Le Continuous Delivery et Continuous Deployment

Voici un article pour bien comprendre le Continuous Delivery et Continuous Deployment, des notions que nous voyons de plus en plus dans le monde devops.

Définition du Continuous Delivery

Le continuous delivery (en français la livraison continue) est une technique d’ingénierie informatique qui consiste à tester, préparer et déployer un changement de code. Une validation humaine finale sera à réaliser avant le déploiement final.

Définition du Continuous Deployment

Le continuous deployment (en français le déploiement continu) est une technique d’ingénierie informatique similaire au continuous delivery sauf que le deploiement s’automatise sans validation en amont. Le système est capable est capable de faire un rollback automatique si des erreurs bloquantes sont repérées.

Continuous Delivery et Continuous Deployment

Voici un schéma simplifié qui vous permettra de bien comprendre la nuance entre ces deux notions et également de situer la notion d’intégration continue (continuous integration) au sein de ces deux techniques d’ingénierie.

continuous delivery et continuous deployment
continuous delivery et continuous deployment

La principale différence entre la livraison continue et le déploiement continue se situe au moment de faire le déploiement en production. Souvent les acteurs qui font du déploiement continue mette en place un analyseur d’erreur qui peut automatiquement prendre la décision de faire un rollback (pratique moins fréquente en livraison continue).

Pourquoi tout automatiser ?

Si cela se voit moins dans les petites structures, les mises en production peuvent prendre beaucoup de temps dans les grosses structures. Certaines parlent de mobiliser une équipe pendant plusieurs heures. Si cela à un coût considérable, c’est aussi un frein pour faire des mise en production régulières.

Il sera donc préférable d’automatiser la livraison de modification afin de pouvoir augmenter sa cadence de mise en production et de ne plus avoir besoin d’équipe pour faire cela. Aujourd’hui il existe de nombreux tests (unitaires, fonctionnels, de qualité de code, de charges…) qui permettent d’assurer au maximum cette automatisation. Certains vont jusqu’à automatiser d’éventuels rollback en production basé sur les logs d’erreurs.

Pour ceux qui on connu ce type d’environnement, dans certains entreprises qui ont encore aujourd’hui un lourd legacy, elles ont parfois des mise en production dangereuse par ses manipulations qui font que les loupés arrivent de temps en temps. Automatiser va permettre d’éviter les erreurs humaines.

On en déduira ainsi deux objectifs principaux :

  • Automatisation des livraisons avec un concept de déclencher tout le processus en un seul clic. Le risque d’erreur humaine que l’on pouvait avoir disparait.
  • Livraisons fréquentes car l’automatisation permet de livrer en un seul clic. Ca s’adapte parfaitement à des équipes Agile et principalement celles qui seraient en Kanban.

L’intégration continue pour renforcer nos déploiements

Comme vous le voyez sur le schéma ci-dessus, il est obligatoire de faire de nombreux tests dans ces techniques d’ingénieries.

Ajoutez des tests unitaires sur chacune de vos fonctions sera une belle sécurité supplémentaire. L’ajout de TDD (Test Driven Development) apporte aussi la sécurité de ne pas oublier de faire les tests unitaires puisque l’idée est de les écrire avant d’écrire notre fonction

Certains vont ajouter des tests de scénarios et la technique du BDD (Behavior Driver Development) pour tester des scénarios plus fonctionnels.

Ces deux types de tests sont des tests de non régression. Ils permettront de savoir à chaque tentative de déploiement quelque chose d’ancien a été impacté.

D’autres tests sont aussi à faire comme les tests fonctionnels, les tests de charges, des tests de qualité de code…

Pour ceux qui veulent se tenter rapidement, vous pouvez faire des premières versions avec Github et les outils externes qui s’y connecte très bien comme Sensionlab Insight, Scrutinizer, Travis, AWS…

Un environnement unique

Pour faire de la bonne livraison continue il faut également envisager d’avoir un seul environnement unique. Pour faire simple, il faut que votre environnement de développement, de tests et de production soient identiques.

Si il est très difficile de faire cela, des outils comme docker (avec docker-compose) permettent d’être plus proche de cette philosophie qu’auparavant. Il vous sera indispensable d’aller vers ce type d’outils pour attaquer sérieusement ce type de technique d’ingénierie.

Conclusion

Ce premier article permet de vous éclairer sur ces deux techniques d’ingénierie qui vont être de plus en plus présente dans le monde informatique ; il faut bien comprendre qu’en fin 2016, plus de la moitié des entreprises disent vouloir passer vers des concepts de devops.

Nous verrons dans des prochains articles, certains outils très utilisé plus en détail.

Laissez une réponse