Ceci est l'un des deux articles de PagerDuty sur Continu. Découvrez notre deuxième : Continu — Construire, détruire et réparer rapidement

Déploiement continu vs. livraison continue

Il existe un écart important entre la compréhension des processus et des technologies modernes et leur mise en pratique. Dans le mouvement DevOps, de nombreuses fonctions essentielles ont été largement adoptées, telles que l'orchestration, l'automatisation des versions et l'analyse. Mais les processus de bout en bout de livraison et de déploiement continus n'ont pas été aussi largement adoptés, ce qui n'est pas une question de compréhension. Il est dicté par les éléments organisationnels existants et par la praticité. Êtes-vous prêt pour la livraison et le déploiement continus ?

Il y a un déficit dans les définitions de livraison continue et déploiement continu . Avant de plonger plus profondément dans le sujet, je dois donner ma définition. La livraison signifie jusqu'à la publication, mais pas directement en production. Il y a toujours une porte, et quelqu'un doit appuyer sur le bouton Go. Le déploiement fait référence à ce qui est mis directement en production une fois tous les tests réussis. La différence peut sembler triviale, mais elle ne l'est pas. Le déploiement permet non seulement mais nécessite également des publications quotidiennes. Il implique également un mécanisme de retour en arrière très robuste, qui repose fortement sur une excellente analyse des alertes et des journaux.

Le reste de cet article portera sur le déploiement continu (appelé à partir de ce point CD).

Le CD a deux dimensions qui déterminent sa praticabilité. La première est directement liée à l'application. La seconde est liée à l'environnement dans lequel les processus vont être mis en œuvre.

L'application

Ce que je vais vous dire, ce sont des « mots de combat ». Il n’est pas (encore) largement admis que le CD dépend du type et de l’architecture de votre application. Cependant, vous constaterez que les pipelines CD qui existent déjà partagent de nombreuses similitudes dans la nature de leur application. Et les entreprises qui sont opportunistes en matière de CD mais ne l’ont pas encore mis en œuvre se heurtent à un mur.

Les aspects de l’architecture applicative qui empêcheront le CD sont :

1. Faible volume de transactions : Si votre application n'a pas suffisamment d'activité, il n'y aura pas assez d'activité pour en tirer des enseignements. Ainsi, l'impact d'une version ne sera pas apparent à court terme. Et son résultat ne sera pas statistiquement précis.
2. Faible base d'utilisateurs : L'un des avantages de la livraison continue est que vous pouvez publier de nouvelles fonctionnalités plus rapidement, et peut-être certaines fonctionnalités considérées comme à haut risque. Cela aura un impact sur votre base d'utilisateurs, mais l'idée est que vous choisirez de ne pas fournir toutes les versions à tous les utilisateurs. Si vous n'avez pas suffisamment d'utilisateurs, vous ne pourrez pas produire 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 en tant que machine de pile complète, système d'exploitation, configuration et code, des problèmes surviendront. Le premier est que cela ne permet tout simplement pas aux développeurs d'avoir suffisamment d'autonomie avec les versions d'application, ce qui limite à lui seul la capacité de déploiement en production sans obstacle informatique. Ensuite, les versions fiables doivent être déployées sur une nouvelle infrastructure. Cela évite les problèmes de contamination, permet une prévisibilité et prend également en charge la capacité de publier des applications sur des sous-segments de la base d'utilisateurs. Avec les déploiements full-stack, c'est aussi simple que de laisser le DNS contrôler le trafic vers des déploiements compartimentés. L'utilisation de conteneurs rend cela beaucoup plus facile.
4. Ne pas exploiter l'architecture des services/microservices : Je ne veux pas dire que votre application doit être une application de microservices. Mais elle doit distinguer les composants d'application volumineux en tant qu'objets distincts et mutuellement exclusifs. Cela signifie que vous pouvez déployer des composants individuels sans impacter l'ensemble de l'application. La raison pour laquelle cela est important est que dans le CD, si vous publiez l'application dans son intégralité, non seulement c'est lent, mais l'impact de tout problème est bien pire - et votre capacité à réagir prendra beaucoup plus de temps car vous devrez redéployer l'intégralité de l'application après l'implémentation d'un correctif, ou redéployer une version précédente.

L'environnement

Les faibles volumes de transactions et le faible nombre d'utilisateurs dépendent de votre marché et des attentes de vos utilisateurs. Vous devriez savoir clairement si vous avez satisfait ces chiffres ou non. Au-delà des attributs de votre application, la plupart des organisations tentent de mettre en œuvre la CD dans une chaîne de distribution existante, ce qui signifie qu'il existe des processus et des personnes avec lesquels il faut composer. Il est possible de mettre en œuvre des processus de CD sans s'occuper de l'organisation existante, mais cela conduit généralement à des environnements non durables. Voici quelques éléments clés à prendre en compte :

1. Il n’y a pas que les développeurs : Bien que de nombreux processus soient dictés par les développeurs, ils ne sont pas les seuls à jouer un rôle. Dans les pipelines de développement continu, beaucoup plus d'efforts sont consacrés à la stratégie qu'à l'exécution. Les stratégies d'assurance qualité sont essentielles pour garantir une couverture de test adéquate avant la publication des versions. Et une collaboration étroite entre les services informatiques garantira que les plates-formes d'alerte, chargées de vous informer rapidement en cas de problème avec une version, sont correctement ciblées et configurées. Dans certains environnements de développement continu, les développeurs ont la possibilité de répondre directement aux problèmes.
2. N'oubliez pas la réponse : Une part disproportionnée du temps consacré à la planification de la livraison de logiciels modernes est consacrée à la progression du code. Mais le succès des itérations futures dépend de la réponse réussie aux itérations existantes. Les organisations doivent consacrer beaucoup de temps aux processus de retour en arrière et au système de réponse aux problèmes, ce qui est à la fois un problème organisationnel (qui est de garde) et un problème technologique (prendre le moins d'étapes possible).

Une approche pour répondre à ces deux défis consiste à choisir d’imiter ce que les startups sont capables de faire : créer l’application avec le processus CD dès le premier jour. Étant donné que la plupart des organisations disposent déjà d’applications existantes, cela n’est pas possible. La meilleure façon d’y parvenir est de créer une nouvelle version de l’application en parallèle, en exploitant le CD dès le départ. Cela prendra du temps, mais si votre application a été conçue avec une architecture de services et une couche API solide pour le backend, cela ne devrait pas être insurmontable.

Transformer la magie en réalité est la vraie victoire. Et de nombreuses organisations qui ont mis en œuvre avec succès la CD ont commencé par des processus tels que l'intégration continue. Elles ont affiné leur approche, leurs outils et la structure de leur équipe d'une manière qui leur a donné la confiance nécessaire pour passer à la CD. Elles se sont également concentrées sur l'exécution et la durabilité, et pas seulement sur davantage de versions directement en production.

Sans avoir à se lancer dans l'aventure, le marché des outils ouvrira la voie. Et si votre application se prête au déploiement continu et que vous êtes prêt à le faire correctement, vous êtes prêt pour un déploiement continu.

Ceci est l'un des deux articles de PagerDuty sur Continu. Découvrez notre deuxième : Continu — Construire, détruire et réparer rapidement