Utilisez-vous Jenkins? Très probablement oui, car c'est le projet le plus populaire de cette classe à ce jour. J'ai toujours été intéressé à parler avec l'un des développeurs et à poser quelques questions difficiles. Ici, nous n'avons pas seulement un développeur, mais le créateur de Jenkins lui-même - Kohsuke Kawaguchi .
Comme vous le savez, Jenkins est un projet open source avec une licence MIT. Plus récemment, la conférence FOSDEM a eu lieu - la plus grande conférence au monde consacrée aux logiciels libres. Gratuit, ouvert, avec des dizaines de locuteurs du monde entier. Cela signifie que vous pouvez y rencontrer n'importe qui - même le créateur de Jenkins. Avec un petit groupe d'amis et de collègues du groupe JUG.ru, nous avons fait un atterrissage surprise là-bas et avons pu enregistrer une bonne interview avec le créateur de Jenkins.
Ainsi, dans notre studio virtuel, Koske Kawaguchi (qui se présentera et expliquera tout en détail ci-dessous), Ruslan Akhmetzyanov ARG89 du groupe JUG.ru et Kirill Tolkachev tolkkv du CIAN , notre conférencier constant, gourou Groovy, Gradle, Spring et la pile technologique Netflix, qui vous pouvez le savoir grâce au podcast Debriefing.
Ruslan: Bonjour. Tout d'abord, parlez-nous un peu de vous et de Jenkins?
Kosuke: Mon nom est Koske, principalement connu comme le créateur de Jenkins et CTO de CloudBees. Jenkins est un outil avec lequel les développeurs automatisent différentes étapes du processus de livraison de logiciels. Je connais personnellement plusieurs programmeurs russes qui utilisent Jenkins et je serai ravi d'en rencontrer d'autres.
Kirill: Je vais également me présenter - je suis développeur et j'organise également le Moscow Jenkins Area Meetup (JAM). J'ai une vaste expérience en utilisant Jenkins, en particulier le pipeline scripté / déclaratif. Pouvez-vous me dire ce que fait le CTO de la société développant Jenkins?
Kosuke: L'une des tâches de mon équipe est d'interagir avec la communauté. Le succès de notre entreprise dépend en grande partie du succès du projet open source. Une autre tâche importante consiste à éduquer le reste des employés de l'entreprise sur le fonctionnement de l'open source. En général, nous obtenons une relation très intéressante entre l'entreprise et la communauté: tout le monde apprend quelque chose les uns des autres, et nous prêtons beaucoup d'attention à cette interaction.
Vous avez également demandé quelle fonction remplit le directeur technique. Le fait est que cette fonction a évolué avec la croissance de l'entreprise. Au début, j'étais un peu comme un programmeur principal et j'ai fait beaucoup de travail technique. Mais au fur et à mesure que l'entreprise se développait, d'autres personnes ont progressivement commencé à faire ce travail. Par exemple, une équipe distincte a commencé à traiter avec Pipeline. Je communique périodiquement avec eux afin d'avoir une idée de ce qu'ils font, parfois je donne des conseils. Mais ils prennent eux-mêmes toutes les décisions liées à la conception et au développement. En général, cette évolution de mon rôle a été très intéressante, je dois constamment m'adapter.
Kirill: Si je vous comprends bien, alors votre attention est passée de problèmes techniques à un travail avec la communauté?
Kosuke: Oui, une grande partie de ce que je fais est liée à cela. Il y a des choses que seul le fondateur d'une entreprise peut dire. Par conséquent, une partie de mon activité consiste, relativement parlant, à brandir un drapeau et à encourager la communauté dans une certaine direction lorsqu'un changement de cap est nécessaire. Comme ce fut le cas, par exemple, l'année dernière. De plus, nous et l'équipe sommes engagés dans la promotion de Jenkins: nous expliquons quels sont nos objectifs, quelles difficultés nous essayons de surmonter. De plus, lorsque j'ai besoin de faire un exposé sur la situation générale, j'inspire plus de confiance. Voilà à quoi ressemble mon activité en bref.
Kirill: Et il y a combien d'années ce départ du travail technique vers le travail organisationnel a commencé? Pouvez-vous raconter l'histoire de Jenkins et comment votre rôle a changé à mesure que le projet grandissait?
Kosuke: Le projet est apparu en 2004, et au début j'ai travaillé dessus le soir et le week-end, c'est-à-dire que c'était une sorte de hobby. Mais petit à petit le projet a grandi. J'ai passé pas mal de temps à créer cette plateforme sur laquelle d'autres personnes pourraient écrire leurs applications. Au fil du temps, un écosystème et une communauté de développeurs ont émergé, dont certains venaient de Russie - par exemple, Oleg Nenashev (Twitter: @oleg_nenashev ), qui a écrit un sous-système très intéressant au-dessus de Jenkins. À mesure que le projet gagnait en popularité, le besoin d'une meilleure interaction avec les utilisateurs et leur formation est devenu plus aigu. Par conséquent, j'ai commencé à en faire plus avec ces choses. Enfin, vers 2010, Jenkins est devenu si populaire que j'ai décidé de lui consacrer tout mon temps et de créer une entreprise. A partir de ce moment, le travail sur l'organisation de l'entreprise s'est ajouté au travail avec la communauté. L'entreprise grandissait et j'ai commencé à me poser la question - quel genre d'activité personne ne peut-il exercer sauf moi? Tant dans l'entreprise que dans la communauté, il y a beaucoup de personnes compétentes qui sont heureuses d'être prêtes à assumer des responsabilités supplémentaires. Peu à peu, ils ont commencé à faire beaucoup de ce que je faisais moi-même. Donc, dans l'ensemble, notre chemin ressemblait.
Kirill: Merci. Aujourd'hui, Jenkins est le système CI le plus populaire. Et quelle est la fréquence de la version commerciale de Jenkins par rapport à d'autres systèmes commerciaux CI? Par exemple, avec Travis Enterprise ou avec des systèmes qui peuvent fonctionner localement?
Kosuke: Open source Jenkins est un grand projet, il a beaucoup d'utilisateurs. CloudBees a une échelle beaucoup plus petite. Par conséquent, si nous parvenons à transformer même un pour cent de la base d'utilisateurs de Jenkins en utilisateurs CloudBees, ce sera un résultat très important. Toutes les entreprises basées sur des produits open source fonctionnent sur ce principe. Une autre question importante est de savoir dans quelle mesure nous parvenons à aider les personnes dont les problèmes devraient être résolus par notre produit. Nous calculons l'efficacité de notre support technique et, si je me souviens bien des statistiques, en général, nos services les satisfont.
Kirill: Vous voulez dire ceux qui utilisent la version payante? Ou ceux qui en ont aussi, gratuitement?
Kosuke: Les deux. Autrement dit, si une personne achète un produit, une assistance lui sera fournie, mais elle peut également être obtenue sans utiliser de logiciel propriétaire.
Kirill: Autrement dit, vous agissez en tant qu'intermédiaire entre les développeurs et vos utilisateurs, open source et commercial. Dois-je bien comprendre que vous avez également des tâches de vision du produit?
Kosuke: Ce n'est pas entièrement vrai, nous avons une équipe de produits distincte. Je ne suis pas un représentant de l'utilisateur, mais j'ai constamment des rencontres avec de nombreuses personnes, utilisateurs et pas seulement, c'est-à-dire que je reste en contact avec la communauté. Par exemple, j'ai une colonne «Résumé avec avancé» pour les autres employés de l'entreprise. Dans ces articles, je parle de la façon dont nos utilisateurs écrivent des logiciels et de ce que cela signifie pour Jenkins. J'essaie donc d'influencer les décisions que l'équipe produit prend.
Kirill: Apparemment, vous jouez un rôle important dans l'entreprise. Passons à des problèmes plus personnels. Quelle est votre fonction Jenkins préférée dont vous pourriez parler du matin au soir?
Kosuke: Eh bien, parler du matin au soir sera difficile. Je suis maintenant plus intéressé par le fonctionnement de l'organisation - je pense que c'est à cause de ma fonction. Lorsque je travaillais seul, mon attention était beaucoup plus concentrée sur les caractéristiques individuelles. Maintenant, je ne pense pas, donc il m’est difficile de répondre à votre question.
Kirill: Alors, vous vous souvenez peut-être d'une fonctionnalité qui a été implémentée il y a des années et qui était très fière?
Kosuke: Je peux parler d'une des fonctionnalités importantes récentes sur lesquelles nous avons travaillé - je pense que ce sera plus intéressant pour les utilisateurs. Il s'agit d'un projet de l'année dernière, Jenkins Configuration as Code . Nous avons vu que nos utilisateurs passaient progressivement de la gestion de Jenkins avec un clic de souris dans l'interface graphique à la configuration via le fichier de configuration dans le référentiel git. Le besoin d'un projet Configuration as Code a été ressenti pendant longtemps et de nombreuses béquilles temporaires ont été écrites pour exécuter cette fonction. Mais aucune de ces entreprises n'était assez importante. Enfin, nous avons réussi à rassembler les personnes de la communauté qui étaient intéressées par ce nouveau projet et à créer un outil assez vaste et réfléchi. De nombreux aspects de ce projet se sont très bien déroulés et il a gagné en popularité, ce qui ne peut que se réjouir.
Vous pouvez rappeler un autre projet, Jenkins X, qui est une évolution dans une direction complètement différente. Il a été créé spécifiquement pour travailler avec Kubernetes. Grâce à cette spécialisation, nous pouvons réaliser une intégration en douceur et masquer la complexité qui résulte de l'intégration et de la connexion de processus de livraison continus. En conséquence, nous facilitons la mise en œuvre des meilleures pratiques, à notre avis. Je pense que grâce à ce projet, Jenkins sera disponible pour un grand nombre de personnes qui effectuent des actions assez standard et ne veulent pas passer beaucoup de temps sur la configuration, qui a besoin de tout pour fonctionner.
Ruslan: Utilisez-vous Jenkins lors de l'écriture de Jenkins?
Kosuke: Oui, le projet Jenkins a son propre Jenkins. En fait, nous avons une grande instance qui exécute un examen pull-rique sur chaque plugin et noyau. En outre, il existe une copie pour les travaux particulièrement importants liés à la sécurité et aux vulnérabilités, car le développement des fonctionnalités de sécurité a lieu dans un référentiel propriétaire séparé. Enfin, il existe une troisième instance pour des tâches encore plus importantes telles que la signature des clés et les éléments liés aux versions. En plus de ces trois, une copie séparée fonctionne 24 heures sur 24 dans ma maison.
Kirill: Vous avez mentionné Jenkins X. Jenkins lui-même est comme un couteau suisse, avec des plugins, il peut tout faire. Mais Jenkins X, au contraire, est hautement spécialisé, il existe pour Pipeline et travaille avec Kubernetes. À quel type de stratégie technique vous et votre entreprise adhérez-vous? Soutenez-vous uniquement Jenkins et Jenkins X? Ou, en plus de cela, il y aura également Jenkins XX pour les clusters Mesos, Jenkins XXX pour Cloud Foundry et ainsi de suite?
Kosuke: Je pense que cela dépend beaucoup de la réaction de la communauté. Il est bien sûr très important d'avoir une plateforme universelle. La question est de savoir qui applique exactement cette flexibilité. Aujourd'hui, les utilisateurs y ont généralement un accès direct. C'est pratique si vous êtes une grande entreprise et que vous faites quelque chose d'inhabituel. Mais en même temps, je connais beaucoup de gens qui n'ont pas besoin d'une telle flexibilité. Imaginez que vous soyez venu dans la salle à manger et que vous ayez demandé de faire un sandwich. On vous propose un choix de sept types de pain, cinq types de beurre, quatre types de fromage et vous devez décider de tous les ingrédients. Mais vous n'avez pas besoin de tout ce choix, vous avez juste besoin d'un sandwich savoureux et vous ne voulez pas savoir comment faire les choses correctement. Je sais que beaucoup de gens ont cette attitude envers Jenkins et veulent que toute la flexibilité reste de notre côté. Jenkins X est le premier pas sérieux dans cette direction. Si ce projet continue à réussir, j'aimerais essayer de faire quelque chose de similaire pour le firmware et l'IoT, les plates-formes mobiles ou l'apprentissage automatique. Je pense qu'il existe de nombreux marchés verticaux où les gens ont juste besoin d'un outil qui leur permettra de mettre rapidement le produit en production. Vous êtes originaire de Russie, alors probablement vous connaissez JetBrains?
Kirill: Bien sûr.
Kosuke: Je pense qu'ils suivent une stratégie similaire. Ils ont une base très flexible, en plus de laquelle il existe de nombreux modules complémentaires plus spécialisés, dans lesquels, essentiellement, les mêmes éléments sont assemblés de différentes manières. Les utilisateurs leur en sont reconnaissants et j'aime beaucoup leur approche.
Kirill: Depuis de nombreuses années, j'observe la même image dans de nombreuses communautés lorsque je vous conseille d'utiliser l'un ou l'autre plug-in - au fait, https://plugins.jenkins.io m'aide beaucoup, tous les plugins approuvés sont là. Le problème est que les gens essaient pour tous les cas d'utiliser un outil universel, qui n'est souvent pas adapté à un cas particulier. Par conséquent, maintenant je recommande généralement un seul outil - Pipeline, qui est un outil idéal qui convient à toutes les situations. Mais un nouveau problème se pose. Les utilisateurs essaient d'utiliser le pipeline scripté ou le pipeline déclaratif sans comprendre comment ils sont organisés en interne. Il y a des problèmes avec l'infrastructure, avec l'établissement d'une correspondance entre les nœuds, le partage de données, un trafic inhabituel entre l'agent et le maître ou des problèmes de mise à l'échelle sur le maître apparaissent. Quel outil, de votre point de vue, est le meilleur: celui qui indique la seule manière correcte de résoudre le problème, comme Jenkins X? Ou un outil comme Scripted Pipeline qui vous demande exactement ce que vous aviez en tête?
Kosuke: Je ne suis pas sûr de vous avoir bien compris, mais je vais essayer de répondre. En japonais, il y a le mot "kata", je ne sais pas comment le traduire avec précision. Il est utilisé, entre autres, en judo. Nous parlons de mouvements strictement définis que les élèves apprennent: par exemple, lever la main d'une certaine manière afin de dévier un certain coup. J'ai fait un peu de cela, donc je connais le plus simple d'entre eux. Le défi consiste à mémoriser un ensemble de mouvements simples, une sorte de modèles ou de meilleures pratiques. Mais ce n'est que le début. Connaissant cette base, vous pouvez continuer à la quitter correctement si la situation l'exige, sans violer les mouvements de base eux-mêmes. Vous étudiez votre propre espace, votre territoire, mais en même temps, connaître la base commune vous aide quand même. Si vous ne la connaissez pas, vous vous demanderez toujours - est-ce que je fais la bonne chose? Même si ce que vous avez écrit fonctionne, vous avez encore des doutes.
En général, votre question m'a rappelé le kata. Je pense que nous avons une situation similaire avec Jenkins. Jenkins X fournit une base, et lorsque vous commencez à la comprendre plus profondément, vous pouvez la laisser si nécessaire à l'aide de plugins et d'autres choses. Bien sûr, Jenkins X doit sacrifier la flexibilité afin de fournir une meilleure expérience avec Kubernetes. Mais le fait que Jenkins X vous pousse vers les meilleures pratiques ne signifie pas que vous êtes privé d'un choix. Dans l'ensemble, cela est vrai par rapport à tout logiciel. C'est juste qu'avec Jenkins X, nous avons eu un changement de mentalité important. Auparavant, nous ne créions que les éléments clés du système - la plateforme et les plugins, c'était à l'utilisateur de les assembler. Avec Jenkins X, la communauté est passée à une nouvelle approche, et à mon avis, c'est une étape très importante.
Kirill: Si cela ne vous dérange pas, j'aurai deux autres questions. Quelle fonctionnalité vous a causé le plus de problèmes au cours de la dernière année? Chaque projet a des périodes difficiles - pouvez-vous nous dire à quoi il ressemblait?
Kosuke: Nous avons vraiment sérieusement ruiné nos vies à plusieurs reprises. Le problème est qu'à mesure que Jenkins grandissait, notre projet commençait à attirer de plus en plus l'attention d'autres sociétés et de leurs équipes de sécurité qui ont commencé à chercher des trous à Jenkins. Par conséquent, le nombre de rapports de vulnérabilité provenant de l'extérieur a commencé à croître de façon exponentielle. Parfois, cela devenait un peu effrayant, surtout lorsque vous considérez que certaines de ces demandes étaient assorties d'un délai, auquel nous devions mettre un terme à la vulnérabilité. Cela a été particulièrement difficile en ce qui concerne les fonctionnalités créées par la communauté. De plus, lors de l'installation de mises à jour avec des vulnérabilités fixes, les utilisateurs sont parfois perturbés. Nous travaillons dur pour éviter que cela ne se produise, car sinon les utilisateurs auront peur d'installer des mises à jour de sécurité, ce qui est extrêmement indésirable.
Kirill: Avez-vous un organe directeur qui décide des fonctionnalités qui seront incluses dans la version? Veuillez nous expliquer comment ces décisions sont prises et les utilisateurs peuvent-ils demander d'inclure certaines fonctionnalités dans la version? S'ils le peuvent, alors qui aura la priorité - aux utilisateurs de Can'tBees ou de l'open source Jenkins? Enfin, si possible, parlez-nous de vos projets pour les six prochains mois à un an.
Koske: Il y a un point intéressant ici: CloudBees ne possède pas Jenkins, ce sont deux projets distincts, chacun avec sa propre structure de prise de décision. CloudBees est tout simplement le plus gros contributeur de Jenkins, avec de nombreux CloudBees travaillant en même temps dans la communauté. Au cours des dernières années, nous avons essayé de créer chez Jenkins des structures de contrôle plus claires qui font exactement ce que vous venez de demander. À cette fin, nous avons créé le processus d'amélioration Jenkins ...
Cyril: Désolé de vous interrompre - est-il abrégé en JEP, tout comme en Java?
Kosuke: Absolument. Évidemment, nous n'avons pas inventé ce concept, mais l'avons emprunté à Python, Java et à d'autres communautés, car il s'y est déjà établi. L'idée principale ici est que la communauté devrait être en mesure d'exprimer son opinion et de parvenir à un consensus avant le début des travaux majeurs sur une fonctionnalité. C'est exactement ce que nous faisons lorsque CloudBees va créer une nouvelle fonctionnalité, nous avons donc la possibilité de changer de cap en fonction de la réponse reçue. C'est l'élément de planification que nous avons pu mettre en œuvre dans notre travail. Puisque nous sommes un projet open source, nous ne pouvons pas dire directement aux autres participants au projet quoi faire. Parfois, ils écoutent notre voix, parfois non.
Quant à nos plans pour les six prochains mois, il est fort probable que nous continuerons à travailler sur bon nombre de nos efforts actuels, y compris Jenkins X. Certains employés de CloudBees et de nombreux contributeurs tiers y travaillent. J'espère que la configuration en tant que code deviendra plus populaire parmi les développeurs de plugins. Dans l'ensemble, nous avons déjà créé la base pour cela, nous devons donc maintenant configurer certains plugins afin qu'ils puissent être correctement connectés via ce système. Enfin, si de nouveaux JEP apparaissent, nous y travaillerons.
Kirill: Eh bien, espérons que JEP n'est pas breveté :) Question à vous en tant qu'auteur de Jenkins - dont l'idée était Scripted Pipeline?
Kosuke: C'est une question intéressante. Le fait est que de nombreuses initiatives dans la communauté n'atteignent souvent pas une masse critique et restent au niveau expérimental. Avant de commencer à travailler sur Pipeline, dans le même espace, les gens avaient déjà essayé de faire quelque chose de similaire, et nous avons eu l'occasion de nous familiariser avec ces tentatives. Nous n'étions donc pas, en fait, les inventeurs de Pipeline. L'un de ces prédécesseurs était le plugin Build Flow, écrit par l'un des employés de CloudBees avant de rejoindre l'entreprise. Je pense que le terme «écosystème» est très réussi - tout se passe vraiment comme dans un véritable écosystème, une technologie créée par quelqu'un évolue et change constamment.
Ruslan: Avez-vous influencé la mise en œuvre de Scripted Pipeline?
Kosuke: Oui, sur sa version originale.
Kirill: Comme nous le savons, il existe deux façons d'implémenter n'importe quel DSL - statiquement et dynamiquement. Pourquoi l'approche dynamique a-t-elle été choisie pour le pipeline scripté?
Kosuke: Je crains de ne pas bien comprendre ce que vous entendez exactement par des approches statiques et dynamiques.
Kirill: Avec une DSL statique, nous avons une certaine confiance dans notre code avant l'exécution. Par exemple, avec DSL en Java, vous devez connaître à l'avance toutes les API et interfaces. Avec une approche dynamique, nous effectuons la vérification directement à l'exécution. Même si le code n'est pas valide, la machine essaiera toujours de l'exécuter, elle lève juste une erreur si nécessaire. La version déclarative du pipeline vous permet d'éliminer de nombreuses erreurs en réduisant la variabilité dans le script de génération.
Kosuke: Pour être honnête, cela n'a pas vraiment d'importance pour moi exactement quand la compilation a lieu. Mais je peux parler des paramètres généraux que nous avons suivis lors de la conception du pipeline scripté. À un certain stade, un nombre important d'utilisateurs Jenkins ont été considérablement gênés par la complexité de l'automatisation. Il était nécessaire d'assurer l'interaction correcte de nombreux composants. Le code est compilé, les tests sont exécutés, puis vous devez attendre que le déploiement soit confirmé, etc. , — Infrastructure as Code. , . Scripted Pipeline. , Pipeline , , Scripted Pipeline, . , , . Declarative Pipeline.
: , -, Jenkins, API . -, Scripted Pipeline, DSL. Declarative Pipeline , . — Pipeline Jenkins? , Jenkins.
: , , . , Pipeline, , , . Freestyle Job, Jenkins, . - , , Freestyle Job . , , . , Pipeline . - — , Shared Libraries. , . . , .
: Jenkins. Jenkins 2. API . Jenkins , , , , . , , ?
: , . , . Jenkins. , 800 , 1600 — , , . , . , . « » , , , , , . , , .
: , Java? 15-, 20- . Python 2 Python 3, ? ?
: , , , Java Python. , . , Jenkins , . , . , , . , , , . , , , Jenkins X. , , .
: , !
5-6 JPoint «Superpowers coming to your Jenkins» . , . JPoint ( , ).