Ceci est l'un des deux articles de PagerDuty sur Continu. Découvrez notre premier : Êtes-vous prêt pour un déploiement continu ?

Surcharge continue

Si vous prêtez attention aux conversations sur la livraison de logiciels modernes, vous avez parfois l'impression d'être frappé à la tête avec une baguette magique continue. Intégration continue, livraison continue, Déploiement continu , Documentation continue, etc. L'idée est si simple qu'elle en est frustrante : aller vite. Mais les avantages d'aller vite vont bien au-delà de la création de nouvelles versions pour votre base d'utilisateurs. La plus grande valeur est peut-être à long terme, et se cache dans la façon dont vous pouvez casser l'application en continu sans crainte, car vous pouvez également la réparer en continu.

Que vous apporte la rapidité à long terme ? Sur une période de trois mois, pouvez-vous dire quelque chose de plus sur votre pipeline que « nous avons eu plus de builds » ? Plus de versions, c’est une chose. Mais une chaîne de livraison qui ne soutient pas l’innovation n’est rien d’autre qu’un moyen de passer du point A au point B. Pour démontrer un réel succès dans une organisation axée sur DevOps, vous devez être en mesure de montrer que la qualité et les fonctionnalités de votre logiciel augmentent également, ce qui signifie que toutes les fonctionnalités intéressantes qui se trouvent enfouies dans votre backlog finissent par remonter au sommet.

Pourquoi Continu ?

Continuous nous permet de mettre en œuvre nos applications en toute confiance, car nous savons que nous pouvons rapidement alerter sur tout problème et effectuer une itération vers une nouvelle version pour le résoudre. Les équipes peuvent désormais mettre en œuvre une fonctionnalité qu'elles mouraient d'envie d'implémenter mais qu'elles ont évitée en raison du risque perçu.

En réalité, le principe de « break/fail fast » signifie que vous pouvez être opportuniste quant à vos fonctionnalités, ce qui est probablement le seul moyen de créer des fonctionnalités qui répondent aux demandes des utilisateurs en temps quasi réel, ou d’apprendre comment les nouvelles fonctionnalités impactent l’application et son adoption. Sans fail fast, les applications peuvent être condamnées à des versions purement linéaires, quelle que soit la durée de vos sprints. Et elles peuvent tomber dans le même piège que nous connaissons tous trop bien : la stagnation, également connue sous le nom de ralentissement éventuel des nouvelles fonctionnalités au profit de très petits changements apportés aux fonctionnalités existantes. Lorsque cela se produit, votre application devient obsolète et ne peut être résolue que par des réécritures majeures, une refactorisation ou de nouvelles applications complètes. Ce n’est pas du tout une continuité, ou du moins pas une continuité durable.

Sorties de Canary

L'extrême de la méthode « fail fast » et « fix fast » est ce que l'on appelle les versions canaries. Dans une version canary, vous disposez d'une ou plusieurs nouvelles versions de l'application en parallèle de la version de production existante. Une fois la ou les versions terminées, vous détournez tout ou partie du trafic de la production vers les nouveaux environnements de version. Le but des sous-segments est d'effectuer des tests A/B sur de légères variations des versions.

Si quelque chose ne va pas avec une version Canary, vous le saurez rapidement grâce à un mécanisme d'alerte robuste. Vous ramènerez ensuite le trafic en production. L'exercice peut avoir un léger impact négatif sur vos utilisateurs, mais la réponse est si rapide qu'elle ressemble à un problème technique. De nouvelles fonctionnalités pourraient être développées dans des délais d'une journée.

Une fois que vous en savez plus sur la nouvelle fonctionnalité, vous pouvez soit l'abandonner, soit la corriger dans cette version Canary, puis la tester à nouveau rapidement. Il s'agit véritablement d'un modèle itératif. Et il peut être configuré non pas comme une seule itération, mais plutôt comme plusieurs itérations exécutées en parallèle.

Ce modèle peut également être considéré comme l'extrême du déploiement continu, bien que sans certains des tests fonctionnels et système automatisés avant les versions. Ces processus peuvent être trop longs pour prendre en charge le concept. Il suppose quelques éléments. Le plus important est que votre application dispose d'une base d'utilisateurs et d'un volume suffisamment élevés pour prendre en charge des tests rapides de nouvelles fonctionnalités.

Je n'ai pas compris comment cela peut fonctionner avec une application de microservices hautement distribuée, mais je suis sûr que c'est possible, si vous avez :

Les outils pour y parvenir

Bien entendu, une approche aussi avancée de la gestion des versions et des architectures d'applications nécessite des outils performants pour la mettre en œuvre. Et les trois principaux outils pour une gestion rapide des échecs sont les suivants :

1. Automatisation des versions : Votre outil d'automatisation des versions doit être capable de gérer plusieurs versions à la fois. Elles le font toutes, mais ce n'est pas ce que je veux dire. La prise en charge de plusieurs versions parallèles nécessite une très bonne gestion des états et des tableaux de bord pour visualiser les versions. Sans cette visibilité, il est très difficile de savoir où se trouvent les versions et quand elles sont annulées, ce qui peut entraîner de graves problèmes. Et la surcharge supplémentaire peut ne pas valoir le coup.
2. Environnements Cloud à la demande : L’infrastructure nécessaire à cette prise en charge n’est pas une question de puissance, mais de flexibilité. La plateforme en tant que service (PaaS) est la forme d’infrastructure la plus adaptée pour prendre en charge les versions Canary, car avec le PaaS, vous provisionnez à partir d’un pool de ressources, et non de machines virtuelles réelles. Cela rend le provisionnement plus rapide, mais aussi plus facile à gérer, car vous n’avez pas à vous soucier de l’orchestration, etc. La plupart des environnements PaaS prennent également en charge l’échange de trafic plus facile. Avec l’infrastructure en tant que service (IaaS), vous devrez contrôler cela via votre DNS ou votre équilibreur de charge, ce qui constitue probablement une étape supplémentaire. Cependant, il n’y a aucune raison pour que l’IaaS soit exclu des processus de démarrage rapide, en particulier si vous exploitez une technologie de conteneur comme Docker, qui le rend presque aussi simple que le PaaS. Dans le cas d’IaaS ou de PaaS, les développeurs doivent pouvoir créer et supprimer autant d’environnements qu’ils le souhaitent, et ce à la demande. Si l’obtention d’environnements est limitée, il n’y a aucun moyen d’obtenir le parallélisme ou de répondre aux problèmes avec une nouvelle version mise à jour. Les processus que je propose nécessitent des déploiements full-stack, donc le déploiement sur des environnements existants n'est pas non plus une option. Avec un processus de publication et de retour en arrière aussi rapide, il est très facile d'accumuler des variables qui contamineraient les environnements persistants.
3. Alerte : La journalisation de vos environnements est une chose. Il est important d'implémenter la journalisation, mais surtout pour les données historiques. Cependant, dans les versions Canary, l'historique est trop tardif. Les réponses à ce qui se passe dans chaque build doivent être rapides et la durée de vie d'une itération est très courte. Vous avez donc besoin d'une plate-forme d'alerte très puissante qui peut vous envoyer des alertes au fur et à mesure qu'elles se produisent. Cependant, la plate-forme d'alerte doit également être intelligente. En raison de la fréquence et du nombre de versions en parallèle, trop d'informations peuvent facilement devenir un problème ; ainsi, la réponse à tout problème nécessite un long processus de filtrage.

Ce n’est pas que de la technologie

Les concepts de publication plus rapide, de rupture plus rapide et de correction plus rapide ne sont pas complexes. Mais leur mise en œuvre dans des environnements existants peut l'être. Et c'est là que tout développeur, responsable des opérations et de l'assurance qualité expérimenté sait qu'il ne suffit pas d'activer le commutateur de publication Canary.

La mise en œuvre est un parcours, mais le processus ci-dessus est un objectif. Et ce qui est bien avec le processus déjà populaire d’intégration continue, c’est que le processus expérimental d’échec et de retour en arrière peut être mis en œuvre dans des environnements d’intégration. Dans ce cas, l’impact ne concerne que votre équipe interne. Dans ce cas, l’impact affectera principalement l’assurance qualité, car elle sera responsable des tests des versions dès leur création, de sorte que le plus grand changement organisationnel se situe à ce niveau. (Toujours bien moins que la mise en œuvre à l’échelle de l’équipe et en production.)

En fin de compte, les outils sont disponibles pour créer plus rapidement, échouer plus rapidement et réparer plus rapidement. Ce processus augmentera non seulement le nombre de builds que vous effectuez par an, mais aussi l'innovation qui peut avoir lieu pour produire de nouvelles fonctionnalités et une meilleure qualité. Étant donné que les outils existent déjà, la tâche incombe à l'équipe de trouver un chemin entre ses processus de publication existants et de nouveaux processus.

Ceci est l'un des deux articles de PagerDuty sur Continu. Découvrez notre premier : Êtes-vous prêt pour un déploiement continu ?