Le cycle de vie du DevOps (parfois appelé pipeline de livraison continue, lorsqu’il est représenté de manière linéaire) est une série de processus de développement itératifs et automatisés, ou flux de travail, exécutés dans le cadre d’un cycle de vie de développement plus vaste, automatisé et itératif, conçu pour optimiser la livraison rapide de logiciels de haute qualité. Le nom et le nombre de flux de travail peuvent varier en fonction des personnes interrogées, mais ils se résument généralement à ces six étapes :
Planification (ou idéation)
Dans ce flux de travail, les équipes définissent les nouvelles fonctionnalités et les nouvelles fonctionnalités pour la prochaine version, en s’appuyant sur les commentaires et études de cas des utilisateurs finaux prioritaires, ainsi que sur les contributions de toutes les parties prenantes internes. L’objectif à l’étape de la planification est de maximiser la valeur commerciale du produit en produisant un backlog de fonctionnalités qui, une fois livrées, produisent un résultat souhaité ayant de la valeur.
Développement
Il s’agit de l’étape de programmation, où les développeurs testent, codent et construisent de nouvelles fonctionnalités améliorées, basées sur des scénarios d’utilisation et des éléments de travail dans le backlog. Des pratiques telles que le développement piloté par les tests (TDD), la programmation en binôme et les examens de code par les pairs, entre autres, sont courantes. Les développeurs utilisent souvent leurs stations de travail locales pour effectuer la “boucle interne” d’écriture et de test du code avant de l’envoyer dans le pipeline de livraison continue.
Intégration (ou construction, ou intégration continue et livraison continue – CI/CD)
Comme mentionné précédemment, dans ce flux de travail, le nouveau code est intégré au code existant, puis testé et encapsulé dans un exécutable pour le déploiement. Les activités d’automatisation courantes comprennent la fusion des modifications de code dans une copie “maître”, la vérification de ce code à partir d’un référentiel de code source et l’automatisation de la compilation, des tests unitaires et de l’encapsulation en un exécutable. La meilleure pratique consiste à stocker la sortie de la phase de CI dans un référentiel binaire pour la phase suivante.
Déploiement (généralement appelé déploiement continu)
Ici, la sortie de construction en temps d’exécution (provenant de l’intégration) est déployée dans un environnement d’exécution – généralement un environnement de développement où des tests d’exécution sont effectués pour la qualité, la conformité et la sécurité. Si des erreurs ou des défauts sont trouvés, les développeurs ont la possibilité d’intercepter et de remédier à tout problème avant que les utilisateurs finaux ne les voient. Il existe généralement des environnements de développement, de test et de production, chaque environnement nécessitant des points de contrôle de qualité progressivement “plus stricts”. Une bonne pratique pour le déploiement dans un environnement de production consiste généralement à le déployer d’abord auprès d’un sous-ensemble d’utilisateurs finaux, puis éventuellement auprès de tous les utilisateurs une fois la stabilité établie.
Opérations
Si la livraison des fonctionnalités dans un environnement de production est caractérisée comme le “jour 1”, une fois que les fonctionnalités sont en cours d’exécution en production, les opérations du “jour 2” se produisent. La surveillance des performances, du comportement et de la disponibilité des fonctionnalités garantit que celles-ci sont en mesure de fournir une valeur ajoutée aux utilisateurs finaux. Les opérations veillent à ce que les fonctionnalités fonctionnent correctement et qu’il n’y ait aucune interruption de service, en veillant à ce que le réseau, le stockage, la plateforme, les calculs et la posture de sécurité soient tous en bonne santé ! En cas de problème, les opérations veillent à ce que les incidents soient identifiés, que le personnel approprié soit alerté, que les problèmes soient identifiés et que les correctifs soient appliqués.
Apprentissage (parfois appelée rétroaction continue)
Il s’agit de la collecte des commentaires des utilisateurs finaux et des clients sur les fonctionnalités, les performances et la valeur ajoutée pour les activités de planification visant à améliorer les fonctionnalités et les fonctionnalités de la prochaine version. Cela comprend également tout l’apprentissage et les éléments du backlog provenant des activités d’exploitation, qui pourraient permettre aux développeurs d’éviter de manière proactive tout incident passé qui pourrait se reproduire à l’avenir. C’est à ce moment-là que la boucle se boucle avec la phase de planification et que nous nous améliorons continuellement !
Trois autres flux de travail continus importants se produisent entre ces flux de travail :
Test continu
Les cycles de vie classiques de DevOps comprennent une phase de “test” distincte qui intervient entre l’intégration et le déploiement. Cependant, DevOps a évolué de telle sorte que certains éléments des tests peuvent avoir lieu dans la planification (développement axé sur le comportement), le développement (tests unitaires, tests de contrat), l’intégration (analyses de code statiques, analyses CVE, linting), le déploiement (tests de fumée, tests de pénétration, tests de configuration), les opérations (tests de chaos, tests de conformité) et l’apprentissage (tests A/B). Les tests sont une forme puissante d’identification des risques et des vulnérabilités, et offrent une opportunité pour les services informatiques d’accepter, d’atténuer ou de remédier aux risques.
Sécurité
Alors que les méthodologies de cascade et les implémentations agiles “ajoutent” des flux de travail de sécurité après la livraison ou le déploiement, DevOps s’efforce d’intégrer la sécurité dès le début (planification) – lorsque les problèmes de sécurité sont les plus faciles et les moins coûteux à résoudre – et en continu tout au long du reste du cycle de développement. Cette approche de la sécurité est appelée déplacement vers la gauche (ce qui est plus facile à comprendre si vous regardez la figure 1). Certaines organisations ont eu moins de succès dans ce déplacement vers la gauche que d’autres, ce qui a conduit à l’émergence de DevSecOps (voir ci-dessous).
Conformité
La conformité réglementaire (gouvernance et risques) doit également être traitée de manière optimale dès le début et tout au long du cycle de développement. Les industries réglementées sont souvent tenues de fournir un certain niveau d’observabilité, de traçabilité et d’accès aux fonctionnalités livrées et gérées dans leur environnement opérationnel en temps d’exécution. Cela nécessite une planification, un développement, des tests et une application des politiques dans le pipeline de livraison continue et dans l’environnement d’exécution. La traçabilité des mesures de conformité est extrêmement importante pour prouver la conformité aux auditeurs externes.
