Construisez une fois, déployez partout : approche de la promotion des applications

Introduction

La livraison d’applications modernes exige des builds fiables, des déploiements cohérents et des processus de mise en production contrôlés. Reconstruire une application pour chaque environnement risque de générer des incohérences et il peut être difficile de vérifier que la version testée par le service QA parvienne en production. L’approche « build once, deploy anywhere » résout ce problème en construisant l’artefact applicatif une seule fois puis en le faisant évoluer à travers les environnements sans reconstruction.

Le processus de mise en production commence par une branche de release, suivie par les modifications des développeurs et les pipelines JAR requis. Jenkins construit l’application et crée une image Docker, qu’il pousse ensuite vers Amazon Elastic Container Registry (Amazon ECR). L’optimisation de la taille des images Docker lors de ce processus améliore l’efficacité du déploiement, explorant les bonnes pratiques pour réduire la taille des images Docker avec des builds multi-étapes.

Le pipeline de déploiement déploie ensuite l’image dans l’environnement de Test. Après qu’une vérification fonctionnelle (sanity test) a été réalisée par le service QA, un pipeline d’approbation contrôle la promotion vers des environnements supérieurs tels que UAT et Production. Helm, Kubernetes et ArgoCD prennent en charge la configuration et le déploiement spécifiques à chaque environnement. Cette approche dissocie la construction applicative du déploiement et de la promotion, créant ainsi un processus de contrôle de release cohérent et traçable.

Points essentiels

• Construire une fois : Créez l’artefact de l’application et l’image Docker une seule fois pour chaque candidat à la version.
• Tester avant promotion : Effectuez un test de validation fonctionnelle complète avant de promouvoir la version.
• Réutiliser le même artefact : Promouvez l’image validée dans les environnements Test, UAT et Production.
• Configuration séparée : Utilisez les valeurs Helm pour gérer les paramètres spécifiques à l’environnement.
• Contrôler les versions : Mettez en place des étapes d’approbation pour les environnements supérieurs.
• Maintenir la traçabilité : Associez chaque image à sa version de release et à la révision de source.

Pourquoi adopter une approche « construire une fois » ?

Cette approche évite que des applications construites pour différents environnements produisent des dépendances, paramètres de build ou révisions de source variés. Par conséquent, l’artefact déployé en Production pourrait différer de celui testé par la QA. La méthode build-once évite les rebuilds inutiles pendant la promotion. Une fois que Jenkins a créé l’artefact de release, le processus de promotion comprend des tests, une approbation et un déploiement. Le flux de travail est le suivant :

Build → Test → Sanity QA → Approbation → UAT → Production

Chaque environnement utilise la même image applicative, la configuration de déploiement peut varier selon l’environnement. Cette approche améliore la cohérence des artefacts, facilite le dépannage, minimise les opérations de build redondantes et simplifie la traçabilité des releases.

Comment fonctionne le processus de lancement

1. Créer la branche de release
   Le pipeline de release crée une branche de release. Les développeurs effectuent les modifications nécessaires sur cette branche, qui devient la source pour la prochaine construction. L’équipe lance ensuite les pipelines JAR requis, JAR 2.0 et JAR 2.2 selon les exigences de la release. La construction de l’application démarre une fois que les étapes préparatoires nécessaires ont été réussies.
    
2. Construire l’application avec Jenkins
   Jenkins gère le processus de construction de l’application. Le pipeline de build récupère la branche de release, exécute les étapes de build requises et crée l’artefact de l’application. Le pipeline empaquette ensuite l’application dans une image Docker et pousse cette image vers Amazon ECR. L’équipe doit enregistrer la version de la release, le commit SHA Git, le numéro de build Jenkins et le tag de l’image. Ces informations permettent d’identifier précisément l’artefact associé à une release. Une fois la construction réussie et les contrôles requis passés, le processus de promotion doit réutiliser l’artefact existant plutôt que de reconstruire l’application.
    
3. Stocker l’image Docker dans Amazon ECR
   Amazon ECR est un dépôt central pour stocker et récupérer les images Docker. Après que Jenkins ait créé l’image, il la pousse vers le dépôt ECR approprié. Les pipelines de déploiement récupèreront cette image lors du déploiement de l’application dans différents environnements. Un tag d’image unique permet d’identifier chaque release. Utiliser le même tag d’image à travers les environnements garantit que Test, UAT et Production reçoivent le même artefact.

Déploiement en environnement de test et finalisation de la validation fonctionnelle

Une fois que l’image est dans Amazon ECR, la chaîne de déploiement la déploie en environnement Test. Helm gère la configuration de déploiement Kubernetes tandis qu’ArgoCD synchronise la configuration souhaitée avec l’environnement Kubernetes cible. Le processus de déploiement doit vérifier que l’application a démarré avec succès, que les contrôles de santé sont passés et que les fonctionnalités critiques fonctionnent comme prévu. L’assurance qualité effectuera des tests de cohérence pour valider la version. Si l’application échoue à la validation, l’équipe résout le problème et répète les contrôles nécessaires avant de continuer. Un déploiement réussi ne signifie pas que la version est prête pour la promotion. Une fois les vérifications requises terminées par l’assurance qualité, la version passe à l’étape d’approbation.

Déployer la même version vers des environnements supérieurs

Le pipeline d’approbation fournit un point de contrôle contrôlé avant que la mise en production ne progresse vers des environnements supérieurs. Le processus suit ces étapes :

• Jenkins construit l’application et publie l’image Docker.
• Le pipeline de déploiement déploie l’image en environnement de test.
• QA réalise les tests de validation initiale.
• Le pipeline d’approbation demande l’autorisation pour la promotion.
• Un intervenant autorisé approuve la mise en production.
• Le processus de déploiement promeut la même image vers la recette utilisateur (UAT).
• L’équipe complète l’approbation requise pour la production.
• Le processus de déploiement promeut l’image approuvée en production.

L’approbation autorise la promotion, elle ne déclenche pas une nouvelle compilation de l’application. Cette séparation permet de conserver une trace claire de l’artefact qui a passé la validation et atteint la production.

Gestion des déploiements avec Helm, Kubernetes et ArgoCD

Différents environnements auront des exigences opérationnelles différentes. La production peut nécessiter plus de réplicas et des limites de ressources plus élevées que le test, mais cela n’implique pas une nouvelle image d’application. Les fichiers de valeurs Helm gèrent ces paramètres de déploiement. Les équipes peuvent également configurer séparément les points de terminaison spécifiques à l’environnement et les paramètres des fonctionnalités par rapport à l’artefact de l’application. ArgoCD prend en charge le déploiement basé sur GitOps en synchronisant les environnements Kubernetes avec la configuration souhaitée stockée dans Git.

Chaque outil a une responsabilité distincte :

    1. Jenkins : construit l’application et publie les images Docker.
    2. Amazon ECR : stocke les images de l’application.
    3. Helm : gère la configuration du déploiement.
    4. ArgoCD : synchronise la configuration souhaitée avec Kubernetes.
    5. Kubernetes : exécute et gère l’application.

 Pour plus d’informations, explorez les étapes pour mettre à jour un cluster Amazon EKS et le renforcement complet des conteneurs sur Amazon EKS.

Pipelines Jenkins et leurs responsabilités

La configuration Jenkins est répartie en différentes responsabilités au lieu de regrouper l’ensemble du processus de release dans un seul pipeline. Certains des pipelines importants dans le flux sont :

Chaque pipeline gère une responsabilité spécifique, ce qui rend le processus de release plus facile à suivre et à dépanner. Des dépendances claires évitent également que des builds échoués ou des contrôles QA non concluants ne progressent vers les étapes suivantes.

Construire une fois vs reconstruire pour chaque environnement

L’approche construire une fois n’élimine pas les tests spécifiques à chaque environnement. Chaque environnement nécessite toujours des contrôles de déploiement appropriés et des validations de version. Elle supprime simplement les reconstructions inutiles de l’application lors du processus de promotion.

Bonnes pratiques pour une promotion d’application fiable

Quelques pratiques aident à maintenir la cohérence tout au long du cycle de vie de la version.

1. Ne jamais reconstruire durant la promotion
   Réutilisez l’artefact existant entre les environnements. Si une modification de l’application devient nécessaire, créez une nouvelle construction et répétez les validations requises.
    
2. Séparez la configuration du code applicatif
   Gérez les paramètres spécifiques à l’environnement via les valeurs Helm et un mécanisme approprié de gestion des secrets.
    
3. Utilisez des références d’images immuables
   Enregistrez les tags d’image et utilisez la même référence d’image dans tous les environnements.
    
4. Imposez des validations et des gates d’approbation
   Empêchez l’avancement des versions si les tests ou les validations requises échouent.
    
5. Maintenez la traçabilité
   Enregistrez le commit source, le numéro de build Jenkins, le tag d’image et l’historique des déploiements. 
   Pour les déploiements en production nécessitant une gestion avancée du trafic et une visibilité sur les services, la mise en place d’un service mesh comme Istio offre un contrôle granulaire sur la communication et l’observabilité des applications. 
    
6. Prévoir un retour arrière
   Conservez les images précédemment approuvées et maintenez les enregistrements de déploiement pour permettre une reprise en cas de problème causé par une version.

Conclusion

L’approche build-once, deploy-anywhere sépare la construction des applications de leur déploiement et promotion, aidant les équipes à maintenir la cohérence tout au long du cycle de vie des releases. Jenkins construit l’application et publie l’image Docker sur Amazon ECR. La pipeline de déploiement livre l’image à l’environnement Test, où l’assurance qualité effectue des tests de validation sommaire. Après les validations nécessaires, l’équipe promeut la même image vers UAT et Production.

Helm gère la configuration de déploiement, Kubernetes exécute l’application, et ArgoCD prend en charge les déploiements basés sur GitOps. Le principe clé est simple : construire une fois, valider l’artefact, puis promouvoir ce même artefact à travers les environnements.

En évitant les reconstructions superflues et en maintenant des contrôles d’approbation clairs, les équipes peuvent améliorer la cohérence des artefacts, simplifier le dépannage et établir un processus de release CI/CD plus fiable. Pour renforcer encore cette fiabilité et optimiser les coûts d’infrastructure, les équipes peuvent également mettre en œuvre des stratégies d’autoscaling Kubernetes intelligentes avec des outils comme Karpenter, qui ajustent automatiquement les ressources selon la demande de l’application en temps réel.