Comprendre la différence entre la livraison et le déploiement continus

Des similitudes

La livraison continue et le déploiement continu reposent sur un pipeline d'intégration continue (CI). CI permet de compiler le code logiciel  pour le préparer à passer à la production. Dans le cas d’entreprises aguerries aux méthodes de CI/CD, le pipeline doit produire rapidement un environnement de test complet et autonome, soit de façon automatique, soit avec une intervention manuelle - même mineure.

Le testeur peut voir qu'un build associé à une fonctionnalité est passé et ensuite pousser les changements pour cette fonctionnalité, les tester et approuver ces modifications pour la production. Une fois le code de production approuvé, il lance un processus automatisé de déploiement. Dans le  déploiement continu, ce coup d'envoi se produit automatiquement si les tests s'exécutent.

Les configurations de livraison et de déploiement continus nécessitent un déploiement automatisé, ainsi que des capacités rollback elles-aussi automatisées. Les entreprises doivent alors investir dans un ensemble d'outils automatisés ou mettre en place des processus pour ne déployer que de petits sous-composants qui comportent un risque mineur. La livraison et le déploiement continus exigent généralement que l'accent soit aussi mis sur les capacités de surveillance et de rollback.

De leur côté, les pratiques de développement ne changent pas. Les développeurs apportent des modifications au code, exécutent des tests unitaires et éventuellement des tests d'intégration en local, puis « committent » leur code et poussent ces modifications sur la branche principale. Certaines grandes entreprises utilisent des branches intermédiaires, mais la plupart des développeurs poussent chaque changement à une seule branche maître. Mettre en place un chaîne de déploiement continu demande du temps et du travail.

Faire en sorte que le déploiement continu fonctionne

Cela fait près de 10 ans que Michael Bolton a analysé les processus d'IMVU, l'une des premières entreprises à prétendre publiquement utiliser le déploiement continu. La préoccupation de Bolton n'était pas que l'équipe effectue des déploiements 50 fois par jour. Mais à l’époque, il doutait surtout que supprimer l'humain des tests puisse fournir un logiciel de qualité. Pour résumer ses conclusions : ce n'était pas très bon.

Aujourd'hui, il existe des domaines où le déploiement continu peut être efficace. Dans la pratique, le déploiement continu exige la mise en place de multiples processus et étapes.  Les testeurs travaillent en collaboration avec le développeur, qui passe aussi au test pendant le processus de développement lui-même. Au moment où le code est poussé dans le contrôle de version, il a déjà été testé.

Effectuer des modifications en continu (rolling) par le biais de tests fractionnés est une autre façon de mettre en œuvre le déploiement continu. Avec un simple test A/B, les utilisateurs voient deux comportements différents, tandis que l'entreprise suit la réponse – là où il y a le plus d’engagement est considéré comme positif.

Pour un déploiement continu, il est courant de classer les utilisateurs : les testeurs, les employés, les utilisateurs bêta, les utilisateurs chevronnés et « monsieur tout le monde ». Le programmeur écrit une nouvelle fonction de cette façon :

if (feature_is_turned_on("featurename",GetUserType()) {

  New_Version_Of_Feature();

} else {

  Cut_Paste_Old_Version_of_Feature();

}

Un terme pour cela est l'indicateur de configuration (configuration flag). Une base de données stocke la combinaison des caractéristiques et des flags on/off ; feature_is_turned_on prend l'information, fait une recherche et renvoie vrai ou faux. Les auteurs de How We Test Software At Microsoft, Alan Page, Ken Johnston et BJ Rollison, appellent cela des « tests en production ». Selon eux, un serveur devrait rechercher la version du logiciel à exécuter en fonction du type d'utilisateur. Si les indicateurs de caractéristiques sont stockés dans un fichier ou une base de données, il peut être aussi facile de les inverser - et donc d’effectuer un rollback du code - que de mettre à jour une base de données ou de changer un fichier.

Une autre méthode courante pour faire un déploiement continu avec des indicateurs de configuration consiste à ne le mettre qu'à la disposition des utilisateurs privilégiés, comme l'équipe de développement. Lorsque les testeurs se rendent sur le site Web et se connectent en tant qu'utilisateurs privilégiés, ils voient le nouveau code en cours d'exécution et le testent. Une fois le test terminé, le flag est mis en place pour tous les utilisateurs. Cela réduit considérablement le besoin d'un environnement de test.

Déployer ou livrer en continu ?

La différence fondamentale entre la livraison continue et le déploiement continu est que, avec la livraison continue, il y a une étape de contrôle intermédiaire. Cela peut être très utile s'il est nécessaire de regrouper les fonctionnalités dans une seule version, si le risque de déploiement en production est trop élevé ou si l'équipe n'a pas les outils de monitoring, de rollback ou de composants en place. Par exemple, une banque pourrait vouloir livrer en continu à un serveur intermédiaire, mais avoir un processus d'audit formel en place avant le déploiement en production.