Il y a 7 ans, j’écrivais la première ligne de code qui a démarré le projet aujourd’hui connu sous le nom de Jenkins, et qui s’appelait à l’origine Hudson. J’avais l’habitude d’être celui qui cassait le build[1], j’avais donc besoin d’un programme qui détecte mes erreurs avant que mes collègues ne le fassent. C’était alors un outil simple qui faisait une chose simple. Cependant, cet outil a rapidement évolué et j’aime à penser aujourd’hui qu’il est devenu le serveur d’intégration continue le plus répandu sur le marché, englobant un large écosystème de plugins, des distributions commerciales, du Jenkins-as-a-Service hébergé, des groupes utilisateurs, des rencontres utilisateurs, des formations, etc.
Comme la plupart de mes autres projets, celui-ci a été rendu open source dès sa création. Au cours de sa vie, il a reposé essentiellement sur l’aide et l’amour d’autres personnes, sans lesquelles ce projet ne serait pas dans son état actuel. Durant cette période, j’ai aussi appris une chose ou deux sur le fonctionnement des projets open source. De par cette expérience, j’ai constaté que les gens ignorent souvent qu’il y a plusieurs façons de contribuer à un projet open source, et qu’écrire du code n’en est qu’une parmi d’autres. On peut en parler autour de soi, aider les autres utilisateurs, organiser des conférences, et bien sûr, on peut rédiger de la documentation.
En cela, John est une personne importante au sein de la communauté Jenkins, même s’il n’a pas fourni de code, il rend Jenkins plus accessible aux nouveaux utilisateurs. Par exemple, il a un blog populaire qui est suivi par de nombreuses personnes, sur lequel il parle régulièrement des pratiques liées à l’intégration continue, ainsi que d’autres sujets liés au développement logiciel. Il a vraiment un talent pour expliquer les choses afin que même des utilisateurs néophytes puissent les comprendre, ce qui est souvent difficile pour des gens comme moi qui développent Jenkins jour après jour. Il est aussi connu pour ses formations, dont Jenkins fait partie. C’est encore une autre façon par laquelle il rend Jenkins accessible à davantage de personnes. Il a clairement une passion pour évangéliser de nouvelles idées et enseigner à ses pairs développeurs comment être plus productifs.
Ces temps-ci je consacre mon temps chez CloudBees à la version open source de Jenkins ainsi qu’à la version pro sur laquelle nous construisons des plugins, et à faire fonctionner Jenkins dans les clouds privés et publics via le service DEV@cloud de CloudBees. Avec ce rôle, j’ai maintenant une plus grande interaction avec John qu’auparavant, et mon respect pour sa passion n’a fait qu’augmenter.
Je fus donc véritablement ravi qu’il prenne en charge l’immense tâche que représente l’écriture d’un livre sur Jenkins. Cela donne une formidable vue d’ensemble sur les principaux ingrédients de l’intégration continue. En plus, à titre personnel, vu que l’on me demande souvent s’il y a un livre sur Jenkins, je peux enfin répondre à cette question par l’affirmative ! Mais plus important encore, ce livre reflète, entre autre, sa passion et sa longue expérience dans l’enseignement de Jenkins. Mais ne me croyez pas sur parole, vous devrez le lire pour le voir par vous-même.
[1] Note des traducteurs : nous n’avons pas traduit le terme build car nous n’avons pas trouvé de traduction pertinente et parce que ce terme reste majoritairement utilisé dans les métiers des TI.