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

Surcharge continue

Si vous prêtez attention aux discussions sur la livraison de logiciels modernes, vous aurez parfois l'impression d'être frappé à la tête par une baguette magique. Intégration continue, livraison continue, Déploiement continu Documentation continue, etc. L'idée est si simple qu'elle en devient frustrante : aller vite. Mais les avantages de cette rapidité vont bien au-delà de la simple génération de builds pour votre base d'utilisateurs. Le plus grand avantage réside peut-être dans le long terme, et réside dans la possibilité de casser l'application en continu sans crainte, car vous pouvez également la corriger en continu.

Qu'est-ce que la rapidité vous apporte à long terme ? Sur une période de trois mois, pouvez-vous dire quelque chose de plus concernant votre pipeline que « Nous avons eu plus de builds » ? Plus de versions, c'est une chose. Mais une chaîne de livraison qui ne favorise pas l'innovation n'est rien d'autre qu'un moyen d'aller du point A au point B. Pour démontrer une réelle réussite dans une organisation axée sur DevOps, vous devez être en mesure de démontrer que la qualité et les fonctionnalités de vos logiciels augmentent également, ce qui signifie que toutes les fonctionnalités intéressantes qui traînent dans votre backlog finissent par remonter au sommet.

Pourquoi continu ?

Continuous nous permet de dépanner nos applications en toute confiance, car nous savons que nous pouvons rapidement alerter en cas de problème et itérer vers une nouvelle version pour le résoudre. Les équipes peuvent désormais implémenter une fonctionnalité qu'elles attendaient avec impatience, mais qu'elles ont évitée en raison d'un risque perçu.

En réalité, le concept 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 quasi-temps réel, ou d'analyser l'impact de nouvelles fonctionnalités sur l'application et son adoption. Sans ce principe, les applications risquent d'être condamnées à des versions purement linéaires, quelle que soit la durée de vos sprints. Elles peuvent également tomber dans le piège que nous connaissons tous : la stagnation, c'est-à-dire le ralentissement des nouvelles fonctionnalités au profit de très petites modifications des fonctionnalités existantes. Dans ce cas, votre application devient obsolète et seules des réécritures majeures, une refactorisation ou de nouvelles applications peuvent y remédier. Ce n'est pas du tout une approche continue, ou du moins pas une approche continue durable.

Sorties de Canary

L'extrême de la rapidité d'exécution et de la rapidité de correction est ce qu'on appelle les versions canaries. Dans une version canary, une ou plusieurs nouvelles versions de l'application sont publiées parallèlement à la version de production existante. Une fois la ou les versions terminées, vous redirigez tout ou partie du trafic de la production vers les nouveaux environnements de version. L'objectif de ces sous-segments est de réaliser des tests A/B sur de légères variations des versions.

En cas de problème avec une version Canary, vous serez rapidement alerté grâce à un mécanisme d'alerte robuste. Vous pourrez ensuite ramener le trafic en production. Cet exercice peut avoir un léger impact négatif sur vos utilisateurs, mais la réponse est si rapide qu'elle ressemble à un bug. De nouvelles fonctionnalités pourraient être développées en 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 d'un modèle véritablement itératif. Il peut être configuré non pas comme une seule itération, mais comme plusieurs itérations exécutées en parallèle.

Ce modèle serait également considéré comme l'extrême du déploiement continu, sans toutefois inclure certains tests fonctionnels et système automatisés avant les versions. Ces processus peuvent être trop longs pour soutenir ce concept. Il suppose toutefois plusieurs conditions. La plus importante est que votre application dispose d'une base d'utilisateurs et d'un volume suffisants pour permettre 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 sûr, une approche aussi avancée pour analyser les versions et les architectures applicatives nécessite des outils performants. Les trois principaux outils pour une gestion rapide des défaillances sont les suivants :

1. Automatisation des versions : Votre outil d'automatisation des versions doit être capable de gérer plusieurs versions simultanément. Elles le sont toutes, mais ce n'est pas ce que je veux dire. La prise en charge de plusieurs versions parallèles nécessite une excellente gestion de l'état 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. De plus, la charge de travail supplémentaire pourrait compromettre le processus.
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 aux versions Canary, car avec le PaaS, le provisionnement s'effectue sur un pool de ressources, et non sur des machines virtuelles. Cela accélère le provisionnement, mais simplifie également la gestion, 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 représente probablement une étape supplémentaire. Cependant, il n'y a aucune raison d'exclure l'IaaS des processus de déploiement rapide, surtout si vous utilisez une technologie de conteneur comme Docker, qui la rend presque aussi simple que le PaaS. Avec l'IaaS ou le PaaS, les développeurs doivent pouvoir créer et supprimer autant d'environnements qu'ils le souhaitent, et ce à la demande. Si l'accès aux environnements est limité, il est impossible d'assurer le parallélisme ou de résoudre les problèmes avec une nouvelle version mise à jour. Les processus que je présente nécessitent des déploiements full-stack ; le déploiement sur des environnements existants n'est donc pas envisageable. Avec un processus de publication et de restauration aussi rapide, il est très facile d'accumuler des variables qui contamineraient les environnements persistants.
3. Alerte : Journaliser vos environnements est une chose. Il est important de mettre en œuvre la journalisation, surtout pour les données historiques. Cependant, dans les versions Canary, l'historique est trop tardif. Les réponses à chaque build doivent être rapides, et la durée de vie d'une itération est très courte. Il vous faut donc une plateforme d'alerte performante, capable de vous envoyer des alertes au fur et à mesure de leur apparition. Cependant, cette plateforme doit également être intelligente. En raison de la fréquence et du nombre de versions en parallèle, un excès d'informations peut facilement devenir problématique ; la réponse à un problème nécessite donc un long processus de filtrage.

Ce n’est pas que de la technologie

Les concepts de publication, de rupture et de correction accélérées ne sont pas complexes. Leur mise en œuvre dans les environnements existants peut l'être. 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 bouton de publication canari.

La mise en œuvre est un parcours, mais le processus décrit ci-dessus est un objectif. L'avantage du processus d'intégration continue, déjà populaire, est que le processus expérimental d'échec et de retour en arrière peut être implémenté dans des environnements d'intégration. Dans ce cas, l'impact se limite à votre équipe interne. Dans ce cas, l'impact touchera principalement l'assurance qualité, car elle sera chargée de tester les versions dès leur publication. C'est donc à ce niveau que se situe le changement organisationnel le plus important. (Ce qui reste bien moins qu'une mise en œuvre à l'échelle de l'équipe et en production.)

En résumé, les outils disponibles permettent de développer, d'éviter les échecs et de corriger plus rapidement les problèmes. Ce processus augmentera non seulement le nombre de builds réalisés chaque année, mais aussi l'innovation permettant d'obtenir de nouvelles fonctionnalités et une meilleure qualité. Puisque les outils existent déjà, il incombe à l'équipe de trouver une solution pour passer de ses processus de publication existants à de nouveaux processus.

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