Intégration continue performante (Part #3)
Après avoir vu comment améliorer notre intégration continue, tant au niveau performance (Part #1) que sur sa bonne utilisation (Part #2), nous allons ici essayer de pousser le bouchon un peu plus loin... jusqu'à la production !
Intégration de la prod en continue
Comment généraliser l'intégration continue à l'entreprise sans retomber dans les travers que je citais en première partie ? Comment exploiter au maximum notre serveur d'intégration continue ? Il n'y a pas de formule magique mais quelques étapes indispensables :
Commencer petit. Rome ne s'est pas fait en un jour. L'intégration continue d'entreprise non plus ! On commence par une petite usine de développement (centralisé mais petite) : mise en place de l'infra, de l'intégration continue, du (des) repo(s), on laisse de côté les clusters, la haute dispo... On fait quelque chose de simple et qui fonctionne (Notez que cette remarque est applicable à beaucoup d'autres domaines et notamment au développement).
Avoir un ou deux projets pilotes qui utilisent l'usine dès le début de leur développement. Cela permet d'affiner la plateforme, affiner le discours autour des gains d'une telle approche et se préparer à accueillir des nouveaux projets.
On communique ensuite sur l'existence d'un tel service auprès de toutes les lignes métiers et toutes les équipes projets. Notez l'importance de cette phrase : On communique autour de l'usine, de ses intérêts (intégration continue) afin que tout le monde sache que cela existe et puisse s'il le souhaite l'utiliser (plutôt que d'utiliser et maintenir dans un coin une usine propre au projet consommatrice de temps pour l'équipe). Le deuxième point important est le service. On ne se contente pas de fournir un serveur et des outils, on apporte un guide d'utilisation, des bonnes pratiques, de l'aide (accompagnement), bref du support. L'usine de développement ne peut fonctionner si une équipe ne travaille pas à plein temps dessus, au moins dans les premiers temps (intégration des projets, évolutions/corrections techniques, support aux utilisateurs...).
Lorsque le nombre de projets commence à être conséquent, voire à nuire aux performances de l'usine, c'est bon signe : votre discours a été porteur, votre support efficace et les équipes l'utilisent. On envisage alors la mise en cluster, la haute dispo, le build distribué et tout ce qui pourra soulager notre petite usine du départ. Cela peut aller jusqu'à la création de plusieurs usines, par exemple une par ligne métier. L'important est d'avoir quelque chose de fluide, connu de tous, maintenu et supporté en central, peu importe les moyens.
Il est alors temps de s'associer à l'équipe de production pour que cet "outil" ne reste pas cantonné au développement alors qu'il pourrait faire bien plus : s'intégrer dans le processus de livraison/déploiement des applications.
Paul Duvall, auteur de Continuous Integration: Improving Software Quality and Reducing Risk parle dans son blog de "production continue", ou comment mettre en production à la demande...
Effectivement, si on met en place un référentiel de librairies d'entreprise (voir la rubrique repository central du dernier Maven Community News), on peut envisager de l'utiliser comme un espace de livraison pour la production :
- L'étape précédente est d'autant plus importante qu'elle permettra d'inciter les projets récalcitrants à s'inscrire dans le processus. Effectivement, la production a une force de persuasion sur les projets bien supérieure aux cellules transverses. Il lui sera donc plus facile d'imposer l'utilisation de l'usine pour délivrer une application. Cela peut paraître extrême mais c'est un processus que j'ai pu voir fonctionner chez un client : Malgré un départ difficile (d'où l'importance du support), les projets ont fini par apprécier cette méthode de travail, relativement cadrante. Plus de décompression de war à la dernière minute pour modifier un fichier, plus d'aller-retour de mails entre les équipes pour fournir les fichiers properties manquants, déploiement de versions testées sont autant de points positifs à cette démarche.
L'investissement nécessaire (tests unitaires et fonctionnels, packaging à la Maven, intégration continue...) en vaut-il la chandelle ? Sur le court terme, c'est assez difficile de s'en rendre compte; pas mal de temps passé à maintenir l'usine de développement, du temps investit dans les tests. On est tout de même heureux de ne plus perdre des heures à fabriquer les livrables et gérer des versions (merci maven release !). A moyen et long terme, sur des applications nécessitant pas mal d'évolutions, le gain est incontestable : non-régression et maintenabilité de l'application, intégration aisée du code, livraison automatique des packages... on passe enfin son temps à développer des fonctionnalités qui ont de la valeur !
L'intégration continue, qui était à l'origine destinée à faciliter le travail des développeurs, pourrait donc s'avérer également un outil très pratique pour la production. Reste à intégrer le client et la MOA dans la boucle, et peut être parviendrons nous à livrer rapidement des applications qui répondent aux besoins et qui fonctionnent. Comme disait Martin Luther King : "I have a dream !"...