Chez AWS, les déploiements sont complètement automatisés et ne nécessitent quasiment pas d’intervention

Il n’est pas surprenant qu’Amazon Web Services soit en avance sur le reste du monde en matière d’intégration et de déploiement continu de logiciels, d’autant plus qu’elle se présente comme un lieu incontournable pour les organisations qui cherchent à mettre pleinement en pratique la CI/CD. Le géant des services en ligne a toutefois porté ses propres pratiques internes de CI/CD à un niveau supérieur, ce qui en fait essentiellement une opération totalement « sans intervention ».

Chez AWS, les changements dans les micro-services sont automatiquement déployés en production « plusieurs fois par jour par des pipelines de déploiement continu », selon Clare Liguori, ingénieure logiciel principale chez AWS. Cette stratégie centrée sur les pipelines est la clé de sa capacité à continuer à pomper du code. Dans un article récent, elle explique comment Amazon fait passer les logiciels par ses phases rapidement et automatiquement. Il est remarquable que les gestionnaires et les développeurs ne passent que peu ou pas de temps à superviser les déploiements et à surveiller les journaux et les mesures pour en évaluer l’impact. « Les déploiements automatisés en cours n’ont généralement pas de développeur qui surveille activement chaque déploiement, vérifie les mesures et recule manuellement s’il y a des problèmes. Ces déploiements sont complètement indépendants. Le système de déploiement surveille activement une alarme pour déterminer s’il doit automatiquement annuler un déploiement. »

Les étapes de vérification

Le code logiciel d’AWS passe par quatre grandes étapes, avec des mécanismes et des processus automatisés qui vérifient et revérifient les résultats à chaque étape :

• Changements de source, validés : les pipelines d’Amazon « valident automatiquement et déploient en toute sécurité tout type de changement de source en production, et pas seulement les changements de code d’application », explique Clare Liguori. « Ils peuvent valider et déployer des changements aux sources tels que les actifs statiques du site web, les outils, les tests, l’infrastructure, la configuration et le système d’exploitation sous-jacent de l’application. Tous ces changements sont contrôlés par version dans des dépôts de code source individuels. Les dépendances du code source, telles que les bibliothèques, les langages de programmation et les paramètres comme les ID AMI, sont automatiquement mises à jour vers la dernière version au moins une fois par semaine. »
• Build, un processus de travail d’équipe : le code est compilé et testé à l’unité, poursuit l’ingénieure. « Les équipes peuvent choisir les cadres de tests unitaires, les linters et les outils d’analyse statique qui leur conviennent le mieux. En outre, les équipes peuvent choisir la configuration de ces outils, comme la couverture de code minimale acceptable dans leur cadre de tests unitaires. »
• Tester et tester encore : le pipeline exécute les dernières modifications par le biais d’un ensemble de tests et de contrôles de sécurité du déploiement. « Ces étapes automatisées empêchent les défauts ayant un impact sur les clients d’atteindre la production et limitent l’impact des défauts sur les clients s’ils atteignent la production. »
• La production, qui intègre le “temps de cuisson” : le code est mis en production par étapes dans toutes les régions de l’AWS, afin d’atténuer les problèmes qui surviennent. « Nous avons constaté que le regroupement des déploiements par “vagues” de taille croissante nous aide à atteindre un bon équilibre entre le risque et la vitesse de déploiement », explique Clare Liguori. « Chaque étape de la vague dans le pipeline orchestre les déploiements vers un groupe de régions, avec des changements promus d’une vague à l’autre. De nouveaux changements peuvent entrer dans la phase de production du pipeline à tout moment. » Elle ajoute que chaque déploiement de production a un “temps de cuisson” pour en évaluer l’impact, car « parfois, l’impact négatif causé par un déploiement n’est pas facilement visible. C’est un processus lent ; il n’apparaît pas immédiatement pendant le déploiement, surtout si le service est alors peu sollicité. Chaque étape du pipeline a un temps de cuisson, c’est-à-dire que le pipeline continue à surveiller l’alarme globale de l’équipe pour tout impact à combustion lente après un déploiement et avant de passer à l’étape suivante ».

AWS ne se contente pas d’automatiser ses processus et d’espérer le meilleur : ses pratiques de déploiement automatisé sont soigneusement élaborées, réglées et testées, observe l’ingénieure, « en fonction de ce qui nous aide à équilibrer la sécurité et la vitesse de déploiement. En même temps, nous voulons minimiser le temps que les développeurs doivent passer à s’inquiéter des déploiements ».

Source : ZDNet.com