Templates déploiement Gitlab CI

J'ai présenté lors du Drupalcamp de Rennes en mars 2024 mon nouveau sideproject : un ensemble de jobs factorisés pour gitlab ci.

La problématique était la suivante :

je déploie pas mal de sites, sur des infrastructures différentes, tout est automatisé via la Gitlab CI. Quand j'attaque un nouveau projet, je me contente de copier le fichier .gitlab-ci.yml, qui définit toute la procédure, depuis mon projet le plus récent vers ce nouveau projet. Je dois ensuite penser à modifier certaines variables, certains comportements afin que cela marche sur ce nouveau projet, c'est long, et il est facile de faire une erreur.
Si je fais des évolutions dans mes jobs, le portage sur les anciens projets est complexe.
Je me retrouve entre mes différents projets avec aucune cohérence, au niveau du noms des stages, des jobs lancés, des fonctionnalités...

J'ai décidé de prendre ce problème à la base et j'ai commencé à poser les besoins que j'avais :

Une liste de jobs factorisés, dans laquelle je viens piocher en fonction des besoins du projet. Tous ces jobs étant sur un même dépôt. La réutilisation étant géré via des includes. La généralisation des jobs est faite via les variables Gitlab, par exemple le user ssh est une variable $SSH_USER.
Ces variables doivent pouvoir être différentes entre les différents environnements (dans mon cas : prod et preprod).
Les règles de déploiements sont fixes, un tag de la forme x.y.z lancera un déploiement en prod, un commit / merge sur une branche preprod lancera lui un déploiement en preprod.
Je dois assurer la compatibilité ascendante, ainsi une nouvelle fonctionnalité développée ne doit pas casser les déploiements existants.
Tout doit être documenté, que ça soit pour mon moi du futur ou pour les curieux afin qu'ils s'en servent comme inspiration.

Voici ce à quoi je suis arrivé :

Image

Un dépôt gitlab qui contient des jobs, factorisés :

Image

Pour la documentation, j'ai utilisé l'outil opensource de meta : Docusaurus. Qui génère un mini site statique à partir de fichiers markdown, qui sont directement dans le dépôt :

Image

Cette documentation est hébergée via Gitlab pages avec un nom de domaine personnalisé : https://gitlab-ci-templates.kgaut.net/

Comment ça marche ?

Tous mes jobs sont dans le dossier « templates » du dépôt : https://gitlab.com/kgaut/gitlab-ci-templates/-/tree/main/templates?ref_type=heads

Chaque type de job est dans un fichier spécifique afin de pouvoir, à la carte, utiliser que ce dont on a besoin suivant notre projet :

Image

Voici par exemple le contenu du job de déploiement :

variables:
  DRUPAL_SITE_PATH : 'web/sites/default'
  MIGRATION_SCRIPT_PATH : 'scripts'
  MIGRATION_SCRIPT_PREDEPLOY_PATH : "$MIGRATION_SCRIPT_PATH/pre-deploy"
  MIGRATION_SCRIPT_POSTDEPLOY_PATH : "$MIGRATION_SCRIPT_PATH/post-deploy"
.deploy:
  stage: deploy
  extends:
    .ssh
  script:
    - wget -O drupal-deploy.sh "https://gitlab.com/kgaut/gitlab-ci-templates/-/raw/$CI_TEMPLATE_VERSION/scripts/drupal-deploy.sh"
    - $SSH_CHAIN 'bash -s' < ./drupal-deploy.sh $PROJECT_ROOT $DRUPAL_SITE_PATH $DRUSH_BIN $CI_ENVIRONMENT_NAME $CI_COMMIT_SHORT_SHA $CI_COMMIT_TAG $DRUSH_ALIAS
prod:deploy:
  extends:
    - .prod
    - .deploy
preprod:deploy:
  extends:
    - .preprod
    - .deploy

Chaque job défini des variables par défaut qui peuvent être surchargées par projet. Toutes les variables sont référencées ici : https://gitlab-ci-templates.kgaut.net/docs/bases/variables

Mise en application

Je commence petit à petit à basculer tous mes sites sur ces templates, voici par exemple le .gitlab-ci.yml de mon site, sur lequel vous êtes actuellement :

variables:
  CI_TEMPLATE_VERSION: &CI_TEMPLATE_VERSION 0.4.0 # Le tag de mon projet de déploiement
  PATH_TO_THEME: "./web/themes/custom/kgaut_2024" 
  ASSETS_IMAGE: "registry.gitlab.com/kgaut/docker-node-images:19"
  ASSETS_ARTEFACTS: "./web/themes/custom/kgaut_2024/css"
  SENTRY_PROJECT : 'kgautnet'
  SENTRY_ORG : 'kgautnet'
  DB_PATH: 'db'
  DIFFS_PATH: 'files/diffs'
  ENV_PREPROD_DISABLED: 1
  QA_DOCKER_IMAGE: wodby/drupal-php:8.2-dev
  PHPCS_DOCKER_IMAGE: $QA_DOCKER_IMAGE
  PHPSTAN_DOCKER_IMAGE: $QA_DOCKER_IMAGE
include: # Ici c'est l'inclusion de l'ensemble des jobs utilisés pour le déploiement du site
  - project: kgaut/gitlab-ci-templates
    ref: *CI_TEMPLATE_VERSION
    file:
      - '/templates/generic/stages-variables-extends.yml'
      - '/templates/drupal/backup.yml'
      - '/templates/drupal/diff-config.yml'
      - '/templates/generic/diff-repository.yml'
      - '/templates/generic/assets.yml'
      - '/templates/drupal/deploy.yml'
      - '/templates/generic/sentry.yml'
      - '/templates/drupal/post-deploy-clear-cache.yml'
      - '/templates/generic/scheduled-clean-dump.yml'
      - '/templates/drupal/scheduled-backup.yml'
      - '/templates/generic/deploy-tracking.yml'
      - '/templates/qa/phpstan.yml'
      - '/templates/qa/phpcs.yml'

Certaines variables sont définies directement dans ce fichier, et d'autres, pour des raisons de sécurités sont directement définies sur Gitlab :

Image

Les variables sur Gitlab permettent aussi de définir les variables qui sont différentes par environnement (host SSH, User SSH par exemple) dans le cas courant je n'ai qu'un seul environnement : la production.

Et voici le déploiement en lui même :

Image

Via la variable CI_TEMPLATE_VERSION je fais référence à un tag de mes templates de déploiement, ainsi, même si je fais des évolutions, les templates sont bloqués et je ne risque pas de casser des déploiements qui fonctionnent. Une montée de version est évidement possible, mais sera faite en pleine conscience. Les différents tags sont visibles ici : https://gitlab.com/kgaut/gitlab-ci-templates/-/tags

La branche principale est main, elle peut contenir des modifications en test, un tag ne sera créé que lorsque tout est considéré comme stable.

J'ai profité du troisième jour du drupalcamp afin d'ajouter un peu de QA, avec pour l'instant uniquement des jobs phpstan et phpcs. Ces jobs crééent des artefacts qui sont récupéré par gitlab. Dans les merge request, cela permet de voir les différents problèmes de qualité de code.

En conclusion

Le but de ce dépôt n'est pas forcément d'être utilisé tel quel par d'autres personnes, le processus de déploiement n'est pas forcément compatible avec le votre ou celui de votre agence. Néanmoins, je pense qu'il y a des idées à piquer, ne serai-ce que dans le concept global ou dans des jobs en particulier.

Lors de la conférence de présentation, on m'a posé la question de l'avenir de ce projet. Je continue à le mettre en place sur mes projets, et à ajouter des fonctionnalités au fur et à mesure, je ne compte donc pas l'abandonner comme cela.

Je suis preneur de tout retour, idée, question !

Retrouvez :