Ceci est l'un des deux articles de PagerDuty publiés sur Continuous. Consultez le second : En continu — Construire, casser et réparer rapidement

Déploiement continu vs. Livraison continue

Il existe un fossé important entre la compréhension des processus et technologies modernes et leur mise en œuvre concrète. Dans le mouvement DevOps, de nombreuses fonctions essentielles, telles que l'orchestration, l'automatisation des déploiements et l'analyse de données, ont été largement adoptées. Cependant, les processus de bout en bout de livraison et de déploiement continus restent moins répandus, non pas par manque de compréhension, mais en raison des contraintes organisationnelles et pratiques. Êtes-vous prêt pour la livraison et le déploiement continus ?

Il existe un déficit dans les définitions de livraison continue et déploiement continu Avant d'approfondir le sujet, il est nécessaire de préciser ma définition. La livraison concerne les étapes jusqu'à la mise en production, mais pas la mise en production directe. Une étape de validation est toujours nécessaire, et quelqu'un doit donner son accord. Le déploiement, quant à lui, désigne la mise en production directe une fois tous les tests réussis. La différence peut paraître minime, mais elle est fondamentale. Le déploiement permet et exige des mises en production quotidiennes. Il implique également un mécanisme de restauration robuste, reposant sur un système d'alertes performant et une analyse approfondie des journaux.

La suite de cet article traitera du déploiement continu (désigné à partir de maintenant par l'acronyme CD).

La mise en œuvre de la CD comporte deux dimensions qui en déterminent la praticité. La première est directement liée à l'application. La seconde concerne l'environnement dans lequel les processus seront déployés.

L'application

Ce que je vais vous dire risque de vous faire réagir. Il n'est pas encore largement admis que l'intégration continue (CI) dépende du type et de l'architecture de votre application. Cependant, vous constaterez que les pipelines CI existants présentent de nombreuses similitudes quant à la nature de leur application. Et les entreprises qui profitent de l'opportunité que représente la CI sans l'avoir encore mise en œuvre se heurtent à un mur.

Les aspects de l'architecture applicative qui empêcheront le déploiement continu (CD) sont les suivants :

1. Faible volume de transactions : Si votre application n'est pas suffisamment sollicitée, il n'y a pas assez d'activité à analyser. Par conséquent, l'impact de toute mise à jour ne sera pas visible à court terme et ses résultats ne seront pas statistiquement fiables.
2. Faible base d'utilisateurs : L'un des avantages du déploiement continu (CD) est de pouvoir déployer plus rapidement de nouvelles fonctionnalités, y compris certaines fonctionnalités jugées à haut risque. Cela aura un impact sur votre base d'utilisateurs, mais l'idée est de ne pas proposer toutes les versions à tous les utilisateurs. Si vous n'avez pas suffisamment d'utilisateurs, vous ne pourrez pas publier de versions pour des sous-segments de votre base d'utilisateurs.
3. Ne pas utiliser de déploiements/architectures Full-Stack Si vous ne déployez pas votre application avec l'ensemble de sa pile logicielle (machine, système d'exploitation, configuration et code), des problèmes surviendront. Premièrement, les développeurs ne disposent pas d'une autonomie suffisante pour les mises à jour, ce qui limite la possibilité de déployer en production sans rencontrer d'obstacles informatiques. Deuxièmement, les mises à jour fiables doivent être déployées sur une infrastructure neuve. Cela évite les problèmes de contamination, assure la prévisibilité et permet de déployer des applications auprès de sous-segments d'utilisateurs. Avec des déploiements full-stack, il suffit de configurer le DNS pour gérer le trafic vers des déploiements compartimentés. L'utilisation de conteneurs simplifie considérablement cette opération.
4. Ne pas exploiter l'architecture de services/microservices : Je ne suggère pas que votre application doive être une application de microservices. En revanche, elle doit distinguer les composants importants comme des objets distincts et indépendants. Cela signifie que vous pouvez déployer des composants individuels sans impacter l'application entière. C'est important car, en déploiement continu (CI/CD), si vous déployez l'application complète, non seulement le processus est lent, mais l'impact de tout problème est bien plus important ; votre capacité de réaction sera également considérablement réduite car vous devrez redéployer l'application entière après la correction, ou redéployer une version précédente.

L'environnement

Un faible nombre de transactions et une base d'utilisateurs réduite sont relatifs à votre marché et aux attentes de vos utilisateurs. Vous devriez pouvoir déterminer assez clairement si vous avez atteint ces objectifs. Au-delà des caractéristiques de votre application, la plupart des organisations tentent d'intégrer le déploiement continu (CD) à une chaîne de distribution existante, ce qui implique de composer avec des processus et des équipes déjà en place. Il est possible de mettre en œuvre les processus du CD sans s'intéresser à l'organisation existante, mais cela conduit généralement à des environnements non viables. Voici quelques éléments clés à prendre en compte :

1. Il ne s'agit pas seulement des développeurs : Bien que de nombreux processus soient dictés par les développeurs, ces derniers ne sont pas les seuls acteurs. Dans les pipelines d'intégration continue et continue (CI/CD), l'accent est mis davantage sur la stratégie que sur l'exécution. Les stratégies d'assurance qualité sont essentielles pour garantir une couverture de tests adéquate avant les mises en production. Une collaboration étroite avec l'équipe informatique permet de s'assurer que les plateformes d'alerte, chargées de signaler rapidement tout problème lié à une mise en production, sont correctement configurées et paramétrées. Dans certains environnements CI/CD, les développeurs ont la possibilité de réagir directement aux problèmes.
2. N'oubliez pas la réponse : On consacre une part disproportionnée du temps à la planification du développement logiciel moderne, au détriment de la simple progression du code. Or, la réussite des itérations futures repose sur une gestion efficace des itérations existantes. Les organisations doivent donc investir un temps considérable dans les processus de restauration et le système de réponse aux problèmes, ce qui relève à la fois d'un problème organisationnel (qui est de garde ?) et d'un problème technologique (minimiser les étapes).

Une solution pour relever ces deux défis consiste à imiter les startups : concevoir l’application avec un processus d’intégration continue dès le départ. Cependant, la plupart des organisations disposant déjà d’applications existantes, cette approche est impossible. La meilleure solution est donc de développer une nouvelle version de l’application en parallèle, en tirant parti de l’intégration continue dès le début. Cela prendra du temps, mais si votre application repose sur une architecture de services et une couche API robuste pour le backend, ce défi devrait être réalisable.

Transformer la magie en réalité, voilà la véritable victoire. Nombre d'organisations ayant réussi leur déploiement continu (CD) ont commencé par des processus comme l'intégration continue. Elles ont affiné leur approche, leurs outils et la structure de leurs équipes, ce qui leur a permis d'aborder sereinement le CD. Elles se sont également concentrées sur l'exécution et la pérennité, et non pas sur la simple multiplication des mises en production.

Sans se lancer à l'aveuglette, le marché des outils vous guidera. Et si votre application se prête au déploiement continu et que vous êtes prêt à l'implémenter correctement, vous êtes prêt pour le déploiement continu.

Ceci est l'un des deux articles de PagerDuty publiés sur Continuous. Consultez le second : En continu — Construire, casser et réparer rapidement