Qu’est-ce que le cycle de vie DevOps ?

Le processus DevOps décrit comment les logiciels passent de l'idéation à la production et au feedback, pour revenir à l'idéation, les équipes de développement et d'exploitation travaillant comme une seule unité collaborative. Il comprend un flux de bout en bout de pratiques et de workflows d'automatisation que les équipes DevOps peuvent utiliser pour planifier, développer, exécuter et optimiser les versions de logiciels.

Les phases du cycle de vie DevOps sont souvent décrites comme faisant partie d'une « boucle infinie » avec les activités de développement sur la gauche et les activités opérationnelles sur la droite, connectées en un seul chemin continu.

Du côté « planifier → code → construire → tester » les exigences logicielles en petits récits utilisateur, valident le code dans les référentiels de code de manière incrémentale (mais fréquente) et utilisent des outils d’intégration continue (CI) pour générer et tester automatiquement chaque code. changement.

Du côté « publier → déployer → exploiter → surveiller », les workflows d'automatisation transmettent les changements à travers les environnements informatiques et sont transmis aux utilisateurs. Parallèlement, les outils d’observabilité suivent la santé du système, la performance des logiciels et le comportement des utilisateurs afin de détecter les problèmes et de mesurer l’impact global.

La boucle infinie souligne que chaque phase du cycle de vie DevOps influence les autres. Les équipes partagent le travail, les connaissances et les responsabilités, au lieu de les transmettre d'un silo à l'autre. La boucle illustre également comment les workflows DevOps peuvent rationaliser les processus de livraison et d’optimisation des logiciels. Idéalement, chaque cycle sera plus rapide, plus sûr et plus automatisé que le précédent.

En tant que tel, le cycle de vie DevOps permet aux entreprises d'aligner les personnes, les processus et les outils afin de fournir des applications logicielles de haute qualité et des expériences utilisateur sans friction.

Chaque phase du cycle de vie DevOps informe et recoupe les autres phases, mais chacune a un objectif clair et un ensemble d'activités associées. Les phases comprennent :

Lors de la phase de planification, les équipes DevOps traduisent les besoins métier et les commentaires des utilisateurs en plans de travail clairs, priorisés et à durée déterminée ainsi qu’en workflows qui guident les activités de développement et d’Opérations dans les phases suivantes. Cette phase clarifie la vision, la portée et la feuille de route d'une version de logiciel ou d'un système afin que chacun comprenne ce qu'il construit, pourquoi c'est important et comment il mesurera le succès.

Les activités de planification typiques peuvent inclure :

• Affiner et trier les backlogs de produits (tels que les nouvelles fonctionnalités, les correctifs et la dette technique).

• Analyser les données fournies par les parties prenantes afin de déterminer les besoins et les contraintes des utilisateurs.

• Décomposer le travail en tâches, en récits utilisateurs (descriptions de fonctionnalités logicielles rédigées du point de vue de l’utilisateur) et en epics (récits d’utilisateurs trop étendus pour être traités dans une seule itération logicielle) afin d’estimer les besoins en ressources et d’identifier les dépendances.

• Définir les indicateurs clés de performance (KPI), les indicateurs de niveau de service (SLI) et les objectifs de niveau de service, afin que les phases ultérieures sachent à quoi ressemble un « bon ».

Au cours de la phase de codage, les développeurs transforment l'infrastructure planifiée et les exigences logicielles en code source fonctionnel, dans une optique d'assurance qualité et d'opérations futures. Il ne s’agit pas seulement d’écrire un nouveau code. Il s’agit également de configurer tous les composants nécessaires pour les processus automatisés de construction, de test, d’intégration et de déploiement plus tard dans le pipeline.

Le processus de codage comprend :

• Écrire du code pour implémenter de nouvelles fonctionnalités, appliquer des correctifs et adresser des besoins non fonctionnels (la sécurité, par exemple).

• Apporter de petites modifications de code incrémentielles à des dépôts partagés au sein de systèmes de contrôle de version (tels que Git et GitHub) à des fins de révision.

• Tester les commits de code afin qu'ils puissent être construits et intégrés de façon fluide à la base de code.

• Ajout ou mise à jour de tests unitaires et composants automatisés afin que les futures exécutions CI puissent valider automatiquement le comportement du code après chaque commit.

Lors de la phase de construction, les modifications du code source sont automatiquement compilées, validées et empaquetées en artefacts de compilation déployables. Les outils DevOps récupèrent les modifications de code depuis le système de contrôle de version, exécutent des vérifications automatisées et produisent des packages (tels que des images de conteneurs Docker et des binaires compilés) versionnés et prêts pour le déploiement ou des tests supplémentaires.

Plus précisément :

• Des scripts automatisés et des outils de création compilent le code source, résolvent et téléchargent les dépendances (y compris les bibliothèques, les cadres et les modules) et relient le tout à un exécutable ou une image.

• Les tests automatisés de base sont exécutés dans le cadre de la version. Si la construction échoue, elle est marquée comme défaillante et reste dans la phase de build. Si la version est acceptée, elle passe à la phase suivante du cycle de vie.

La phase de test — également appelée validation — vise à s’assurer qu’un changement de code se comporte comme prévu dans des conditions réelles. Les équipes DevOps utilisent un ensemble d'outils de test avancés pour valider en permanence que chaque changement est fonctionnel, sécurisé et performant avant qu'il n'avance dans le pipeline ou n'atteigne la production.

En règle générale, les processus de test sont étroitement intégrés dans le pipeline d'intégration continue/de livraison continue (CI/CD), de sorte que les développeurs obtiennent des commentaires rapides et fréquents sur la qualité du code.

L'objectif principal des tests logiciels est d'identifier les défauts le plus tôt possible (lorsqu'ils sont moins chers et plus faciles à corriger) et d'empêcher les versions défectueuses de progresser vers la sortie. Les tests permettent également de vérifier que les nouvelles modifications ne perturberont pas les fonctionnalités existantes, aidant ainsi les développeurs à maintenir la stabilité globale du système à mesure que les produits logiciels évoluent.

La phase de publication constitue une passerelle contrôlée entre la « version testée » et le « déploiement en direct », les modifications apportées au code sont approuvées pour la production et rendues visibles aux utilisateurs cibles. Les équipes de développement préparent un code éprouvé et testé pour le déploiement en l'empaquetant, en validant qu'il est prêt pour la production et en coordonnant comment et quand il déplacera dans les environnements de préproduction et de production.

Les processus de publication courants comprennent :

• Effectuer des contrôles finaux de qualité, de sécurité et de conformité selon des critères d’acceptation prédéfinis.

• Attacher les artefacts de construction à des versions spécifiques et créer des journaux de changement et de la documentation.

• Identifier les vulnérabilités dans la prochaine version et planifier des stratégies d'atténuation (telles que des annulations) pour résoudre les problèmes.

Pendant la phase de déploiement, le code testé et empaqueté est automatiquement acheminé vers les environnements cibles (préproduction (staging) ou production). Les outils de gestion de la configuration et d'infrastructure en tant que code (IaC) — qui utilisent des fichiers de configuration et des langages de codage descriptifs de haut niveau pour automatiser la mise en service et l'orchestration de l'infrastructure pour les versions logicielles — aident les équipes DevOps à garantir que les logiciels sont livrés de manière fiable et reproductible.

Le déploiement est généralement piloté par la livraison continue (CD) et les plateformes de conteneurisation (Kubernetes, par exemple) qui orchestrent les processus de déploiement de logiciels (extraction des artefacts de construction, mise à jour des conteneurs et des binaires, exécution des tests finaux et basculement du trafic vers la nouvelle version).

Les équipes DevOps utilisent souvent différentes stratégies de déploiement pour s'assurer que les nouvelles versions sont introduites progressivement et peuvent être retirées rapidement, si nécessaire.

Avec le déploiement bleu-vert, par exemple, les applications sont déployées dans deux environnements de production parallèles, et chaque environnement exécute une version différente de l’application. L'environnement « bleu » gère l'application en direct, tandis que l'environnement « vert » gère les tests et la validation des nouvelles versions de l'application. Lorsque la nouvelle itération passe, l’environnement vert devient l’environnement de direct, et l’environnement bleu reste inactif, mais disponible, pour gérer les annulations.

Avec les déploiements canari, les équipes déploient des applications à un petit sous-ensemble d’utilisateurs — ou « canaris » — pour une surveillance et des tests en environnement réel avant de déployer l’application à l’ensemble de la base d’utilisateurs.

De la même manière que les canaris ont été utilisés pour avertir les mineurs de charbon de la présence de gaz toxiques, les déploiements de canaris avertissent les équipes de développement des défauts des applications sans risquer de provoquer des problèmes de performance à grande échelle qui affectent chaque utilisateur. Si l'application fonctionne bien avec le groupe Canary, les développeurs l'étendent progressivement à de plus grands groupes jusqu'à ce qu'elle soit accessible à tous les utilisateurs.

La phase d’exploitation vise à garantir la stabilité, la performance, la sécurité et la disponibilité des systèmes opérationnels pour les utilisateurs réels avec des workloads réelles. Ce n'est pas la « fin » du cycle de vie des applications. Au contraire, il réinjecte les données et les informations vers les étapes antérieures.

À cette étape, les équipes DevOps :

• Exécutent et supervisent les applications dans l’environnement de production, y compris les services d'infrastructure et les dépendances associés.

• Gèrent les processus de planification de la capacité et de mise à l'échelle afin que les flux de trafic ne se dégradent pas au fil du temps.

• Détectent et trient les problèmes, corrigez les goulots d’étranglement des performances et appliquez des correctifs ou des annulations si nécessaire.

• Appliquent des correctifs de sécurité et imposez des pratiques de gouvernance (telles que les contrôles d’accès et les audits de conformité) pour optimiser la sécurité du système.

Lors de la phase de surveillance, les équipes observent en permanence les applications et l’infrastructure en production afin de détecter les problèmes, de comprendre le comportement réel des utilisateurs et d’envoyer des informations sur le développement et les opérations.

Les équipes DevOps collectent des données d'observabilité (indicateurs, logs et traces) ainsi que d'autres informations provenant d'applications, serveurs, réseaux et bases de données afin de suivre les performances en temps réel. Ils définissent des seuils et des alertes afin que les anomalies (telles qu'une latence élevée de l'API ou des modèles d'accès suspects) déclenchent des notifications pour une enquête et une résolution rapides.

Si les outils de surveillance détectent un défaut logiciel ou un problème d’utilisabilité, ils transmettent les informations aux systèmes de suivi des incidents et aux backlogs, afin que les équipes puissent ajuster les itérations suivantes.​

La boucle infinie n’inclut pas explicitement de phase « sécurisée », mais les pipelines DevOps impliquent souvent des pratiques et des technologies qui intègrent des mesures de sécurité tout au long du cycle de vie.

C'est là que DevSecOps entre dans le cadre des exigences.

DevSecOps — abréviation de développement, sécurité et opérations — est une pratique de développement logiciel qui déplace les protocoles de sécurité de la droite (extrémité) à la gauche (début) du cycle de vie du développement. Avec shift-left, les développeurs implémentent des protocoles de sécurité (tels que le chiffrement des données, la validation des entrées, les contrôles d’accès basés sur les rôles et l’authentification multifacteur) pendant qu’ils écrivent le code.

Le DevSecOps intègre également des activités de « shift right », étendant les pratiques de sécurité aux environnements de production post-déploiement. Les pratiques Shift-right donnent la priorité à la surveillance, aux tests et à la protection des applications au moment de l'exécution, dans des conditions réelles. Ils complètent la sécurité shift-left en créant une boucle de commentaires continus où les problèmes de sécurité découverts en production informent les phases de développement antérieures.

Utilisées conjointement, les fonctions de sécurité shift-left et shift-right permettent aux entreprises d'intégrer des contrôles de sécurité à chaque phase du cycle de vie DevOps. Une double stratégie de sécurité, « shift-everywhere », aide les équipes DevOps à mettre en place à la fois la prévention précoce et la détection et la réponse aux menaces post-déploiement, améliorant ainsi la posture de sécurité globale et favorisant une amélioration continue.

Le cycle de vie DevOps représente une évolution des approches plus traditionnelles du développement logiciel, telles que le waterfall et l’agile.

Waterfall est une méthodologie de développement qui suit un processus linéaire et séquentiel où chaque phase du cycle de vie — collecte des exigences, conception, mise en œuvre, test, déploiement et maintenance — doit être entièrement achevée et approuvée avant le début de la suivante. Elle privilégie la planification proactive, la documentation détaillée et la prévisibilité, ce qui le rend adapté aux projets avec des exigences stables, bien définies et peu de changements anticipés (par exemple, les projets gouvernementaux et liés à la santé).

Waterfall permet un contrôle strict des processus, mais les équipes de développement sont cloisonnées. Effectuer des modifications après la fin d’une phase est coûteux et chronophage. En bref, Waterfall a du mal à être agile.

Agile est une méthodologie de développement itérative qui permet de réaliser de petites étapes fonctionnelles de travail par cycles courts (appelés « sprints »). Il privilégie la planification adaptative, la livraison anticipée et l’amélioration continue basée sur les retours des parties prenantes, permettant aux équipes de développement de répondre rapidement aux exigences et conditions changeantes.

Les méthodologies agiles peuvent s'avérer efficaces dans les environnements dynamiques, tels que les startups. Ils atténuent la rigidité linéaire des approches en cascade grâce à des équipes interfonctionnelles qui donnent la priorité à la fonctionnalité des logiciels plutôt qu'à une documentation exhaustive. Cependant, les approches agiles se concentrent sur le processus de développement logiciel , à l’exclusion des processus opérationnels.  

DevOps offre une pratique culturelle et technique moderne qui intègre les équipes de développement et d'exploitation, en s'appuyant sur des outils CI/CD (tels que GitLab) pour l'automatisation des tests, du déploiement et de la surveillance. Contrairement à l'agile et au waterfall, les pratiques DevOps peuvent aider les entreprises à accélérer les versions de logiciels et à créer des applications qui restent performantes et agiles dans les architectures microservices hautement dynamiques et les environnements informatiques basés sur le cloud d'aujourd'hui.

Les 7 C offrent une autre façon de conceptualiser le cycle de vie DevOps comme le produit de sept processus continus.

Le développement continu implique la planification et le codage de logiciels, les développeurs décomposant le processus en itérations plus petites et plus faciles à gérer. Les développeurs stockent les modifications dans des systèmes de contrôle de version et alignent en permanence leur code sur les exigences des parties prenantes, ce qui aide les équipes à minimiser les risques et à s'adapter rapidement aux changements.

L'intégration continue permet de fusionner les modifications de code de plusieurs développeurs dans un référentiel partagé et de déclencher automatiquement des builds après chaque validation. Il permet aux équipes DevOps d'améliorer en permanence leurs applications logicielles, de recevoir des commentaires constructifs, de détecter et de corriger les erreurs avant qu'elles n'affectent les performances des logiciels et de fournir des logiciels de meilleure qualité selon des calendriers plus prévisibles.

Les tests continus permettent aux développeurs de lancer automatiquement des avis et des protocoles de test (tels que les unit tests). Il utilise des outils de test pour examiner en permanence le code intégré afin de détecter les bogues, les défauts d'utilisation et les problèmes de performance. Les tests continus donnent aux développeurs les commentaires rapides dont ils ont besoin pour améliorer le logiciel sans retarder le cycle de vie.

La livraison continue automatise la livraison des applications et des modifications validées de la base de code (mises à jour, correctifs et même de nouvelles fonctionnalités) à tous les environnements d'infrastructure nécessaires pour des tests ultérieurs. Les versions de code qui réussissent tous les tests d'intégration et les étapes de validation sont empaquetées et livrées dans des référentiels de code, qui centralisent et stockent les packages de code dans un état déployable.

Le déploiement continu va encore plus loin en déployant automatiquement chaque modification approuvée vers la production, sans intervention humaine. Lorsque les mises à jour du code sont testées, validées et approuvées, les outils de déploiement continu déplacent l'artefact logiciel vers un environnement de préproduction ou vers des serveurs publics et des plateformes de distribution (tels que des magasins d'applications) où les utilisateurs peuvent y accéder.

Un retour d’information continu exige que les équipes DevOps s’appuient sur le suivi des données, l’expérience utilisateur et les contributions des parties prenantes afin d’affiner le backlog produit et de déterminer l’urgence de chaque amélioration.

La surveillance continue permet de suivre les performances des applications et de l'infrastructure en temps réel et d'identifier les problèmes de manière proactive afin de maintenir la fiabilité du système. La plupart des outils de surveillance visualisent les données du pipeline CI/CD à l'aide de tableaux de bord, ce qui augmente la visibilité de la pile technologique et permet des optimisations basées sur les données.

Les outils d'automatisation gèrent le provisionnement de l'infrastructure, la mise à l'échelle des Ressources, les sauvegardes des données, le routage du trafic et la maintenance, permettant aux équipes DevOps d'appliquer continuellement des commentaires aux nouvelles itérations d'application.

Tirer parti des meilleures pratiques DevOps peut apporter de nombreux avantages aux entreprises, notamment :