Le déploiement continu par Thoughtworks : Go!

Thoughtworks, le cabinet de conseil spécialisé dans les pratiques de développement agile et XP, faisait figure de pionnier de l'intégration continue lors de la sortie de leur outil d'automatisation de build CruiseControl il y a quelques années. Cependant, la concurrence fut rude ces dernières années, notamment grâce à Hudson ou TeamCity, et CruiseControl apparaît aujourd'hui comme un outil fonctionnel mais sans plus.

La réponse de Thoughtworks ne s'est pas faite attendre longtemps: la sortie de Go, un outil de gestion du cycle de vie des applications exprime leur volonté de remplacer leur outil historique CruiseControl et de passer de l'intégration continue au déploiement continu ou continuous delivery: déploiement continu dans tous les environnements, y compris la production.

Nous allons aborder dans cet article ce qui caractérise cet outil, ses points forts et ce qu'on aurait aimé y voir.

Formalisation et personnalisation du processus de production de logiciel

Go permet de formaliser et manipuler des concepts importants dans le cycle de vie d'un logiciel. Voici une capture d'ecran de Go avec les différentes notions formalisées :

Typiquement, la notion de pipeline: une suite d'étapes correspondant à un maillon dans la chaine de la fabrication d'un logiciel, en général constitué des étapes de compilation + tests unitaires + déploiement sur un environnement de test. Les tests fonctionnels d'acceptance peuvent correspondre à un autre maillon de cette chaîne. Le lancement des tests de performance et le déploiement en pré-production ou en production peuvent constituer d'autres étapes.

Le schéma ci-dessous permet de faire un zoom sur le pipeline de tests d'acceptance :

Go propose en outre de gérer les dépendances entre pipelines. Cela permet par exemple de dire que le pipeline de déploiement en production dépend du succès des pipelines de tests d'acceptance et de déploiement en pré-production. La capture ci-dessous montre trois pipelines: un contenant les tests d’acceptance, un deuxième les tests de performance et un troisième le déploiement sur l'environnement de production :

Il faut noter que Go convient aux structures multi-projets. La description d'un pipeline (adresse du gestionnaire de sources, commandes à exécuter dans chaque étape, etc.) peut être commune à plusieurs projets. Ceci permet donc une homogénéité et une mutualisation de la configuration des projets.

Les actions faites au niveau de chaque étape d'un pipeline, appelées stages, peuvent notamment être exécutés par des scripts shell, .bat, ant, rake ou makefile. On regrettera le manque de support de Maven mais Thoughtworks ne l'exclut pas pour les versions à venir. On devra en attendant écrire des scripts qui lanceront les commandes Maven...

Formalisation de la notion d'environnement

C'est un des principaux atouts de l'outil. En formalisant la notion d’environnement, avec pour chacun sa fonction (dev, UAT, Pre-Prod, Prod, etc.) et les ressources dont il dispose, il permet une vision globale du processus de production: quelle version du logiciel est déployée dans quel environnement à quel moment? Cette vision claire facilite le passage d'un environnement a un autre, avec un simple clic. Il faut tout de même noter que cette vision des environnements est disponible uniquement dans la version Entreprise, ce qui limite fortement l'intérêt de la version communautaire. Les différences entre les deux éditions sont exposées dans ce tableau :

Parallélisation des tests avec la notion d'agents et de jobs

La parallélisation est une fonctionnalité incontournable aujourd'hui pour un outil d'intégration continue. Ici, elle s'implémente avec des agents et des jobs. Un job est une unité de travail indivisible. Un pipeline est une suite de stages eux-mêmes composés de jobs parallélisables. Les agents s'approprient des jobs en s'adressant au serveur principal, et les exécutent.

Aucune intelligence cependant n'est à attendre de la part de l'outil en ce qui concerne la parallélisation des jobs en général et notamment des tests. Si on veut paralléliser des tests, on doit lancer chaque test sur un job séparé et ainsi ils seront parallélisés de fait. Cela reste donc possible mais fastidieux.

Conclusion

Avec Go, Thoughtworks rattrape le retard accumulé, et formalise des notions que sont les environnements, le déploiement continu, les pipelines de build, etc. Un des avantages non cités de l'outil est son ergonomie, sa vision globale des environnements, des ressources et des versions déployées à tout moment et son niveau d'industrialisation qui conviendra aux contextes multi-projets. Go vient combler un vide et répondre à un vrai besoin.

Cerise sur le gâteau, la documentation est très complète et Thoughtworks organise des sessions de formation régulièrement : http://www.thoughtworks-studios.com/webinars.