Déploiement Continue (CD)

Après la phase d'Intégration Continue (CI), nous avons obtenu un ou plusieurs artefacte(s) qui compose.nt notre logiciel, nous devons donc les déployer sur l'environnement cible.
Etant donné que les artefactes sont obtenus automatiquement, il faut aussi les livrer automatiquement.
Suivant la structure organisationnelle de l'entreprise, cette livraison peut nécessiter une approbation mannuelle avant d'aller en Production par exemple, dans ce cas on parle de Continue Delivery et s'il n'y a pas d'approbation manuelle, donc une livraison directe, alors nous parlons de Continue Deployment.

Release Plan (Note)

Afin de donner de la visibilté de au Business surtout lorsque nous sommes en Continue Delivery, il convient d'établir une Release Note qui trace toutes fonctionnalités et anomalies corrigées dans la version qui est déployée en production.\

Environnements

Afin de garantir la qualité de ce qu'on livre comme produit, il faut s'assurer que les changements appportés sont conforment au besoin exprimé.
Pour cela, il faut mettre en place plusieurs environnements (DEV, INT, UAT & PROD) qui sont respectivement associés aux branches (develop, release, master).

• DEV
  L'environnement DEVest celui sur lequel les développeurs testent les différentes fonctionnalités features qu'ils ont développé.
  Lorsque les changements sont conformes à leurs yeux, les developpeurs font des demandes de fusion dites pull request.

On se positionne sur la branche release/2025.1 puis nous y ajoutons les changements qui sont disponible sur la branche develop

git checkout release/2025.1
git merge develop

• INT
  L'environnement d'Intégration (INT) est associté aux branche release/xxxx.y. C'est enviroonement est dédié aux Business Analysts (BA). C'est ici que les regles de gestion relatives aux besoins exprimés sont testées.
  En cas de non conformité, il ticket d'annomalie est créé et affecté au developpeurs concernés par la fonctionnalité. Ce bug est corrigé en priorité directement sur la branche release/xxxx.y et déployé automatiquement afin que le BA puisse de nouveau tester. C'est également sur cet environnement que les QA (Quality Insurance) lancent les tests automatiques s'assurant ainsi qu'il n'y a pas regressions fontionnelle dans la version.
  A la fin de la phase de tests, un PV de recette est redigé par le responsable de BA. Ce PV est l'élément qui permet permet de promouvoir la version concernée pour aller sur la production en passant par l'environnement UAT.

• UAT
  L'environnement d'UAT est un environnement dit de pre-production. Il est identique à l'environnement de production.
  Sur cette environnement, l'on va lancer les tests de surface dits smoke tests afin de vérifier quelques parcours clés. Le but étant de s'assurer que l'environnement tout est OK.
  Sur cette environnement, étant donné qu'il est identique à la production, tant au niveau du nombre de noeuds, CPU, RAM, interface réseau que des stratégies de montée en charge (auto-scalling).
  Cet environnement va principalement servir à confirmer les exigences non-fonctionnelles telles que:

  • Performace
    • Les Temps de résponse
    • Le Taux d'erreurs
  • Résilience
    • Montée en charge
  • Securité
  • etc...

Il s'agit pour les TechLead de définir plusiers stragtégies de tests qui peuvent être élaborée en répondant aux questions suivantes:

• Quel est le nombre maximum de connexion simultanée supporté
• En combien de temps la page d'accueil s'affiche
• A quel moment le système devient unitilisable
• etc...

Les réponse à ces questions permettent de définir la quelité exacte de resources nécessaires suivant la stratégie de l'entreprise.
Il faut également mettre en place un système de monitoring au travers d'un ensemble de métriques que nous verons dans la section Monitoring

• PROD
  Les résultats de la batterie de tests réalisés en UAT sont à analyser et si les valeurs des mértiques sont conformes aux attendues, alors les perfs experts redige égaelement leur PV de de tests qui sera joint à celui des BA pour autoriser la libvraison en production.
  Après la livraison, il faut imméditement se mettre sur tableau de bord de monitoring pour commencer à surveiller le comportement de la l'application et de la plateforme.
  En cas de souci majeur, l'ont peut revenir sur la version précédente et créer un incident pour corriger le problème.\

Etant donné que l'on souhaite revenir en arrière en cas de souci majeur, alors il faut s'assuer que les nouveaux changements ne crént pas d'incomatibilité entre la version précédente et la version actuelle de la base données.

Configuration des environnements

Nos environnements d'exécution peut être des clusters KUBERNETES ou une VM qui peut être dans le cloud ou onPremise.
Pour automatiser le phase de déploiement, nous allons utiliser les outils tels que:

• Terraform pour faire l'infrastructure as Code c'est à dire provisonner notre environnement
• Asible pour automatiser nos tâches de configuration compte-tenu du nombre important de VMs à paramétrer
• Kustomize et HELM pour gérer nos resource Kubernetes
• ArgoCD pour activer l'automatisation du déploiement.