Cas client : Comment améliorer la fiabilité du processus de livraison informatique

Contexte : Les entreprises doivent s’adapter aux nouvelles conformités informatiques demandées par l’Europe

Notre client du secteur des assurances a dû faire face à de nouvelles exigences européennes en matière de conformité informatique, qui l'obligeaient à améliorer la fiabilité de son processus de livraison de logiciels et à simplifier la collecte de l'historique de livraison de production. 

Nous avons rejoint une équipe de plateforme DevOps nouvellement créée qui était chargée de cette responsabilité, qui a hérité de défis importants de la configuration existante.

Défis initiaux observés : Un pipeline de livraison mal documenté avec peu de conformités informatiques à jour

Nous avons découvert que le pipeline de livraison de logiciels reposait sur de mauvaises pratiques. Il était géré par une seule personne utilisant des méthodes incohérentes avec une documentation minimale, ce qui a conduit à :

• Difficultés de dépannage du pipeline : l'identification et la résolution des problèmes prenaient du temps et étaient sujettes aux erreurs.
• Lacunes en matière de conformité : la ressource cloud n'était pas alignée sur les politiques de conformité cloud de l'entreprise. 
• Implication limitée des développeurs : les développeurs avaient peu d'informations ou de contrôle sur les processus de déploiement gérés exclusivement par un seul DevOps.
• Manque de validation de livraison : vérifier si une version de production était réussie ou comportait des problèmes était un processus manuel.

Nous avons limité notre champ d'action à l'infrastructure et aux pipelines CI/CD, à l'exclusion du code d'application.

Problèmes informatiques opérationnels identifiés

Nous avons identifié les problèmes clés suivants ayant un impact sur le déploiement :

• Balises git mal nommées et déroutantes ;
• Version de production de fonctionnalités/bascules de fonctionnalités qui n'étaient pas correctement déclarées ;
• Défis liés à la restauration de la version précédente ; 
• Opérations manuelles sensibles apparaissant dans les pipelines de production, par exemple, activer la page de maintenance ;
• Conflits fréquents entre les branches git ;
• Une tolérance croissante pour les tâches ayant échoué ou se terminant par des avertissements ;

Les causes profondes de ces problèmes étaient principalement l'utilisation de branches git spécifiques à l'environnement. Impliquant plusieurs fichiers de configuration, règles et variables, ce qui rendait le pipeline complexe.

Solutions appliquées pour mettre en conformité les process informatiques, les rendre modulables et réduire les coûts

Nous avons optimisé le flux de travail de déploiement en supprimant les interventions manuelles (CI/CD) et en rationalisant l'infrastructure avec un environnement actif/non actif au lieu de bleu/vert. Élimination des erreurs humaines lors de l'activation de la version et activation des transitions automatisées.

L'adoption de GitHub Flow a réduit la complexité de la ramification, tandis qu'elle a standardisé les portes de qualité pour assurer une validation cohérente du code.

Le déploiement continu a été accéléré en minimisant les frais généraux liés aux tâches, en réduisant les délais de déploiement et en automatisant les contrôles préalables à la mise en œuvre afin de respecter les normes réglementaires et opérationnelles. La sécurité a été renforcée avec l'authentification OIDC pour les déploiements contrôlés.

Rationalisation de l'infrastructure Terraform

La base de code de l'infrastructure a été réécrite pour être modulaire, réutilisable et conforme aux politiques :

• Plus facile à gérer grâce à la réduction de nombreux fichiers d'état Terraform. 
• Économise le développement et garantit que les ressources déployées sont conformes aux politiques cloud de l'entreprise en supprimant les ressources autogérées. Remplacé par un module Terraform standardisé fourni par l'équipe cloud-DevOps de l'entreprise. 
• Test plus rapide des modifications de l'infrastructure avec la possibilité d'exécuter un plan Terraform local dans l'environnement de développement. En raison du grand nombre de variables fournies à Terraform à partir du pipeline GitLab CI/CD, il était difficile d'exécuter un plan Terraform local sans pousser le code. Cela permet de tester plus rapidement les modifications de l'infrastructure et de réduire le temps de validation des correctifs et des fonctionnalités. 

Suppression de la confusion Blue/Green : des manipulations simplifiées entre environnement actif et non-actif

Dans un modèle de déploiement Blue/Green, deux environnements de production identiques existent : l'un actif avec la version actuelle de l'application (blue) et l'autre exécutant la nouvelle version de l'application (green). Après une validation réussie, le trafic est basculé vers l'environnement vert et devient l'environnement actif.

Le processus existant était sujet à des erreurs humaines, car les développeurs devaient savoir quelle couleur (blue ou green) était actuellement active et mettre à jour manuellement les fichiers Terraform pour spécifier quelle version devait être activée dans l'environnement non actif.

Nos améliorations ont simplifié le processus d'activation de la version, en supprimant l'exigence d'association de couleurs et en autorisant plusieurs versions masquées pour les tests dans un environnement à branches de fonctionnalités.

Pour le déploiement continu (CD), la promotion de la version de « masquée » à « active » est déplacée dans une tâche de pipeline au lieu d'une validation manuelle. En un clic, le développeur peut exécuter la tâche d'activation manuelle, qui basculera automatiquement le trafic vers la nouvelle version.

La logique de routage CloudFront basée sur un cookie de version avec Lambda@Edge est refactorisée, intégrant des tests unitaires et des portes de qualité SonarQube pour une fiabilité améliorée. Consultez l'article Comment configurer un déploiement blue-green avec AWS Lambda Edge.

Déploiement continu

De Git Flow à GitHub Flow

La stratégie de ramification multiple, inspirée de Git Flow, a entraîné des confusions et des conflits lors de la fusion et du déploiement de code. En éliminant les branches spécifiques à l'environnement dans les référentiels d'applications et d'infrastructures, à l'instar de GitHub Flow, nous avons clarifié le processus de déploiement :

• Remplir automatiquement les variables de la tâche de déploiement déclenchée à partir du message de fin de balise
• Déplacer une version d'un environnement à un autre sans avoir à passer par les gates de qualité du code

Quality Gates 

Nous avons standardisé les portes de qualité à l'aide de modèles génériques, garantissant que tous les projets respectent les mêmes normes. Cela incluait SonarQube pour l'analyse de la qualité du code, les tests unitaires et d'intégration pour la validation du code et les contrôles de dépendance pour les vulnérabilités.

Déploiement continu

Réduction du nombre de tâches

Dans GitLab CI/CD, lorsqu'une nouvelle tâche est instanciée, plusieurs étapes se produisent pour préparer l'environnement et exécuter le script de tâche :

1. Initialisation du runner GitLab : identifie le runner qui exécutera la tâche et lui attribue un identifiant unique. 
2. Résolution des secrets : tous les secrets requis pour la tâche sont récupérés en toute sécurité. 
3. Préparation de l'exécuteur : le runner prépare l'environnement de l'exécuteur, y compris l'image du conteneur et toutes les dépendances requises.
4. Authentification Docker et extraction d'image : le runner s'authentifie auprès du registre Docker et extrait l'image du conteneur requise.
5. Préparation de l'environnement : l'environnement d'exécution est configuré, y compris le montage des volumes, la configuration du réseau ou l'initialisation des chemins.
6. Récupération du code source : le référentiel du projet est cloné dans le répertoire de travail et un commit spécifique est extrait.
7. Téléchargement d'artefacts : les artefacts des étapes précédentes du pipeline sont téléchargés.

Lorsque les exécuteurs GitLab sont occupés, il peut falloir jusqu'à 2 minutes pour que le conteneur soit prêt avant de démarrer l'exécution du script. En réduisant le nombre de tâches dans le pipeline, nous pourrions réduire le temps de déploiement jusqu'à 14 minutes, juste en temps d'initialisation du conteneur.

Automatisation des vérifications de pré-implémentation et des preuves de livraison

Le pipeline CD déploie désormais les artefacts déclenchés à partir du pipeline CI en fonction du SHA court de validation, et le nom de la version est obtenu à partir du slug de référence de validation.

Cette automatisation remplace les validations manuelles dans le code Terraform, introduisant une vérification de pré-implémentation comme mesure de sécurité dédiée. Le travail effectue une série de validations automatisées avant que la nouvelle version ne soit promue à la version active :

• La version cachée à activer est-elle accessible lors de la définition du cookie de version ?
• La version actuellement active est-elle différente de la version à activer ?

Une fois déployée, nous pouvons recueillir des preuves de ce qui a été livré en production. Selon la réglementation européenne Digital Operational Resilience Act (DORA), il s'agit d'une partie obligatoire du processus de gestion des changements. Dans le cadre de la post-implémentation, nous vérifions :

• La production est-elle toujours accessible ?
• Le cookie de publication répondu est-il conforme à la publication déployée ?

Renforcement de la sécurité

Nous avons amélioré la sécurité en implémentant OIDC (OpenID Connect) sur les tâches GitLab, un protocole d'authentification qui permet une vérification d'identité sécurisée et fiable. Cela signifie que seuls les utilisateurs disposant des autorisations appropriées, telles que définies par leurs rôles, peuvent lancer les processus de déploiement.

Prochaines étapes pour évaluer la réussite du projet et son développement futur

Un processus simplifié a été établi, exécutant des déploiements conformes plus rapidement et permettant une restauration en toute simplicité.

La mise en œuvre d'une plateforme de mesures DevOps basée sur DevOps Research and Assessment (DORA) sera notre prochaine étape. Cela permet de suivre :

• Fréquence de déploiement 
• Délai d'exécution des modifications
• Délai moyen de récupération
• Taux d'échec des modifications

Leçons apprises

Ce projet a fourni des informations précieuses sur les pratiques DevOps modernes :

• La compréhension de la stratégie de déploiement bleu-vert a permis de minimiser les temps d'arrêt et de réduire les risques pendant les déploiements.
• Sécurisation des déploiements avec OIDC. 
• Base de code d'infrastructure modulaire, conforme aux politiques de l'entreprise.
• AWS Lambda@Edge pour le routage entre les versions d'application a amélioré la flexibilité du déploiement.
• L'adoption de GitHub Flow pour l'intégration continue a rationalisé le processus de développement.
• Les gates de qualité standardisées avec SonarQube garantissent une qualité de code constante.
• Les contrôles de livraison automatisés et la collecte de preuves pour répondre aux exigences de conformité et maintenir un pipeline de livraison fiable.