En ayant marre d'avoir à gérer x versions de de NodeJS sur ma machine avec pour chacune ses dépendances et incompatibilités, et de devoir se souvenir pour chaque projet quelle version utiliser, j'ai fini par externaliser cette gestion à docker, comme je le fais déjà depuis longtemps pour php, mysql, SolR...
CI
-
-
Pour un projet, j'ai du mettre en place une stratégie de déploiement automatisée avec entre autres un déploiement sur un serveur de préproduction que lors de la création d'un tag preprod-x.x exemples : preprod-0.1, preprod-0.2, preprod-1.0...
-
Via Gitlab CI il est possible de faire qu'un job soit manuel (manual) afin que, comme son nom l'indique, il ne soit exécuté que si l'on en a besoin.
C'est pratique pour des tâches non obligatoires ou que l'on veut ne pas lancer à chaque déploiement.
-
Dans la version 13 de Gitlab CI qui sortira le 22/05/2020, les instructions only / exept ne fonctionneront plus dans nos fichiers .gitlab-ci.yml.
-
J’utilise énormément la partie « CI » de Gitlab pour déployer automatiquement les sites et applications web que je gère.
-
.gitlab-ci.yml
stages : - predeploy - deploy - postdeploy - scheduled prod_backup_db: script: - ssh <a href="mailto:user@serveur">user@serveur</a> 'drush @kg cr' - ssh <a href="mailto:u
-
Si vous utilisez gitlab-ci pour mettre en place un déploiement automatisé vers votre serveur de production (ou n'importe quel type de serveur), Il faut que votre runner puisse s'authentifier via SSH sur le serveur.
Pour cela, on commence par lui créer une clé ssh :
-
Si vous tentez de mettre en place Gitlab CI sur votre serveur, au moment de l'enregistrement d'un runner, via la commande :