Principes de base

Environnements

2 environnements de déploiement :

• prod
• preprod

Le déploiement en prod se fait lors de tag x.y.z, le déploiement en preprod se fait lors d'un push sur la branche preprod (ou celle que désigne PREPROD_BRANCH).

Plus d'information sur les déclencheurs

Variables

Pour le bon fonctionnement des jobs, des variables sont nécessaires, certaines peuvent être spécifiques à l'environnement (prod ou preprod).

Il est recommandé de passer en protected les variables critiques (clé ssh privée par exemple), cela impliquera que la branche preprod soit elle aussi protected ainsi que les tags *.*.*. cela se configure dans gitlab: Settings / Repository / Protected tags & Protected branches.

Plus d'information sur les variables

Scripts exécutés sur le serveur

Les jobs de déploiement et de diff exécutent sur le serveur, par SSH, des scripts du dossier scripts/ de ce dépôt. Ils les téléchargent au moment du job, à la version CI_TEMPLATE_VERSION, depuis l'instance GitLab qui exécute le pipeline (CI_TEMPLATE_SCRIPTS_URL) : celle d'où viennent les include: project:, où cette version existe donc forcément.

Les scripts récents (déploiement Symfony, sauvegardes MySQL et Drupal) reçoivent leurs paramètres par l'environnement : le job envoie au serveur, avant le script, des lignes export VARIABLE='valeur' correctement quotées. Une valeur peut donc contenir des espaces, et une variable vide ne décale pas les suivantes.

Le projet kgaut/gitlab-ci-templates doit être public sur cette instance : un projet privé ou absent renvoie la page de connexion, et le job échoue en le signalant, sans rien exécuter.

Rapports des jobs de diff

Les patchs et les archives produits par les jobs de diff sont rapatriés du serveur et publiés en artefacts du job, dans reports/. Ils sont conservés une semaine, même quand le job échoue, et ne sont téléchargeables que par les membres Developer et au-delà : un patch peut contenir des secrets.

Connexion SSH et clés d'hôte

Les jobs qui se connectent au serveur vérifient son identité avec les clés d'hôte fournies par le projet (SSH_KNOWN_HOSTS ou SSH_KNOWN_HOSTS_FILE). Sans elles, ils balaient le serveur à chaque job (ssh-keyscan) et croient ce qu'il répond : le job le signale par un avertissement. Fournir les clés d'hôte

Artefacts

Les jobs de déploiement, de sauvegarde, de diff et d'après déploiement ne consomment aucun artefact : ils déclarent dependencies: [], et ne dépendent donc pas de la durée de vie des artefacts des stages précédents. Un job d'un projet qui étend l'un d'eux (.deploy, .post-deploy, .deploy-track…) et qui a besoin d'un artefact doit le dire, par needs ou par dependencies.

Les artefacts que d'autres jobs consomment (rapports QA, assets générés) sont conservés un jour.