{"id":93885,"date":"2020-09-10T19:42:23","date_gmt":"2020-09-10T17:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov"},"modified":"2020-09-10T19:42:23","modified_gmt":"2020-09-10T17:42:23","slug":"continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","title":{"rendered":"L'int\u00e9gration continue en tant que pratique, et non Jenkins. Andre\u00ef Alexandrov.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Discutons pourquoi les outils CI et CI sont en r\u00e9alit\u00e9 deux choses diff\u00e9rentes.<\/p>\n

<\/p>\n

Quel probl\u00e8me CI cherche-t-il \u00e0 r\u00e9soudre, d'o\u00f9 vient l'id\u00e9e, quelles sont les derni\u00e8res validations prouvant son efficacit\u00e9, comment savoir si vous appliquez r\u00e9ellement une pratique et non juste un Jenkins install\u00e9.<\/p>\n

<\/a><\/noindex><\/p>\n

L'id\u00e9e de faire une pr\u00e9sentation sur l'int\u00e9gration continue est n\u00e9e il y a un an, lorsque je passais des entretiens de recherche d'emploi. J'ai discut\u00e9 avec 10-15 entreprises, et une seule a pu r\u00e9pondre clairement \u00e0 ce qu'est le CI et expliquer comment elles ont compris qu'elles n'en avaient pas. Les autres disaient des absurdit\u00e9s incompr\u00e9hensibles sur Jenkins \ud83d\ude42 Eh bien, nous avons Jenkins, il fait des builds, donc c'est du CI ! Dans ma pr\u00e9sentation, je vais essayer d'expliquer ce qu'est r\u00e9ellement l'int\u00e9gration continue et pourquoi Jenkins et des outils similaires ont une relation tr\u00e8s limit\u00e9e avec cela.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Alors, qu'est-ce qui vient g\u00e9n\u00e9ralement \u00e0 l'esprit lorsque l'on \u00e9voque le CI ? La plupart des gens penseront \u00e0 Jenkins, Gitlab CI, Travis, etc.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

M\u00eame si nous faisons une recherche sur Google, ces outils nous seront pr\u00e9sent\u00e9s.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Si vous demandez aux personnes qui s'y connaissent, d\u00e8s qu'elles \u00e9num\u00e8rent les outils, elles vous diront que le CI est lorsque, dans une Pull Request pour un commit, une build est effectu\u00e9e et que des tests sont ex\u00e9cut\u00e9s.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

L'int\u00e9gration continue, ce n'est pas une question d'outils, ni de builds avec des tests dans une branche ! L'int\u00e9gration continue est une pratique d'int\u00e9gration tr\u00e8s fr\u00e9quente de nouveau code et pour l'appliquer, il n'est pas du tout n\u00e9cessaire de se lancer dans des Jenkins, des GitLabs, etc.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Avant de comprendre \u00e0 quoi ressemble un CI complet, plongeons d'abord dans le contexte des personnes qui l'ont invent\u00e9 et ressentons la douleur qu'elles ont tent\u00e9 de r\u00e9soudre.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Et ils ont cherch\u00e9 \u00e0 r\u00e9soudre la douleur du travail d'\u00e9quipe !<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Regardons des exemples des difficult\u00e9s rencontr\u00e9es par les d\u00e9veloppeurs lors du d\u00e9veloppement en \u00e9quipe. Nous avons un projet, une branche master dans git et deux d\u00e9veloppeurs.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Et ils ont commenc\u00e9 \u00e0 travailler comme tout le monde en a l'habitude. Ils ont pris une t\u00e2che dans JIRA, cr\u00e9\u00e9 une branche feature et ont commenc\u00e9 \u00e0 \u00e9crire du code.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

L'un a termin\u00e9 sa fonctionnalit\u00e9 plus rapidement et l'a fusionn\u00e9e dans master.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Le second a besoin de plus de temps, il a fusionn\u00e9 plus tard et a rencontr\u00e9 un conflit. Maintenant, au lieu d'\u00e9crire les fonctionnalit\u00e9s n\u00e9cessaires au business, le d\u00e9veloppeur consacre son temps et ses efforts \u00e0 r\u00e9soudre des conflits.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Plus il est difficile d'int\u00e9grer votre fonctionnalit\u00e9 dans le master, plus nous perdons de temps. Et c'est un exemple assez simple que j'ai pr\u00e9sent\u00e9. C'est un cas o\u00f9 il n'y a que 2 d\u00e9veloppeurs. Imaginez maintenant si 10, 15 ou 100 personnes dans l'entreprise \u00e9crivent dans le m\u00eame d\u00e9p\u00f4t. Vous perdrez la t\u00eate \u00e0 r\u00e9soudre tous ces conflits. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Il y a un autre cas l\u00e9g\u00e8rement diff\u00e9rent. Nous avons un master et plusieurs d\u00e9veloppeurs qui travaillent sur quelque chose.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Ils ont cr\u00e9\u00e9 une branche chacun.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

L'un d'eux a fait un merge, tout va bien, il a termin\u00e9 sa t\u00e2che.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Entre-temps, le deuxi\u00e8me d\u00e9veloppeur a \u00e9galement termin\u00e9 sa t\u00e2che. Supposons qu'il l'a soumise pour r\u00e9vision. Dans de nombreuses entreprises, il y a cette pratique de la r\u00e9vision. D'une part, c'est une bonne et utile pratique, d'autre part, cela nous ralentit souvent. Nous ne plongerons pas dans ce sujet, mais voici un excellent exemple de ce \u00e0 quoi peut conduire une histoire tortueuse de r\u00e9vision. Vous avez soumis une demande de tirage pour r\u00e9vision. Le d\u00e9veloppeur n'a plus rien \u00e0 faire. Que commence-t-il \u00e0 faire ? Il commence \u00e0 prendre d'autres t\u00e2ches. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Pendant ce temps, le deuxi\u00e8me d\u00e9veloppeur a \u00e9galement travaill\u00e9 sur autre chose. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Le premier a termin\u00e9 une troisi\u00e8me t\u00e2che. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Et apr\u00e8s un certain temps, sa r\u00e9vision a \u00e9t\u00e9 approuv\u00e9e, et il essaie de faire un merge. Et que se passe-t-il ? Il rencontre un grand nombre de conflits. Pourquoi ? Parce que pendant que sa demande de tirage \u00e9tait en r\u00e9vision, beaucoup de choses ont d\u00e9j\u00e0 chang\u00e9 dans le code. <\/p>\n

<\/p>\n

En plus de cette histoire de conflits, il y a une question de communication. Tant que votre branche est en r\u00e9vision, tant qu'elle attend quelque chose, tant que vous peinez \u00e0 terminer la fonctionnalit\u00e9, vous cessez de suivre les changements dans la base de code de votre service. Peut-\u00eatre que ce que vous essayez de r\u00e9soudre maintenant a d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9solu hier, et vous pourriez r\u00e9utiliser une m\u00e9thode. Mais vous ne le verrez pas, car vous travaillez toujours avec une branche obsol\u00e8te. Et cette branche obsol\u00e8te conduit toujours \u00e0 devoir r\u00e9soudre des conflits de merge. <\/p>\n

<\/p>\n

Ainsi, si nous travaillons en \u00e9quipe, c'est-\u00e0-dire que ce n'est pas une seule personne qui fouille dans le d\u00e9p\u00f4t, mais 5 \u00e0 10 personnes, alors plus nous tardons \u00e0 ajouter notre code dans le master, plus nous souffrons du fait qu'\u00e0 la fin, quelque chose doit \u00eatre fusionn\u00e9. Plus nous avons de conflits, et plus nous travaillons avec une version ancienne, plus nous aurons de probl\u00e8mes.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Faire quelque chose ensemble, c'est douloureux ! Nous nous g\u00eanerons toujours les uns les autres. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Ce probl\u00e8me a \u00e9t\u00e9 soulev\u00e9 il y a plus de 20 ans. La premi\u00e8re mention de la pratique de l'Int\u00e9gration Continue que j'ai trouv\u00e9e se situe dans le cadre de la programmation extr\u00eame.<\/p>\n

<\/p>\n

La programmation extr\u00eame est le premier cadre agile. La page est apparue en 1996. L'id\u00e9e \u00e9tait d'utiliser certaines pratiques de programmation, de planification et d'autres, afin que le d\u00e9veloppement soit le plus flexible possible, pour que nous puissions r\u00e9agir plus rapidement \u00e0 des changements ou aux exigences de nos clients. Ils ont commenc\u00e9 \u00e0 s'en rendre compte il y a 24 ans, que si vous faites quelque chose pendant longtemps et \u00e0 l'\u00e9cart, vous y passez plus de temps \u00e0 cause des conflits. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Maintenant, nous allons analyser le terme \u00ab Int\u00e9gration Continue \u00bb mot par mot. Si l'on traduit litt\u00e9ralement, cela donne une int\u00e9gration continue. Mais \u00e0 quel point est-elle continue n'est pas tr\u00e8s clair, elle est en r\u00e9alit\u00e9 plut\u00f4t intermittente. Et dans quelle mesure l'int\u00e9gration est-elle \u00e9vidente \u00e9galement ? <\/p>\n

<\/p>\n

C'est pourquoi je vous pr\u00e9sente maintenant des citations de la programmation extr\u00eame. Nous allons examiner les deux mots s\u00e9par\u00e9ment. <\/p>\n

<\/p>\n

Int\u00e9gration \u2014 Comme je l'ai d\u00e9j\u00e0 dit, nous visons \u00e0 ce que chaque ing\u00e9nieur travaille avec la version de code la plus r\u00e9cente, afin qu'il tente d'ajouter son code aussi souvent que possible dans la branche principale, pour que ce soient de petites branches. Parce que si elles sont grandes, nous pouvons facilement rester bloqu\u00e9s pendant une semaine \u00e0 cause des conflits de fusion. Surtout si nous avons un cycle de d\u00e9veloppement long, comme le mod\u00e8le en cascade, o\u00f9 le d\u00e9veloppeur parts pendant un mois pour r\u00e9aliser une grande fonctionnalit\u00e9. Et il peut se retrouver bloqu\u00e9 longtemps au stade de l'int\u00e9gration. <\/p>\n

<\/p>\n

L'int\u00e9gration, c'est quand nous prenons notre branche et l'int\u00e9grons avec la branche principale, nous la fusionnons. Il existe une version ultime o\u00f9 nous d\u00e9veloppons en faisant directement des commits dans la branche principale sans cr\u00e9er de branches suppl\u00e9mentaires.<\/p>\n

<\/p>\n

En r\u00e9sum\u00e9, l'int\u00e9gration consiste \u00e0 prendre son code et \u00e0 le fusionner dans la branche principale. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Que signifie le mot \u00ab continu \u00bb, qu'est-ce qui est appel\u00e9 continuit\u00e9 ? La pratique implique que le d\u00e9veloppeur cherche \u00e0 int\u00e9grer son code le plus rapidement possible. C'est son objectif lors de l'ex\u00e9cution de toute t\u00e2che : faire en sorte que son code apparaisse dans la branche principale le plus vite possible. Dans un monde id\u00e9al, les d\u00e9veloppeurs feraient cela toutes les quelques heures. C'est-\u00e0-dire que vous prenez une petite t\u00e2che, vous la fusionnez dans la branche principale. Tout va bien. Vous aspirez \u00e0 cela. Et vous devez le faire de mani\u00e8re continue. D\u00e8s que vous avez fait quelque chose, vous l'int\u00e9grez imm\u00e9diatement dans la branche principale. <\/p>\n

<\/p>\n

Et le d\u00e9veloppeur qui fait quelque chose est responsable de ce qu'il a fait pour que cela fonctionne et ne casse rien. C'est ici qu'appara\u00eet g\u00e9n\u00e9ralement l'histoire des tests. Nous voulons ex\u00e9cuter certains tests sur notre engagement, sur notre fusion, pour nous assurer que cela fonctionne. Et c'est ici que Jenkins peut vraiment vous aider.<\/p>\n

<\/p>\n

Mais concernant les histoires : faisons en sorte que les changements soient petits, que les t\u00e2ches soient petites, et essayons de fusionner la t\u00e2che dans la branche principale imm\u00e9diatement \u2013 c'est l\u00e0 que Jenkins ne vous aidera pas. Parce que Jenkins ne vous aidera qu'\u00e0 ex\u00e9cuter les tests. <\/p>\n

<\/p>\n

Vous pouvez vous en passer. Cela ne vous d\u00e9rangera absolument pas. Parce que l'objectif de la pratique est de se fusionner le plus souvent possible, afin de ne pas perdre beaucoup de temps sur des conflits futurs. <\/p>\n

<\/p>\n

Imaginons que nous sommes en 2020, pour une raison quelconque, sans Internet. Et nous travaillons localement. Nous n'avons pas Jenkins. C'est normal. Vous pouvez tout de m\u00eame cr\u00e9er une branche locale. Vous y avez \u00e9crit du code. Vous avez r\u00e9alis\u00e9 une t\u00e2che en 3-4 heures. Vous passez \u00e0 la branche principale, faites un git pull, fusionnez votre branche. C'est fait. Si vous faites cela souvent \u2013 f\u00e9licitations, vous avez l'Int\u00e9gration Continue !<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Quelles sont les preuves dans le monde moderne indiquant que cela vaut la peine de d\u00e9penser des efforts ? Parce qu'en g\u00e9n\u00e9ral, c'est compliqu\u00e9. Si vous essayez de travailler ainsi, vous comprendrez que vous devez traiter une certaine planification, vous passerez plus de temps \u00e0 d\u00e9composer les t\u00e2ches. Parce que si vous faites man..., vous ne pourrez pas fusionner rapidement et, par cons\u00e9quent, vous vous retrouverez dans l'embarras. Vous n'aurez plus de pratique. <\/p>\n

<\/p>\n

Et cela va co\u00fbter cher. Il ne sera pas possible de travailler avec l'int\u00e9gration continue d\u00e8s demain. Vous allez tous mettre beaucoup de temps \u00e0 vous habituer, beaucoup de temps \u00e0 apprendre \u00e0 d\u00e9composer les t\u00e2ches, beaucoup de temps \u00e0 vous habituer \u00e0 revoir votre pratique de r\u00e9vision, si vous en avez une. Parce que notre objectif est que cela soit fusionn\u00e9 aujourd'hui. Et si vous passez trois jours \u00e0 faire une r\u00e9vision, alors vous avez des probl\u00e8mes et l'int\u00e9gration continue ne fonctionne pas. <\/p>\n

<\/p>\n

Mais avons-nous des preuves concr\u00e8tes en ce moment qui nous disent qu'il est judicieux d'investir dans cette pratique ?<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

La premi\u00e8re chose qui m'est venue \u00e0 l'esprit est l'\u00c9tat du DevOps. C'est une \u00e9tude que les gars r\u00e9alisent depuis 7 ans. Ils le font maintenant en tant qu'organisation ind\u00e9pendante, mais sous Google.<\/p>\n

<\/p>\n

Et leur \u00e9tude de 2018 a montr\u00e9 une corr\u00e9lation entre les entreprises qui essaient d'utiliser des branches \u00e0 courte dur\u00e9e de vie, qui s'int\u00e8grent rapidement, qui s'int\u00e8grent fr\u00e9quemment, elles ont de bien meilleurs indicateurs de performance IT.<\/p>\n

<\/p>\n

Quels sont ces indicateurs ? Ce sont 4 m\u00e9triques qu'ils recueillent aupr\u00e8s de toutes les entreprises dans leurs sondages : fr\u00e9quence de d\u00e9ploiement, d\u00e9lai pour les changements, temps de restauration du service, taux d'\u00e9chec des changements.<\/p>\n

<\/p>\n

Et tout d'abord, il y a cette corr\u00e9lation, nous savons que les entreprises qui fusionnent souvent ont des m\u00e9triques bien meilleures. Et ils classifient les entreprises en plusieurs cat\u00e9gories : les entreprises lentes, qui produisent lentement, les performers moyens, les performers \u00e9lev\u00e9s et l'\u00e9lite. L'\u00e9lite comprend Netflix, Amazon, qui sont tr\u00e8s rapides, font tout rapidement, avec \u00e9l\u00e9gance et qualit\u00e9.<\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

Une autre histoire, qui s'est produite il y a \u00e0 peine un mois. Le Technology Radar a publi\u00e9 un excellent article sur Gitflow. Gitflow se distingue des autres en ce sens que ses branches vivent longtemps. Il y a des branches de version qui vivent longtemps, des branches de fonctionnalit\u00e9s qui vivent \u00e9galement longtemps. Cette pratique a \u00e9t\u00e9 plac\u00e9e en HOLD dans le Technology Radar. Pourquoi ? Parce que les gens rencontrent des difficult\u00e9s d'int\u00e9gration. <\/p>\n

<\/p>\n

Si votre branche vit tr\u00e8s longtemps, elle commence \u00e0 prendre du retard, nous commen\u00e7ons \u00e0 passer plus de temps \u00e0 y apporter un changement. <\/p>\n

<\/p>\n

R\u00e9cemment, l'auteur de Gitflow a d\u00e9clar\u00e9 que si vous aspirez \u00e0 l'int\u00e9gration continue, si vous souhaitez effectuer des mises \u00e0 jour aussi souvent que possible, alors Gitflow est une mauvaise id\u00e9e. Il a \u00e9galement mentionn\u00e9 dans un article s\u00e9par\u00e9 que si vous avez un backend o\u00f9 vous pouvez faire cela, Gitflow est superflu pour vous, car il vous ralentira et causera des probl\u00e8mes d'int\u00e9gration. <\/p>\n

<\/p>\n

Cela ne signifie pas que Gitflow est mauvais et qu'il ne faut pas l'utiliser. Il est adapt\u00e9 \u00e0 d'autres cas. Par exemple, lorsque vous devez maintenir plusieurs versions d'un service ou d'une application, c'est-\u00e0-dire lorsque vous devez fournir un support sur une p\u00e9riode prolong\u00e9e. <\/p>\n

<\/p>\n

Mais si vous parlez \u00e0 des personnes qui maintiennent de tels services, vous entendrez beaucoup de plaintes sur le fait que cette version \u00e9tait 3.2, qui a \u00e9t\u00e9 publi\u00e9e il y a 4 mois, et que ce correctif n'y figurait pas, et maintenant, pour l'int\u00e9grer, il faut apporter beaucoup de modifications. Et les voil\u00e0 de nouveau bloqu\u00e9s, et ils passent une semaine \u00e0 essayer de fusionner une nouvelle fonctionnalit\u00e9. <\/p>\n

<\/p>\n

Comme Alexander Kovalev l'a justement not\u00e9 dans le chat, la corr\u00e9lation n'est pas \u00e9quivalente \u00e0 la causalit\u00e9. C'est vrai. C'est-\u00e0-dire qu'il n'y a pas de lien direct selon lequel si vous avez une int\u00e9gration continue, alors toutes les m\u00e9triques seront excellentes, non. Mais il existe une corr\u00e9lation positive, c'est-\u00e0-dire que si l'un est vrai, l'autre est probablement \u00e9galement vrai. Ce n'est pas un fait, mais c'est fort probable. Ce n'est qu'une corr\u00e9lation. <\/p>\n

<\/p>\n

\"L'int\u00e9gration<\/p>\n

<\/p>\n

On dirait que nous faisons d\u00e9j\u00e0 quelque chose, que nous fusionnons d\u00e9j\u00e0, mais comment savoir si nous avons r\u00e9ellement l'int\u00e9gration continue et que nous fusionnons suffisamment souvent ?<\/p>\n

<\/p>\n

Jez Humble est l'auteur du Handbook, Accelerate, du site Continuous Delivery et du livre \u00ab Continuous Delivery \u00bb. Il propose un test comme celui-ci :<\/p>\n

<\/p>\n