Quelques pistes pour t’aider dans ton aventure « Continuous Integration ».
Le premier conseil que je peux te donner c’est d’oublier, au moins dans un premier temps, Docker. Un outil comme Jenkins, et dans une certaine mesure aussi Gitlab, ça n’est pas un outil adapté à la conteneurisation. Jenkins est historiquement un fork d’un projet nommé Hudson, et ça commence à avoir plus de dix ans. Plein de choses ne sont pas bien foutues pour les conteneurs.
Du coup je te conseille de viser une installation avec 1 outil = 1 VM. Si c’est trop compliqué d’avoir ça, tu peux collocaliser les outils sur une seule VM. Pour un prototype ça ira très bien. Mais sur le long terme tu te rendra compte que ça pose des problèmes en production. Chaque outil a des besoins assez différents et concurrents en ressources.
Le second conseil que je te donnerais c’est d’ajouter un gestionnaire d’artefacts à ton architecture (à moins que Release Automation fasse ça, je ne connais pas cet outil). Les deux pistes Open Source les plus fiables sont JFrog Artifactory et Sonatype Nexus (ton choix sera dicté très probablement par les types de dépôts que tu veux et que tu trouves dans les versions communautaires de ces outils : Python, NodeJS/NPM, Maven2, Docker, yum…).
Par rapport à ta question sur GitlabCI pour remplacer Jenkins, je pense que c’est une bonne idée pour un prototype. Les pipelines GitlabCI sont bien documentés, et c’est un outil désormais assez connu. En face, Jenkins est un peu vieillissant, mais très communautaire, avec des tonnes de plugins utiles et d’intégrations. Si je devais monter une architecture de zéro, sans contraintes d’existant, je pencherais quand même vers GitlabCI.
Troisième conseil, fait simple. De l’installation « prototype » à faire ton propre Cloudbees maison, il y a un gouffre dans lequel tu peux vite tomber (oh un plugin cool, oh une automatisation sympa…). Commence petit. A chaque fois que tu te dis « je vais rajouter cette fonctionnalité », pèse bien le ratio travail/gain. Et ce conseil ne concerne pas que la partie technique. C’est très tentant également de faire compliqué sur l’organisation (en équipes, en projets, standardiser le nommage etc.) : là aussi parfois il faut savoir commencer simple, quitte à avoir conscience qu’il faudra dans quelques mois refaire du ménage et mettre en place des stratégies.
Comme disait Dijsktra (le mathématicien, pas l’espion) : « early optimization is the root of all evil! »
Si tu veux te documenter sur ce sujet je te conseille très fortement d’aller regarder ce que Martin Fowler a écrit. C’est LE mec à suivre pour ce qui concerne la CI/CD. Côté France, tu devrais aussi t’intéresser à ce que publie Nicolas de Loof, Monsieur Cloudbees : https://twitter.com/ndeloof.
Tu peux aussi regarder les conférences Devoxx sur Youtube, il y a plein de très bonne pratiques à y trouver notamment par les gens de Cloudbees ou de JFrog.
Une vidéo à voir avant de jouer avec Jenkins notamment :
Pour info, c’est un sujet sur lequel je bosse pas mal aussi bien techniquement qu’en termes de méthodologie la CI/CD. Je ne veux pas t’écrouler sous des réponses technico-techniques et trop pointues, il faut que tu mettes les mains dans le cambouis pour te faire tes propres idées. Mais si tu galères sur un point technique, ou si tu veux une relecture de présentation, n’hésite pas à PM.
les outils JetBrains. Je n’ai jamais utilisé TeamCity, mais si c’est du même acabit que leurs autres softs ça doit être très intéressant à tester. Par contre il n’y a pas, à ma connaissance, de version communautaire. Et il y aura probablement un peu moins de littérature que sur les autres outils.
)
Je vais détailler un peu plus mes besoins, parce qu’effectivement on est déjà parti un peu loin