Du code à la production : guide du déploiement continu avec GitLab

Le déploiement continu est une pratique qui change la donne et qui permet aux équipes d'offrir de la valeur plus rapidement, avec une confiance accrue. Cependant, adopter des workflows de déploiement avancés, tels que GitOps, l'orchestration de conteneurs avec Kubernetes ou les environnements dynamiques, peut être intimidant pour les équipes non expérimentées.

Chez GitLab, nous nous engageons à ce que la livraison de logiciels soit sans accroc et évolutive. En permettant aux équipes de se concentrer sur les fondamentaux, nous leur donnons les moyens d'établir une base solide qui soutient la croissance et de mettre en place des stratégies plus complexes au fil du temps.

Dans ce guide, découvrez les étapes clés pour mettre en œuvre le déploiement continu avec GitLab et poser les bases d'une réussite à long terme.

Commencez par planifier votre workflow

Avant de passer à la mise en œuvre technique, prenez le temps de planifier votre workflow de déploiement. Une planification minutieuse et une approche méthodique sont les clés du succès.

Stratégie de gestion des artefacts

Dans le contexte du déploiement continu, les artefacts désignent les fichiers empaquetés suite au processus de compilation, destinés à être stockés, déployés et dont vous devez gérer les versions.

En voici quelques exemples :

images de conteneurs pour vos applications
paquets
exécutables ou fichiers binaires compilés
bibliothèques
fichiers de configuration
packages de documentation
autres artefacts

Chaque type d'artefact joue un rôle spécifique dans votre processus de déploiement. Par exemple, une application web typique peut générer les artefacts suivants :

une image de conteneur pour le service backend
une archive ZIP des ressources frontend compilées
des fichiers SQL pour les modifications de base de données
des fichiers de configuration propres à l'environnement

La gestion efficace de ces artefacts est cruciale pour la réussite des déploiements. Voici comment aborder la gestion des artefacts.

Artefacts et stratégies de contrôle des versions

Une bonne pratique permettant de démarrer avec une structure bien organisée consiste à établir une stratégie de gestion des versions claire pour vos artefacts.

Lors de la création de nouvelles versions :

Utilisez la gestion sémantique de version (major.minor.patch) pour les tags de version
- Exemple : myapp:1.2.3 pour une version stable
- Modifications de la version majeure (2.0.0) pour les changements cassants
- Modifications de la version mineure (1.3.0) pour les nouvelles fonctionnalités
- Modifications de la version des correctifs (1.2.4) pour les corrections de bugs
Conservez un tag 'latest' pour la version stable la plus récente
- Exemple : myapp:latest pour les déploiements automatisés
Incluez un SHA de validation pour un suivi précis des versions
- Exemple : myapp:1.2.3-abc123f pour le débogage
Utilisez des tags basés sur les branches pour les environnements de développement
- Exemple : myapp:feature-user-auth pour les tests de fonctionnalités

Rétention des artefacts de compilation

Mettez en œuvre des règles de durée de rétention définies :

Définissez des délais d'expiration explicites pour les artefacts temporaires
Définissez les artefacts nécessitant une durée de rétention permanente
Configurez des stratégies de nettoyage pour gérer le stockage

Accès au registre et authentification

Sécurisez vos artefacts avec des contrôles d'accès appropriés :

Implémentez des jetons d'accès personnels (Personal Access Tokens) pour l'accès des développeurs
Configurez des variables CI/CD pour l'authentification du pipeline
Mettez en place des portées d'accès appropriées

Stratégie d’environnement de déploiement

Réfléchissez dès le départ à la configuration de vos environnements, car ils façonnent l'ensemble de votre pipeline de déploiement :

Configurations de l'environnement de développement, de préproduction et de production
Variables et secrets propres à l'environnement
Contrôles d'accès et règles de protection
Approche de suivi et de surveillance du déploiement

Cibles de déploiement

Il est important de réfléchir à la cible de déploiement et à l'approche choisie, tout en prenant en compte les avantages et les inconvénients de ces décisions :

Besoins en infrastructure (machines virtuelles, conteneurs, services cloud)
Configurations de la sécurité et de l'accès au réseau
Mécanismes d'authentification (clés SSH, jetons d'accès)
Éléments à prendre en compte pour l'allocation des ressources et la mise à l'échelle

Lorsque vous avez défini votre stratégie et pris les décisions fondamentales, vous pouvez transformer cette planification en un pipeline fonctionnel. Nous allons créer un exemple concret qui démontre ces concepts, en commençant par une application simple à laquelle nous ajouterons progressivement des fonctionnalités de déploiement.

Mettez en œuvre votre pipeline CD

Exemple pas à pas

Examinons comment mettre en œuvre un pipeline de déploiement continu de base pour une application web. Nous utiliserons une application HTML simple à titre d'exemple, mais ces principes s'appliquent à tout type d'application. Nous allons également déployer notre application sous la forme d'une image Docker sur une simple machine virtuelle. Cela nous permettra de nous appuyer sur une image organisée avec un minimum de dépendances et de nous assurer qu'aucun prérequis propre à l'environnement n'est introduit involontairement. En travaillant sur une machine virtuelle, nous ne ferons pas appel aux intégrations natives de GitLab, ce qui nous permettra de travailler sur une configuration plus simple, quoique moins évolutive.

Prérequis

Dans cet exemple, nous allons conteneuriser une application qui s'exécutera sur une machine virtuelle hébergée sur la plateforme d'un fournisseur de services cloud. Nous testerons également cette application localement sur notre machine. Cette liste de prérequis n'est nécessaire que pour notre scénario.

Configuration de la machine virtuelle

Provisionnez une machine virtuelle sur la plateforme de votre fournisseur de services cloud préféré (par exemple, GCP, AWS, Azure).
Configurez les règles du réseau pour autoriser l'accès sur les ports 22, 80 et 443.
Enregistrez l'adresse IP publique de la machine pour le déploiement.

Configuration de l'authentification SSH :

Générez une paire de clés publique/privée pour la machine.
Dans GitLab, accédez à Paramètres > CI/CD > Variables.
Créez une variable nommée GITLAB_KEY.
Définissez le type sur « Fichier » (requis pour l'authentification SSH).
Collez la clé privée dans le champ Valeur.
Définissez une variable USER (utilisateur qui se connecte et exécute les scripts sur votre machine virtuelle).

Configuration des variables de déploiement

Créez des variables pour vos cibles de déploiement :
- STAGING_TARGET : l'adresse IP/le domaine de votre serveur de préproduction
- PRODUCTION_TARGET : l'adresse IP/le domaine de votre serveur de production

Configuration du développement local

Installez Docker sur votre machine locale pour tester les déploiements.

Accès au registre de conteneurs GitLab

Localisez votre chemin d'accès au registre :
- Accédez à Déploiement > Registre de conteneurs.
Copiez le chemin d'accès au registre (par exemple, registry.gitlab.com/group/project).
Configurez l'authentification :
- Accédez au menu Paramètres > Jetons d'accès.
- Créez un jeton avec un accès au registre.
- Expiration du jeton : maximum 1 an.
- Enregistrez le jeton de façon sécurisée.
Configurez l'accès au registre local :

docker login registry.gitlab.com
# The username if you are using a PAT is gitlab-ci-token
# Password: your-access-token

1. Création de votre application

Commencez avec une application web de base. Dans notre exemple, nous utilisons une page HTML simple :

<!|||UNTRANSLATED_CONTENT_START|||-- index.html -->
<html>
  <head>
    <style>
      body {
        background-color: #171321; /* GitLab dark */
      }
    </style>
  </head>
  <body>
    <!|||UNTRANSLATED_CONTENT_END|||-- Your content here -->
  </body>
</html>

2. Conteneurisation de votre application

Créez un Dockerfile pour empaqueter votre application :

FROM nginx:1.26.2
COPY index.html /usr/share/nginx/html/index.html

Ce Dockerfile :

Utilise nginx comme image de base pour diffuser du contenu web
Copie votre fichier HTML au bon endroit dans la structure du répertoire nginx

3. Configuration de votre pipeline CI/CD

Créez un fichier .gitlab-ci.yml pour définir les étapes de votre pipeline CI/CD :

variables:
  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest
  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA

stages:
  - publish
  - deploy

Décomposons ce code :

TAG_LATEST est composé de trois parties :

$CI_REGISTRY_IMAGE est le chemin d'accès au registre des conteneurs de votre projet dans GitLab.

Par exemple : registry.gitlab.com/your-group/your-project

$CI_COMMIT_REF_NAME est le nom de votre branche ou tag.

Par exemple, si vous travaillez sur la branche principale : /main, et si vous travaillez sur une branche de fonctionnalité : /feature-login

:latest est un suffixe fixe.

Ainsi, si vous êtes sur la branche principale, TAG_LATEST devient registry.gitlab.com/your-group/your-project/main:latest.

TAG_COMMIT est presque identique, mais au lieu de :latest, il utilise : $CI_COMMIT_SHA, qui est l'identifiant de commit, par exemple :abc123def456.

Ainsi, pour ce même commit sur la branche principale, TAG_COMMIT devient : registry.gitlab.com/your-group/your-project/main:abc123def456.

La présence de ces deux variables s'explique par le fait que TAG_LATEST vous permet facilement de toujours obtenir la version la plus récente. TAG_COMMIT vous fournit une version spécifique à laquelle vous pouvez revenir si nécessaire.

4. Publication dans le registre de conteneurs

Ajoutez le job de publication à votre pipeline :

publish:
  stage: publish
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $TAG_LATEST -t $TAG_COMMIT .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $TAG_LATEST
    - docker push $TAG_COMMIT

Ce job :

Utilise Docker-in-Docker pour compiler des images
Crée deux versions avec tag de votre image
S'authentifie auprès du registre GitLab
Effectue un push des deux versions vers le registre

Maintenant que vos images sont stockées de façon sécurisée dans le registre, vous pouvez vous concentrer sur leur déploiement dans vos environnements cibles. Commençons par des tests locaux pour valider notre configuration avant de passer aux déploiements dans l'environnement de production.

5. Déploiement dans votre environnement

Avant le déploiement en production, vous pouvez effectuer un test localement. Nous venons de publier notre image dans le dépôt GitLab, pour lequel nous allons effectuer un pull localement. Si vous ne connaissez pas le chemin d'accès exact, accédez à Déploiement > Registre de conteneurs. Vous devriez voir une icône permettant de copier le chemin d'accès de votre image à la fin de la ligne pour l'image de conteneur que vous souhaitez tester.

docker login registry.gitlab.com 
docker run -p 80:80 registry.gitlab.com/your-project-path/main:latest

Ce faisant, vous devriez être en mesure d'accéder à votre application localement sur votre adresse localhost via votre navigateur web.

Vous pouvez maintenant ajouter un job de déploiement à votre pipeline :

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - chmod 400 $GITLAB_KEY
    - apk add openssh-client
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER 
      docker pull $TAG_COMMIT &&
      docker rm -f myapp || true &&
      docker run -d -p 80:80 --name myapp $TAG_COMMIT

Ce job :

Configure l'accès SSH à votre cible de déploiement
Effectue un pull de l'image la plus récente
Supprime tout conteneur existant
Déploie la nouvelle version

6. Suivi des déploiements

Activez le suivi des déploiements en ajoutant la configuration de l'environnement :

deploy:
  environment:
    name: production
    url: https://your-application-url.com

Cela crée un objet environnement dans la section Exploitation > Environnements de GitLab et fournit :

L'historique de déploiement
Le statut de déploiement actuel
Un accès rapide à votre application

Bien qu'un pipeline d'environnement unique soit un bon point de départ, la plupart des équipes doivent gérer plusieurs environnements, dont des environnements de test et de préproduction. Étoffons notre pipeline pour gérer ce scénario plus réaliste.

7. Configuration de plusieurs environnements

Pour obtenir un pipeline plus robuste, configurez les déploiements de préproduction et de production :

stages:
  - publish
  - staging
  - release
  - version
  - production

staging:
  stage: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG == null
  environment:
    name: staging
    url: https://staging.your-app.com
  # deployment script here

production:
  stage: production
  rules:
    - if: $CI_COMMIT_TAG
  environment:
    name: production
    url: https://your-app.com
  # deployment script here

Cette configuration :

Effectue un déploiement vers l'environnement de préproduction à partir de votre branche principale
Utilise les tags GitLab pour déclencher les déploiements de production
Fournit un suivi distinct pour chaque environnement

Que ce soit à cette étape ou à l'étape suivante, nous tirons parti des tags, qui sont une fonctionnalité très utile de GitLab. En créant manuellement un tag dans la section Code > Tags, $CI_COMMIT_TAG est créé, ce qui nous permet de déclencher des jobs en conséquence.

8. Création de notes de version automatisées

Nous utiliserons les fonctionnalités de gestion des versions de GitLab depuis notre pipeline CI/CD. Commencez par mettre à jour les étapes de votre pipeline CI/CD dans .gitlab-ci.yml :

stages:

- publish
- staging
- release # New stage for releases
- version
- production

Ensuite, ajoutez le job de release :

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Only run when a tag is created
  script:
    - echo "Creating release for $CI_COMMIT_TAG"
  release:                                # Release configuration
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created from $CI_COMMIT_TAG'
    tag_name: '$CI_COMMIT_TAG'           # The tag to create
    ref: '$CI_COMMIT_TAG'                # The tag to base release on

Vous pouvez l'améliorer en ajoutant des liens vers vos images de conteneurs :

release:
  name: 'Release $CI_COMMIT_TAG'
  description: 'Release created from $CI_COMMIT_TAG'
  tag_name: '$CI_COMMIT_TAG'
  ref: '$CI_COMMIT_TAG'
  assets:
    links:
      - name: 'Container Image'
        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'
        link_type: 'image'

Pour générer des notes de version automatisées pertinentes :

Utilisez des commits conventionnels (feat:, fix:, et autres commandes.).
Incluez les numéros de ticket (#123).
Séparez le sujet du corps par un saut de ligne.

Si vous souhaitez des notes de version personnalisées avec des informations de déploiement :

release_job:
  script:
    - |
      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')
      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:"- %s")
      cat > release_notes.md << EOF
      ## Deployment Info
      - Deployed on: $DEPLOY_TIME
      - Environment: Production
      - Version: $CI_COMMIT_TAG

      ## Changes
      $CHANGES

      ## Artifacts
      - Container Image: \`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\`
      EOF
  release:
    description: './release_notes.md'

Une fois configurées, les versions sont créées automatiquement lorsque vous ajoutez un tag Git. Vous pouvez les afficher dans GitLab sous Déploiement > Releases.

9. Assemblage

Voici à quoi ressemble notre fichier YAML final :

variables:
  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest
  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA
  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables
  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables

stages:
  - publish
  - staging
  - release
  - version
  - production

# Build and publish to registry
publish:
  stage: publish
  image: docker:latest
  services:
    - docker:dind
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG == null
  script:
    - docker build -t $TAG_LATEST -t $TAG_COMMIT .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $TAG_LATEST
    - docker push $TAG_COMMIT

# Deploy to staging
staging:
  stage: staging
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG == null
  script:
    - chmod 400 $GITLAB_KEY
    - apk add openssh-client
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET "
        docker pull $TAG_COMMIT &&
        docker rm -f myapp || true &&
        docker run -d -p 80:80 --name myapp $TAG_COMMIT"
  environment:
    name: staging
    url: http://$STAGING_TARGET

# Create release
release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - |
      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')
      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:"- %s")
      cat > release_notes.md << EOF
      ## Deployment Info
      - Deployed on: $DEPLOY_TIME
      - Environment: Production
      - Version: $CI_COMMIT_TAG

      ## Changes
      $CHANGES

      ## Artifacts
      - Container Image: \`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\`
      EOF
  release:
    name: 'Release $CI_COMMIT_TAG'
    description: './release_notes.md'
    tag_name: '$CI_COMMIT_TAG'
    ref: '$CI_COMMIT_TAG'
    assets:
      links:
        - name: 'Container Image'
          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'
          link_type: 'image'

# Version the image with release tag
version_job:
  stage: version
  image: docker:latest
  services:
    - docker:dind
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - docker pull $TAG_COMMIT
    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG

# Deploy to production
production:
  stage: production
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - chmod 400 $GITLAB_KEY
    - apk add openssh-client
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET "
        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&
        docker rm -f myapp || true &&
        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG"
  environment:
    name: production
    url: http://$PRODUCTION_TARGET

Ce pipeline complet :

Publie des images dans le registre (branche principale)
Déploie vers l'environnement de préproduction (branche principale)
Crée des versions (lorsqu'un tag est ajouté)
Crée des versions d'images avec des tags de version
Déploie dans l'environnement de production (lorsqu'un tag est créé)

Principaux avantages :

Environnement de développement et de test local propre et reproductible
Chemin d'accès clair vers les environnements de production avec une structure qui renforce la confiance dans ce qui est déployé
Modèle pour se remettre de défaillances inattendues, entre autres
Possibilité de développement sur cette base et d'adoption de stratégies de déploiement plus complexes

Bonnes pratiques

Tout au long de la mise en œuvre, respectez les principes suivants :

Documentez tout, de l'utilisation des variables aux procédures de déploiement.
Utilisez les fonctionnalités intégrées de GitLab (environnements, releases, registre).
Mettez en œuvre des contrôles d'accès et des mesures de sécurité adaptés.
Pensez aux éventuelles défaillances en mettant en place des procédures de restauration robustes.
Évitez les redondances dans vos configurations de pipeline en suivant le principe DRY (Don't Repeat Yourself).

Mise à l'échelle de votre stratégie de déploiement

Pour terminer, voici quelques aspects à prendre en compte à mesure que votre stratégie de déploiement continu évolue.

Mesures de sécurité avancées

Améliorez la sécurité grâce aux fonctionnalités suivantes :

Environnements protégés avec accès restreint
Approbations requises pour les déploiements en production
Scanning de sécurité intégré
Évaluations automatisées des vulnérabilités
Règles de protection des branches pour les modifications liées au déploiement

Stratégies de livraison progressive

Mettez en œuvre des stratégies de déploiement avancées :

Feature flags pour les déploiements contrôlés
Déploiements canari pour l'atténuation des risques
Stratégies de déploiement bleu-vert
Capacités de test A/B
Gestion dynamique de l'environnement

Surveillance et optimisation

Mettez en place des pratiques de surveillance robustes :

Suivi des mesures de déploiement
Mise en place d'un suivi des performances
Configuration d'alertes de déploiement
Établissement d'objectifs de niveau de service (SLO) en matière de déploiement
Optimisation régulière du pipeline

Pourquoi utiliser GitLab ?

La plateforme GitLab est idéale pour les workflows de déploiement modernes grâce à ses fonctionnalités de déploiement continu. Elle permet de simplifier les étapes menant du code à la production, en offrant un registre de conteneurs intégré, une gestion de l'environnement et le suivi des déploiements au sein d'une seule interface. Les variables propres à l'environnement, les portes d'approbation de déploiement et les fonctionnalités de restauration de GitLab fournissent la sécurité et le contrôle nécessaires aux déploiements en production, tandis que les fonctionnalités telles que les versions temporaires d'applications et les feature flags offrent des approches de livraison progressive. Ces fonctionnalités de déploiement continu font partie intégrante de la plateforme DevSecOps complète de GitLab et s'intègrent parfaitement à l'ensemble du cycle de vie de vos logiciels.

Lancez-vous dès aujourd'hui

Opter pour un déploiement continu est une évolution, pas une révolution. Commencez par les fondamentaux, établissez une base solide et intégrez progressivement des fonctionnalités avancées lorsque les besoins de votre équipe augmentent. GitLab fournit les outils et la flexibilité nécessaires pour vous accompagner à chaque étape de ce parcours, de votre premier déploiement automatisé aux pipelines de livraison complexes et multi-environnements.

Essayez GitLab Ultimate gratuitement pendant 60 jours et commencez votre déploiement continu dès aujourd'hui.