Déploiement continu en préproduction

Introduction

Le déploiement continu (CD) est l’étape au cours de laquelle un logiciel validé est livré dans un environnement où il peut être exécuté.

Reprenons l’exemple de notre usine logicielle.

CI : le robot recherche les défauts.
Artefact : le robot emballe le produit dans une boîte.
CD : le camion de livraison transporte la boîte jusqu’au magasin (le serveur), afin que les clients puissent l’utiliser.

Dans le monde réel, un déploiement consiste souvent à mettre à jour des systèmes en fonctionnement via SSH, des API ou des mécanismes de mise en production propres à une plateforme. Dans ce lab, vous simulerez ce processus. L’objectif principal est de comprendre le flux de livraison, du code testé jusqu’à l’environnement d’exécution.

C’est la différence fondamentale entre la CI et le CD. La CI vérifie que les modifications du logiciel sont suffisamment fiables pour être livrées, tandis que le CD prend en charge le transfert contrôlé de ces modifications validées vers un environnement.

Dans ce lab, vous allez :

Découvrir le concept des déclencheurs manuels (déploiement en un clic).
Écrire un workflow de déploiement qui simule le processus réel.
Relier votre « camion de livraison » (CD) à votre « contrôle qualité » (CI).

Prérequis

Nous continuerons à utiliser le dépôt github-actions-basics.

Créer un déploiement manuel

Vous ne souhaitez pas forcément effectuer un déploiement à chaque envoi de code. Vous pouvez vouloir attendre une approbation ou déployer uniquement lorsque vous êtes prêt.

C’est pourquoi les déclencheurs manuels et les environnements par étapes sont courants. Les pipelines de livraison cherchent souvent un équilibre entre rapidité et prudence opérationnelle, plutôt que de déployer immédiatement en production chaque build réussi.

GitHub Actions vous permet de créer des workflows qui s’exécutent uniquement lorsque vous cliquez sur un bouton. Pour cela, utilisez le déclencheur workflow_dispatch.

Accédez au répertoire de votre projet.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Remarque : remplacez your-username par votre véritable nom d’utilisateur GitHub.

Créez un nouveau fichier nommé deploy.yml.

touch .github/workflows/deploy.yml

Ouvrez-le avec nano.

nano .github/workflows/deploy.yml

Ajoutez le contenu suivant :

name: Deploy to Production

on: workflow_dispatch

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploying
        run: echo "Starting deployment..."

Vous voyez on: workflow_dispatch ? C’est le bouton magique.

Enregistrez le fichier, quittez nano, puis envoyez ce fichier vers GitHub.

git add .
git commit -m "Add manual deployment workflow"
git push

Accédez maintenant à l’onglet Actions sur GitHub.

Cliquez sur Deploy to Production dans la barre latérale gauche.
Une bannière bleue contenant le message « This workflow has a dispatch event trigger. » s’affiche.
Cliquez sur le bouton Run workflow, puis sur le bouton vert Run workflow dans le menu déroulant.

Run workflow

Vous venez de déclencher manuellement un pipeline de déploiement !

Simuler les étapes d’un déploiement

Les scripts de déploiement réels peuvent être complexes, mais ils suivent généralement un schéma simple :

Se connecter au serveur.
Récupérer la nouvelle version du logiciel.
Redémarrer l’application.

Même si les détails d’implémentation varient, la plupart des pipelines de déploiement suivent encore cette structure générale : s’authentifier, récupérer l’artefact souhaité, puis faire en sorte que l’environnement en cours d’exécution l’utilise.

Mettons à jour deploy.yml pour simuler ces étapes. Nous utiliserons des commandes echo pour afficher ce qui se passerait réellement.

Ouvrez à nouveau le fichier.

nano .github/workflows/deploy.yml

Remplacez la section jobs par cette simulation plus détaillée :

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Mock SSH Connection
        run: echo "Connecting to production server at 192.168.1.1..."

      - name: Pull New Image
        run: |
          echo "Logging into Registry..."
          echo "Pulling image ghcr.io/myname/app:latest..."

      - name: Restart Application
        run: |
          echo "Stopping old container..."
          echo "Starting new container..."
          echo "Deployment Successful!"

Enregistrez le fichier et quittez l’éditeur. Envoyez vos modifications.

git add .
git commit -m "Update deployment steps"
git push

Retournez dans GitHub Actions et exécutez à nouveau manuellement le workflow Deploy to Production. Observez les journaux. Ils ressemblent à ceux d’un véritable déploiement !

Run workflow

Cette technique de « simulation » est très utile. Dans le monde professionnel, nous écrivons souvent d’abord ces workflows « squelettes » afin de nous mettre d’accord sur le processus avant de développer le code complexe réel.

Ajouter des contrôles de sécurité

Pour le moment, notre workflow « Deploy » est complètement séparé de notre workflow « Test » (CI). Pourtant, dans la réalité, vous ne voulez jamais déployer du code défectueux. Vous voulez que le camion de livraison ne parte que si le contrôle qualité réussit.

Vous pouvez relier des workflows avec le mot-clé needs, mais cette méthode fonctionne surtout au sein d’un même fichier. Pour des fichiers séparés, nous gérons généralement cela au niveau du processus : la CI s’exécute lors d’un Push, tandis que la CD s’exécute lors d’une Release ou manuellement.

Apprenons toutefois à ajouter un contrôle de sécurité, même à notre déploiement manuel. Nous supposerons que le déploiement ne doit avoir lieu que lorsque nous sommes absolument certains de sa fiabilité.

Ouvrez deploy.yml.

nano .github/workflows/deploy.yml

Ajoutons une simulation de la protection d’un environment. Modifiez la section steps pour y inclure une vérification.

steps:
  - name: Safety Check
    run: echo " verifying that CI passed..."

  - name: Mock SSH Connection
    run: echo "Connecting to production server at 192.168.1.1..."
  ## ... rest of the file

(Remarque : dans une véritable configuration Enterprise, nous utiliserions une fonctionnalité appelée GitHub Environments pour imposer que « la CI doit réussir » avant l’exécution de ce job. Cela nécessite toutefois une configuration en dehors de ce fichier.)

Pour le moment, enregistrez le fichier, quittez l’éditeur, puis envoyez vos modifications.

git add .
git commit -m "Add safety check"
git push

Exécutez une dernière fois le workflow manuellement.

Résumé

Félicitations ! Vous avez terminé le module CICD consacré à GitHub Actions.

Dans ce dernier lab, vous avez appris :

Déclencheurs manuels : utiliser workflow_dispatch pour contrôler les déploiements.
Simulation : prototyper un processus de déploiement à l’aide d’étapes simulées.
Vue d’ensemble : comprendre comment la CI, les artefacts, la sécurité et le CD s’intègrent.

Vous êtes parti de zéro concernant GitHub Actions et disposez maintenant d’un dépôt entièrement fonctionnel avec des scripts de test, de création de packages et de déploiement automatisés. Vous êtes prêt à commencer l’automatisation de vos propres projets !