Jeudi dernier, l’équipe Zenika était présente au séminaire ThoughtWorks qui se déroulait à Paris et animé par Jez Humble, auteur du livre “Continuous Delivery”. Jez Humble et son équipe ont transmit leur savoir sur les grands principes du “Continuous Delivery” durant toute une journée.
Entouré d’une vingtaine de personnes, le séminaire s’est composé d’un ensemble de slides résumant étape par étape la démarche du continuous delivery. Et en fin de journée, nous avons eu une mini-démonstration du logiciel Toughworks GO. Ce dernier est pour le moment le seul logiciel du marché capable d’implanter pleinement un pipeline de continuous delivery, c’est-à-dire une implémentation automatisée (ou semi-automatisée) avec des mécanismes d’approbation (manuel ou automatique) des étapes de build, de déploiement/installation, de test et de livraison. L’objectif est de donner de la visibilité, du feedback et une maîtrise complète de la livraison de ses applications.
Quelques rappels de vocabulaire
“Continuous Integration” est une méthodologie de développement consistant à instancier une instance du processus d’intégration (génération de code, compilation, exécution des tests, ..) à chaque changement d’environnement (source code, filesystem, ..).
“Continuous Delivery” est l’étape suivante et caractérise la possibilité de déployer ses applications à tout moment.
“Continuous Deployment” est la dernière marche du « Continuous » et caractérise le déploiement en continu en production
Quelques notions à retenir
- Les problèmes de déploiement sont dues principalement à la structure des organisations et au manque de connaissances des outils. Mais dans tous les cas, cela est rarement due à un manque de temps.
- Tout le monde doit être responsable du “delivery”
- Plus on livre souvent, plus les livraisons (release) contiennent moins de choses; on réduit ainsi automatiquement les risques.
- Essayer d’automatiser le maximum d’étapes de votre pipeline
- Toujours prévoir une procédure de retour en arrière (rollback) en cas de déploiement
- Considérer votre infrastructure comme du code afin de pouvoir détecter les changements. Les outils Puppet ou Chef aident alors à répondre à cette problématique.
- Limiter le concept “feature branching”. Ce style de dévelopement logiciel consiste à créer une branche par fonctionnalité majeure de l’application à implémenter. A contratrio, il est préférable de travailler sur une seule branche principale pour l’équipe.
- Utiliser la technique ‘Feature Toogles’ et/ou la technique ‘Branch by Abstraction’ pour éviter le ‘Feature Branching’ et ainsi permettre de pouvoir continuer à livrer sans que l’implémentation d’une nouvelle fonctionnalité soit terminée. ‘Feature Toogles’ consiste à mettre à disposition des mécanismes de switch pour rendre actif une fonctionnalité à la demande. L’autre technique ‘Branch by abstraction’ (ou Code branching) est une technique d’architecture consistant à faire des couches d’architecture afin de prémunir son code source des changements inattendues qui peuvent être faits. Par exemple, si on veut s’abstraire du gestionnaire de persistance Hibernate pour potentiellement utiliser autre chose, cela va consister à faire une interface proxy de persistence et ainsi relayer Hibernate à une typologie d’implémentation.
- Produire vos binaires une seule fois (très important dans le cadre de Maven qui va à l’encontre de ceci avec son mécanisme de release qui reconstruit les binaires)
Nos regrets
On regrette parfois la nuance de certaines affirmations au regard par exemple de très grands projets industriels.
Prenons par exemple le développement en branches (ou feature branching). Cette technique est souvent peu recommandée dans un cadre d’intégration continue. En effet, “feature branching” engendre une tendance à intégrer les fonctionnalités au reste du projet tardivement (plusieurs jours, plusieurs semaines, … après le début de l’implémentation de la fonctionnalité) et rend ainsi les merges douloureux avec les branches principales d’intégration. Les merges sont d’autant complexe que le temps d’intégration est grand.
A contrario, l’intégration continue a pour objectif d’intégrer en continu (ou à défaut fréquemment) les développements d’une équipe pour une branche principale et non sur chaque branche de fonctionnalité. Et mettre en place un CI serveur sur chaque branche n’est pas non plus une solution car nous nous retrouvons avec l’intégration de plusieurs versions du produit pour une seule version au finale.
Néanmoins, dans le cadre d’une très grosse équipe avec des livraisons régulières sur la branche d’intégration (deliver), ce problème est réduit significativement. En effet, de part la taille de l’équipe, nous avons en permanence une branche d’intégration alimentée avec des nouveaux éléments de développement et donc une réelle intégration en continue.
En conclusion
Nous avons pu apprécier les retours d’expériences et les échanges avec l’ensemble des participants. Jez Humble est un très bon communiquant et nous avons hâte de le revoir parmi nous à Paris.
