Voyons pourquoi les outils CI et CI sont des choses complètement différentes.
Quelle douleur CI est-il censé résoudre, d'où est venue l'idée, quelles sont les dernières confirmations que cela fonctionne, comment comprendre que vous avez une pratique et pas seulement installé Jenkins.
L'idée de faire un reportage sur l'Intégration Continue est apparue il y a un an, alors que je me présentais à des entretiens et que je cherchais un emploi. J'ai parlé à 10 à 15 entreprises, une seule d'entre elles a pu répondre clairement à ce qu'est l'IC et expliquer comment elles ont réalisé qu'elles ne l'avaient pas. Les autres disaient des bêtises inintelligibles à propos de Jenkins :) Eh bien, nous avons Jenkins, il construit, CI ! Au cours du rapport, j'essaierai d'expliquer ce qu'est réellement l'intégration continue et pourquoi Jenkins et les outils similaires ont une relation très faible avec cela.
Alors, qu’est-ce qui vous vient généralement à l’esprit lorsque vous entendez le mot CI ? La plupart des gens penseront à Jenkins, Gitlab CI, Travis, etc.
Même si nous le recherchons sur Google, cela nous donnera ces outils.
Si vous êtes habitué à demander, immédiatement après avoir répertorié les outils, ils vous diront que CI est lorsque vous créez et exécutez des tests dans une Pull Request pour une validation.
L'intégration continue n'est pas une question d'outils, ni d'assemblys avec des tests dans une branche ! L'intégration continue est la pratique d'intégration très fréquente de nouveau code et pour l'utiliser il n'est pas du tout nécessaire de clôturer Jenkins, GitLab, etc.
Avant de comprendre à quoi ressemble un IC à part entière, plongeons d'abord dans le contexte des personnes qui l'ont inventé et ressentons la douleur qu'ils essayaient de résoudre.
Et ils ont résolu la douleur de travailler ensemble en équipe !
Examinons des exemples des difficultés rencontrées par les développeurs lorsqu'ils développent en équipe. Ici nous avons un projet, une branche master dans git et deux développeurs.
Et ils se mirent au travail comme tout le monde était habitué depuis longtemps. Nous avons pris en charge une tâche dans le grand schéma des choses, créé une branche de fonctionnalités et écrit le code.
L'un d'entre eux a terminé la fonctionnalité plus rapidement et l'a fusionnée dans le maître.
Le second a nécessité plus de temps, il a fusionné plus tard et s'est soldé par un conflit. Désormais, au lieu d'écrire les fonctionnalités dont l'entreprise a besoin, le développeur consacre son temps et son énergie à résoudre les conflits.
Plus il est difficile de combiner votre fonctionnalité avec un master commun, plus nous y consacrons du temps. Et je l'ai montré avec un exemple assez simple. Ceci est un exemple où il n'y a que 2 développeurs. Imaginez si 10, 15 ou 100 personnes dans une entreprise écrivent sur un seul référentiel. Vous deviendrez fou pour résoudre tous ces conflits.
Il existe un cas légèrement différent. Nous avons un maître et des développeurs qui font quelque chose.
Ils ont créé une brindille.
L'un d'eux est mort, tout allait bien, il a réussi la tâche.
Le deuxième développeur, quant à lui, a remis sa tâche. Disons qu'il l'a envoyé pour examen. De nombreuses entreprises ont une pratique appelée révision. D’une part, cette pratique est bonne et utile, d’autre part, elle nous ralentit à bien des égards. Nous n’entrerons pas dans les détails, mais voici un excellent exemple de ce à quoi peut conduire une mauvaise critique. Vous avez soumis une pull request pour examen. Le développeur n'a plus rien à faire. Que commence-t-il à faire ? Il commence à assumer d'autres tâches.
Pendant ce temps, le deuxième développeur a fait autre chose.
Le premier a accompli la troisième tâche.
Et après un certain temps, son avis a été mis à l'épreuve et il essaie de se réconcilier. Alors que se passe-t-il? Il détecte un grand nombre de conflits. Pourquoi? Parce que pendant que sa pull request était en attente de révision, beaucoup de choses avaient déjà changé dans le code.
En plus de l’histoire des conflits, il y a une histoire des communications. Pendant que votre fil est en attente de révision, pendant qu'il attend quelque chose, pendant que vous travaillez sur une fonctionnalité pendant une longue période, vous arrêtez de suivre ce qui change dans la base de code de votre service. Peut-être que ce que vous essayez de résoudre maintenant a déjà été résolu hier et que vous pouvez utiliser une méthode et la réutiliser. Mais vous ne le verrez pas car vous travaillez toujours avec une branche obsolète. Et cette branche obsolète vous oblige toujours à résoudre un conflit de fusion.
Il s'avère que si nous travaillons en équipe, c'est-à-dire que ce n'est pas une personne qui fouille dans le référentiel, mais 5 à 10 personnes, alors plus nous n'ajoutons pas notre code au maître, plus nous souffrons car nous avons finalement besoin quelque chose puis fusionnez-le. Et plus nous avons de conflits et plus nous travaillons avec une ancienne version, plus nous avons de problèmes.
Faire quelque chose ensemble est douloureux ! Nous nous gênons toujours les uns les autres.
Ce problème a été remarqué il y a plus de 20 ans. J'ai trouvé la première mention de la pratique de l'intégration continue dans l'Extreme Programming.
Extreme Programming est le premier framework agile. La page est parue en 96. Et l'idée était d'utiliser une sorte de pratique de programmation, de planification et d'autres choses, afin que le développement soit aussi flexible que possible, afin que nous puissions répondre rapidement à tout changement ou exigence de nos clients. Et ils ont commencé à se rendre compte il y a 24 ans que si vous faites quelque chose pendant très longtemps et en marge, vous y consacrez plus de temps parce que vous avez des conflits.
Nous allons maintenant analyser l'expression « Intégration continue » individuellement. Si nous le traduisons directement, nous obtenons une intégration continue. Mais la continuité n’est pas très claire ; c’est très discontinu. Mais son degré d’intégration n’est pas non plus très évident.
Et c'est pourquoi je vous donne maintenant des citations d'Extreme Programming. Et nous analyserons les deux mots séparément.
Intégration - Comme je l'ai déjà dit, nous nous efforçons de faire en sorte que chaque ingénieur travaille avec la version la plus récente du code, afin qu'il s'efforce d'ajouter son code le plus souvent possible à une branche commune, afin qu'il s'agisse de petites branches. Parce que s’ils sont volumineux, nous pouvons facilement nous retrouver coincés dans des conflits de fusion pendant une semaine. Cela est particulièrement vrai si nous avons un long cycle de développement tel que Waterfall, où le développeur s'est absenté pendant un mois pour supprimer une fonctionnalité énorme. Et il restera bloqué très longtemps au stade de l’intégration.
L'intégration, c'est lorsque nous prenons notre branche et l'intégrons au maître, nous la fusionnons. Il existe une option ultime lorsque nous sommes un développeur transbase, où nous nous efforçons de garantir que nous écrivons immédiatement dans le maître sans aucune branche supplémentaire.
En général, l'intégration signifie prendre votre code et le faire glisser dans le maître.
Qu’entend-on ici par le mot « continu », qu’appelle-t-on continuité ? La pratique implique que le développeur s'efforce d'intégrer son code le plus rapidement possible. C'est son objectif lors de l'exécution de n'importe quelle tâche : faire passer son code en maître le plus rapidement possible. Dans un monde idéal, les développeurs feraient cela toutes les quelques heures. Autrement dit, vous prenez un petit problème et le fusionnez dans le maître. Tout est bon. C’est ce à quoi vous aspirez. Et cela doit être fait en permanence. Dès que vous faites quelque chose, vous le transmettez immédiatement au maître.
Et le développeur qui crée quelque chose est responsable de ce qu’il a fait pour que cela fonctionne et ne rien casser. C’est là que sort généralement l’histoire du test. Nous voulons exécuter quelques tests sur notre commit, sur notre fusion, pour nous assurer que cela fonctionne. Et c'est là que Jenkins peut vous aider.
Mais avec les histoires : faisons de petits changements, laissons les tâches être petites, créons un problème et essayons immédiatement de l'intégrer d'une manière ou d'une autre dans le maître - aucun Jenkins n'aidera ici. Parce que Jenkins vous aidera uniquement à exécuter des tests.
Vous pouvez vous en passer. Cela ne vous fera pas de mal du tout. Parce que le but de la pratique est de mesurer le plus souvent possible, afin de ne pas perdre énormément de temps sur d'éventuels conflits à l'avenir.
Imaginons que, pour une raison quelconque, nous soyons en 2020 sans Internet. Et nous travaillons localement. Nous n'avons pas Jenkins. C'est bon. Vous pouvez toujours créer une succursale locale. Vous y avez écrit du code. Nous avons terminé la tâche en 3-4 heures. Nous sommes passés à master, avons fait un git pull et y avons fusionné notre branche. Prêt. Si vous faites cela souvent, félicitations, vous disposez de l’Intégration Continue !
Quelles preuves existent dans le monde moderne pour lesquelles cela vaut la peine de dépenser de l’énergie ? Parce qu'en général c'est difficile. Si vous essayez de travailler ainsi, vous comprendrez que certains plannings seront désormais affectés, vous devrez consacrer plus de temps à décomposer les tâches. Parce que si vous faites l'homme..., alors vous ne pourrez pas vous réconcilier rapidement et, par conséquent, vous aurez des ennuis. Vous n'aurez plus de pratique.
Et ce sera cher. Il ne sera plus possible de travailler immédiatement à partir de demain grâce à l'intégration continue. Il vous faudra à tous très longtemps pour vous y habituer, il vous faudra très longtemps pour vous habituer à décomposer les tâches, il vous faudra très longtemps pour vous habituer à refaire la pratique de révision, si vous en avez une . Parce que notre objectif est qu'il fonde aujourd'hui. Et si vous effectuez une révision dans les trois jours, vous rencontrez des problèmes et l’intégration continue ne fonctionne pas pour vous.
Mais disposons-nous actuellement de preuves pertinentes qui nous indiquent qu’investir dans cette pratique est logique ?
La première chose qui m’est venue à l’esprit était l’état du DevOps. Il s'agit d'une étude que les gars mènent depuis 7 ans. Aujourd’hui, ils le font en tant qu’organisation indépendante, mais sous Google.
Et leur étude de 2018 a montré une corrélation entre les entreprises qui tentent d'utiliser des succursales éphémères qui s'intègrent rapidement, s'intègrent fréquemment et ont de meilleurs indicateurs de performance informatique.
Quels sont ces indicateurs ? Ce sont 4 métriques qu'ils prennent auprès de toutes les entreprises dans leurs questionnaires : fréquence de déploiement, délai de modification, délai de restauration du service, taux d'échec des modifications.
Et premièrement, il y a cette corrélation : nous savons que les entreprises qui mesurent fréquemment ont de bien meilleurs indicateurs. Et ils ont une division des entreprises en plusieurs catégories : ce sont des entreprises lentes qui produisent quelque chose lentement, moyennement performantes, très performantes et élites. L'élite est Netflix, Amazon, qui sont ultra rapides, font tout rapidement, magnifiquement et efficacement.
La deuxième histoire, qui s'est produite il y a à peine un mois. Technology Radar a un excellent article sur Gitflow. Gitflow est différent de tous les autres dans la mesure où ses branches ont une durée de vie longue. Il existe des branches de version qui durent longtemps et des branches de fonctionnalités qui durent également longtemps. Cette pratique chez Technology Radar a été transférée à HOLD. Pourquoi? Parce que les gens sont confrontés à la douleur de l’intégration.
Si votre branche vit très longtemps, elle reste bloquée, pourrit et nous commençons à passer plus de temps à essayer d'y apporter des modifications.
Et récemment, l'auteur de Gitflow a déclaré que si votre objectif est l'intégration continue, si votre objectif est de rouler le plus souvent possible, alors Gitflow est une mauvaise idée. Il a ajouté séparément à l'article que si vous disposez d'un backend sur lequel vous pouvez vous efforcer d'atteindre cet objectif, alors Gitflow est superflu pour vous, car Gitflow vous ralentira, Gitflow vous créera des problèmes d'intégration.
Cela ne veut pas dire que Gitflow est mauvais et ne doit pas être utilisé. C'est pour d'autres occasions. Par exemple, lorsque vous devez prendre en charge plusieurs versions d’un service ou d’une application, c’est-à-dire lorsque vous avez besoin d’une assistance sur une longue période.
Mais si vous parlez à des personnes qui soutiennent de tels services, vous entendrez beaucoup de douleur sur le fait que cette version était la 3.2, il y a 4 mois, mais que ce correctif n'y était pas inclus et maintenant, pour y parvenir, vous devez faire un tas de changements. Et maintenant, ils sont à nouveau bloqués, et maintenant ils bidouillent depuis une semaine pour essayer d'implémenter une nouvelle fonctionnalité.
Comme Alexander Kovalev l’a noté à juste titre dans la discussion, la corrélation n’est pas la même chose que la causalité. C'est vrai. Autrement dit, il n'y a pas de lien direct selon lequel si vous disposez d'une intégration continue, toutes les mesures seront excellentes. Mais il existe une corrélation positive selon laquelle si l’un est l’un, alors l’autre l’est probablement aussi. Ce n’est pas un fait, mais c’est très probable. C'est juste une corrélation.
Il semble que nous fassions déjà quelque chose, il semble que nous fusionnions déjà, mais comment comprendre que nous avons encore de l'Intégration Continue, que nous fusionnons assez souvent ?
Jez Humble est l'auteur de Handbook, Accelerate, du site Web Continuous Delivery et du livre Continuous Delivery. Il propose ce test :
- Le code de l'ingénieur parvient quotidiennement au maître.
- Pour chaque commit, vous exécutez des tests unitaires.
- Le build dans le master est tombé, il a été réparé en 10 minutes environ.
Il suggère d'utiliser un test comme celui-ci pour vous assurer que vous avez suffisamment de pratique.
Je trouve ce dernier un peu controversé. Autrement dit, si vous pouvez le réparer en 10 minutes, alors vous avez une intégration continue, cela semble un peu étrange, à mon avis, mais c'est logique. Pourquoi? Parce que si vous vous figez souvent, cela signifie que vos modifications sont minimes. Si un petit changement signifie que votre build principal est cassé, vous pouvez alors trouver un exemple rapidement car le changement est petit. Ici, vous avez eu une petite fusion, 20 à 30 lignes ont été modifiées. Et, par conséquent, vous pouvez rapidement comprendre quelle en était la raison, car les changements sont minimes, vous disposez d'une très petite zone pour rechercher le problème.
Et même si notre production s'effondre après la sortie, alors si nous avons la pratique de l'intégration continue, il nous est beaucoup plus facile d'agir, car les changements sont infimes. Oui, cela affectera la planification. Cela va faire mal. Et, probablement, la chose la plus difficile dans cette pratique est de s'habituer à décomposer les tâches, c'est-à-dire comment le faire pour pouvoir prendre quelque chose et le faire en quelques heures et en même temps passer un examen, si tu en as un. La révision est une douleur distincte.
Les tests unitaires ne sont qu'un assistant qui vous aide à comprendre si votre intégration a réussi et si rien n'a été cassé. À mon avis, ce n’est pas non plus entièrement obligatoire, car ce n’est pas le but de la pratique.
Ceci est une brève introduction à l’intégration continue. C'est tout ce qu'il y a à dire dans cette pratique. Je suis prêt à répondre aux questions.
Je vais juste résumer à nouveau brièvement :
- L'intégration continue n'est pas Jenkins, ce n'est pas Gitlab.
- Ce n'est pas un outil, c'est une pratique selon laquelle nous fusionnons notre code dans le maître aussi souvent que possible.
- Nous faisons cela afin d'éviter l'énorme douleur qui surviendra lors des fusions à l'avenir, c'est-à-dire que nous éprouvons un peu de douleur maintenant pour ne pas en ressentir davantage à l'avenir. Exactement.
- Sur le côté il y a une communication par code, mais je vois très rarement cela, mais c'est aussi pour cela qu'il a été conçu.
des questions
Que faire des tâches non décomposées ?
Décomposer. Quel est le problème? Pouvez-vous donner un exemple illustrant qu'il existe une tâche et qu'elle n'est pas décomposée ?
Il y a des tâches qui ne peuvent pas être décomposées par le mot « complètement », par exemple celles qui nécessitent une expertise très approfondie et qui peuvent en fait être résolues en un mois pour obtenir un résultat digeste.
Si je vous comprends bien, il y a alors une tâche importante et complexe dont le résultat ne sera visible que dans un mois ?
Oui c'est vrai. Oui, il sera possible d'évaluer le résultat au plus tôt dans un mois.
Bien. En général, ce n'est pas un problème. Pourquoi? Car dans ce cas, quand on parle de brindilles, nous ne parlons pas d’une brindille avec une particularité. Les fonctionnalités peuvent être volumineuses et complexes. Ils peuvent affecter un grand nombre de composants. Et peut-être que nous ne pouvons pas les réaliser entièrement dans une seule branche. C'est bon. Nous devons juste décomposer cette histoire. Si une fonctionnalité n’est pas complètement prête, cela ne signifie pas que certaines parties de son code ne peuvent pas être fusionnées. Vous avez ajouté, disons, la migration et il y a quelques étapes à l'intérieur de la fonctionnalité. Disons que vous avez une étape : effectuez une migration, ajoutez une nouvelle méthode. Et vous pouvez déjà mesurer ces choses chaque jour.
Bien. A quoi ça sert alors ?
A quoi ça sert de tuer des petites choses tous les jours ?
Oui.
S'ils cassent quelque chose, vous le voyez tout de suite. Vous avez un petit morceau qui a cassé quelque chose, il vous est plus facile de le réparer. Le fait est qu’il est beaucoup plus facile de fusionner un petit élément maintenant que de fusionner quelque chose de grand en quelques semaines. Et le troisième point est que d’autres ingénieurs travailleront avec la version actuelle du code. Ils verront que certaines migrations ont été ajoutées ici, puis une méthode est apparue qu'ils voudront peut-être également utiliser. Tout le monde verra ce qui se passe dans votre code. C'est pour ces trois choses que l'on pratique.
Merci, le sujet est clos !
(Oleg Soroka) Puis-je ajouter ? Vous avez tout dit correctement, je veux juste ajouter une phrase.
So.
Avec l'intégration continue, le code est fusionné dans une branche commune non pas lorsque la fonctionnalité est complètement prête, mais lorsque la build cesse de se briser. Et vous pouvez vous engager en toute sécurité à maîtriser autant de fois par jour que vous le souhaitez. Le deuxième aspect est que si, pour une raison quelconque, vous ne pouvez pas diviser la tâche mensuelle en tâches pendant au moins trois jours, je reste silencieux pendant environ trois heures, alors vous avez un énorme problème. Et le fait que vous n'ayez pas d'intégration continue est le moindre de ces problèmes. Cela signifie que vous avez des problèmes d’architecture et aucune pratique d’ingénierie. Car même s’il s’agit de recherche, elle doit en tout cas être formulée sous forme d’hypothèses ou de cycle.
Nous avons parlé de 4 indicateurs qui distinguent les entreprises qui réussissent de celles qui sont en retard. Il nous faut encore vivre pour voir ces 4 métriques. Si votre tâche moyenne prend un mois, je me concentrerais d'abord sur cette mesure. Je le réduirais d'abord à 3 jours. Et après ça, j’ai commencé à penser à Continu.
Ai-je bien compris que vous pensez qu'en général, il ne sert à rien d'investir dans des pratiques d'ingénierie si une tâche prend un mois ?
Vous disposez d'une intégration continue. Et il existe un tel sujet qu'en 10 minutes, vous pouvez soit corriger un correctif, soit l'annuler. Imaginez que vous l'avez déployé. De plus, vous disposez même d'un déploiement continu, vous l'avez déployé en production et vous avez ensuite remarqué que quelque chose n'allait pas. Et vous devez le restaurer, mais vous avez déjà migré votre base de données. Vous disposez déjà du schéma de base de données de la prochaine version. De plus, vous disposiez également d'une sorte de sauvegarde et les données y étaient également écrites.
Et quelle alternative avez-vous ? Si vous annulez le code, il ne pourra plus fonctionner avec cette base de données mise à jour.
La base ne fait qu'avancer, oui.
Les personnes qui ont de mauvaises pratiques d’ingénierie n’ont probablement pas lu le livre épais sur... non plus. Que faire de la sauvegarde ? Si vous restaurez à partir d'une sauvegarde, cela signifie que vous perdez les données que vous avez accumulées à ce moment-là. Par exemple, nous avons travaillé pendant trois heures avec la nouvelle version de la base de données, les utilisateurs y étaient enregistrés. Vous refusez l'ancienne sauvegarde car le schéma ne fonctionne pas avec la nouvelle version, vous avez donc perdu ces utilisateurs. Et ils sont mécontents, jurent-ils.
Afin de maîtriser l'ensemble des pratiques qui prennent en charge l'intégration continue et la livraison continue, il ne suffit pas d'apprendre à écrire.... Premièrement, il peut y en avoir beaucoup, ce sera peu pratique. De plus, il existe de nombreuses autres pratiques comme celles scientifiques. Une telle pratique existe, GitHub l'a popularisée à un moment donné. C’est à ce moment-là que l’ancien code et le nouveau code s’exécutent en même temps. C'est à ce moment-là que vous créez une fonctionnalité inachevée, mais qu'elle peut renvoyer une certaine valeur : soit en tant que fonction, soit en tant qu'API Rest. Vous exécutez à la fois le nouveau code et l’ancien code et comparez la différence entre eux. Et s'il y a une différence, vous enregistrez cet événement. De cette façon, vous savez que vous disposez d’une nouvelle fonctionnalité prête à être déployée par-dessus l’ancienne si vous n’avez pas eu de divergence entre les deux depuis un certain temps.
Il existe des centaines de pratiques de ce type. Je suggérerais de commencer par le développement transbase. Elle n'est pas à 100% sur l'Intégration Continue, mais les pratiques sont les mêmes, l'une ne peut bien vivre sans l'autre.
Avez-vous donné le développement transbase comme exemple où vous pouvez voir des pratiques ou suggérez-vous aux gens de commencer à utiliser le développement transbase ?
Jetez un œil, car ils ne pourront pas l’utiliser. Pour les utiliser, vous devez lire beaucoup. Et quand une personne demande : « Que faire d'une fonctionnalité qui prend un mois, cela signifie qu'elle n'a pas lu sur le développement de transbase. » Je ne le recommanderais pas pour l'instant. Je conseillerais de se concentrer uniquement sur la manière de diviser correctement les tâches volumineuses en tâches plus petites. C'est l'essence de la décomposition.
La décomposition est l'un des outils de l'architecte. Nous faisons d’abord l’analyse, puis la décomposition, puis la synthèse, puis l’intégration. Et c’est ainsi que tout se passe pour nous. Et nous devons encore progresser vers l’intégration continue par la décomposition. Des questions se posent dès la première étape, et nous parlons déjà de la quatrième étape, c'est-à-dire que plus nous intégrons souvent, mieux c'est. Il est encore trop tôt pour le faire ; ce serait bien de d’abord abattre votre monolithe.
Vous devez dessiner un certain nombre de flèches et de carrés sur un diagramme. Vous ne pouvez pas dire que maintenant je vais montrer le schéma architectural d'une nouvelle application et montrer un carré, à l'intérieur duquel se trouve un bouton vert pour l'application. Dans tous les cas, il y aura davantage de carrés et de flèches. Chaque diagramme que j’ai vu en avait plus d’un. Et la décomposition, même au niveau de la représentation graphique, est déjà en cours. Les carrés peuvent donc être rendus indépendants. Sinon, j'ai de grandes questions à poser à l'architecte.
Il y a une question du chat : « Si une révision est obligatoire et prend beaucoup de temps, peut-être un jour ou plus ?
Vous avez des problèmes avec la pratique. L'examen ne devrait pas durer un jour ou plus. C'est la même histoire que la question précédente, mais en un peu plus douce. Si un examen dure une journée, il est fort probable que cet examen entraîne un très grand changement. Cela signifie qu'il doit être réduit. Dans le développement Transbase, recommandé par Oleg, il existe une histoire appelée révision continue. Son idée est que nous faisons exprès une si petite pull request, car nous nous efforçons de fusionner constamment et petit à petit. Et donc la pull request modifie une abstraction ou 10 lignes. Grâce à cet examen, cela nous prend quelques minutes.
Si l'examen prend un jour ou plus, quelque chose ne va pas. Premièrement, vous pourriez rencontrer des problèmes avec l’architecture. Ou bien il s’agit d’un gros morceau de code, de 1 000 lignes par exemple. Ou votre architecture est si complexe qu’une personne ne peut pas la comprendre. Il s’agit d’un problème légèrement secondaire, mais il faudra également le résoudre. Il n’est peut-être pas du tout nécessaire de procéder à un examen. Nous devons également y réfléchir. La révision est ce qui vous ralentit. Cela présente des avantages en général, mais vous devez comprendre pourquoi vous le faites. Est-ce une façon pour vous de transmettre rapidement des informations, est-ce une façon pour vous de fixer des normes en interne ou quoi ? Pourquoi as-tu besoin de ça ? Parce que l’examen doit être fait très rapidement, ou complètement annulé. C'est comme le développement de Transbase - l'histoire est très belle, mais seulement pour les gars matures.
Concernant les 4 métriques, je recommanderais quand même de les supprimer pour comprendre à quoi cela conduit. Regardez les chiffres, regardez l’image, à quel point tout va mal.
(Dmitry) Je suis prêt à en discuter avec vous. Les chiffres et les mesures sont tous excellents, les pratiques sont excellentes. Mais vous devez comprendre si l'entreprise en a besoin. Certaines entreprises n’ont pas besoin d’un changement aussi rapide. Je connais des entreprises où les changements ne peuvent pas être effectués toutes les 15 minutes. Et pas parce qu’ils sont si mauvais. C'est un tel cycle de vie. Et pour que la fonction de branchement soit la fonction de bascule, vous avez besoin de connaissances approfondies.
C'est compliqué. Si vous souhaitez lire l'histoire de la fonctionnalité bascule plus en détail, je vous la recommande vivement. . Et il existe un merveilleux article de Martin Fowler sur les fonctionnalités à bascule : quels types il existe, cycles de vie, etc. La fonctionnalité à bascule est compliquée.
Et vous n’avez toujours pas répondu à la question : « Jenkins est-il nécessaire ou non ?
Jenkins n'est en aucun cas vraiment nécessaire. Sérieusement, les outils : Jenkins, Gitlab vous apporteront du confort. Vous verrez que l'ensemble est assemblé ou non. Ils peuvent vous aider, mais ils ne vous donneront pas de pratique. Ils ne peuvent que vous donner un cercle – Ok, pas Ok. Et puis, si vous écrivez aussi des tests, car s’il n’y a pas de tests, alors cela ne sert presque à rien. C’est donc nécessaire car c’est plus pratique, mais en général, vous pouvez vous en passer, vous ne perdrez pas grand-chose.
Autrement dit, si vous avez des pratiques, cela signifie-t-il que vous n’en avez pas besoin ?
C'est exact. Je recommande le test Jez Humble. Là, j'ai une attitude ambivalente sur le dernier point. Mais en général, si vous avez trois choses, que vous fusionnez constamment, que vous exécutez des tests sur les commits dans le master, que vous corrigez rapidement la build dans le master, alors peut-être que vous n'avez besoin de rien d'autre.
En attendant les questions des participants, j'ai une question. Nous parlions juste du code produit. L'avez-vous utilisé pour le code d'infrastructure ? Est-ce le même code, a-t-il les mêmes principes et le même cycle de vie, ou existe-t-il des cycles de vie et des principes différents ? Habituellement, quand tout le monde parle d’Intégration et de Développement Continus, tout le monde oublie qu’il existe aussi du code d’infrastructure. Et dernièrement, il y en a eu de plus en plus. Et faut-il y apporter toutes ces règles ?
Même si cela ne devrait pas être le cas, ce serait formidable car cela faciliterait la vie de la même manière. Dès que nous travaillons avec du code, pas avec des scripts bash, mais nous avons du code normal.
Stop, stop, un script bash c'est aussi du code. Ne touche pas à mon ancien amour.
D'accord, je ne piétinerai pas vos souvenirs. J'ai une aversion personnelle pour bash. C'est moche et effrayant tout le temps. Et ça casse souvent de manière imprévisible, c’est pourquoi je n’aime pas ça. Mais bon, disons que vous avez du code bash. Peut-être que je ne comprends vraiment pas et qu'il existe des frameworks de test normaux. Je ne suis tout simplement pas au courant. Et nous bénéficions des mêmes avantages.
Dès que nous travaillons avec une infrastructure en tant que code, nous rencontrons les mêmes problèmes que les développeurs. Il y a quelques mois, j'ai été confronté à une situation où un collègue m'a envoyé une pull request de 1 000 lignes en bash. Et vous restez à la revue pendant 4 heures. Les mêmes problèmes se posent. C'est toujours du code. Et c'est toujours une collaboration. Nous restons coincés avec la pull request et nous restons coincés avec le fait que nous résolvons les mêmes conflits de fusion dans le même bash, par exemple.
Je regarde maintenant très activement toute cette histoire de la plus belle programmation infra. J'ai maintenant introduit Pulumi dans l'infrastructure. C'est de la programmation dans sa forme la plus pure. Là, c'est encore plus sympa, car j'ai toutes les capacités d'un langage de programmation, c'est à dire que j'ai fait de belles bascules à l'improviste avec les mêmes si et tout va bien. Autrement dit, ma modification est déjà dans le maître. Tout le monde peut déjà le voir. D'autres ingénieurs le savent. Cela a déjà influencé quelque chose là-bas. Cependant, cela n’a pas été activé pour toutes les infrastructures. Il s'est allumé pour mes bancs de tests par exemple. Par conséquent, il est nécessaire de répondre à nouveau à votre question. Cela nous facilite la vie, en tant qu'ingénieurs travaillant avec du code, de la même manière.
Si quelqu'un d'autre a des questions ?
J'ai une question. Je veux continuer la discussion avec Oleg. En général, je pense que vous avez raison, que si une tâche prend un mois, alors vous avez un problème d'architecture, vous avez un problème d'analyse, de décomposition, de planification, etc. Mais j'ai le sentiment que si vous commencez en essayant de vivre selon l'intégration continue, vous commencerez alors à corriger la douleur avec la planification, car vous ne pourrez y échapper nulle part ailleurs.
(Oleg) Oui, c'est vrai. Cette pratique est comparable en effort à toute autre pratique sérieuse de changement de culture. La chose la plus difficile à surmonter, ce sont les habitudes, surtout les mauvaises. Et si pour mettre en œuvre cette pratique, un changement sérieux dans les habitudes de votre entourage s'impose : développeurs, direction, responsable de production, alors des surprises vous attendent.
Quelles surprises pourrait-il y avoir ? Disons que vous décidez de vous intégrer plus souvent. Et il y a d'autres éléments liés à l'intégration, par exemple les artefacts. Et dans votre entreprise, par exemple, il existe une politique selon laquelle chaque artefact doit être comptabilisé d'une manière ou d'une autre dans une sorte de système de stockage d'artefacts. Et cela prend du temps. Une personne doit cocher la case indiquant qu'elle, en tant que gestionnaire de versions, a testé cet artefact pour s'assurer qu'il est prêt à être publié en production. Si cela prend 5-10-15 minutes, mais que vous effectuez la mise en page une fois par semaine, alors passer une demi-heure une fois par semaine est une petite taxe.
Si vous effectuez une intégration continue 10 fois par jour, alors 10 fois doivent être multipliés par 30 minutes. Et cela dépasse le temps de travail de ce gestionnaire de versions. Il en a juste marre de faire ça. Il y a des frais fixes pour certaines pratiques. C'est tout.
Et vous devez soit annuler cette règle pour ne plus faire de telles ordures, c'est-à-dire vous n'attribuez pas manuellement un diplôme pour correspondre à quelque chose. Vous comptez entièrement sur un ensemble automatisé de tests de préparation.
Et si vous avez besoin d'une preuve de quelqu'un pour que le patron la signe, et que vous ne vous lancez pas dans la production sans que Vasya dise qu'il le permet, etc. - toutes ces absurdités gênent le praticien. Parce que s’il y a certaines activités associées à une taxe, alors tout est multiplié par 100. Par conséquent, ce changement ne sera souvent pas accueilli avec joie par tout le monde. Parce que les habitudes des gens sont difficiles à changer.
Lorsqu'une personne fait son travail habituel, elle le fait presque sans réfléchir. Sa charge cognitive est nulle. Il joue avec, il a déjà une check-list en tête, il l’a fait mille fois. Et dès qu’on vient lui dire : « Annulons cette pratique et introduisons-en une nouvelle à partir de lundi », cela devient pour lui une puissante charge cognitive. Et cela concerne tout le monde en même temps.
Par conséquent, la chose la plus simple, même si tout le monde ne peut pas se permettre ce luxe, mais c'est ce que je fais toujours, c'est la suivante. Si un nouveau projet démarre, toutes les pratiques non testées sont généralement immédiatement intégrées à ce projet. Même si le projet est jeune, nous ne risquons vraiment rien. Il n'y a pas encore de Prod, il n'y a rien à détruire. Il peut donc être utilisé comme formation. Cette approche fonctionne. Mais toutes les entreprises n’ont pas souvent la possibilité de lancer de tels projets. Bien que cela soit aussi un peu étrange, car il y a maintenant une transformation numérique complète, chacun doit lancer des expériences pour suivre la concurrence.
Ici, vous arrivez à la conclusion que vous devez d’abord comprendre ce que vous devez faire. Le monde n’est pas idéal, et la production ne l’est pas non plus.
Oui, ces choses sont interconnectées.
Les entreprises ne comprennent pas toujours non plus qu’elles doivent suivre cette voie.
Il existe une situation dans laquelle aucun changement n’est possible. C’est une situation où il y a plus de pression sur l’équipe. L’équipe est déjà assez épuisée. Elle n'a pas de temps libre pour des expériences. Ils travaillent sur les fonctionnalités du matin au soir. Et la gestion a de moins en moins de fonctionnalités. Il en faut de plus en plus. Dans une telle situation, aucun changement n’est possible. On peut seulement dire à l'équipe que demain nous ferons la même chose qu'hier, il nous reste juste à faire un peu plus de fonctionnalités. En ce sens, aucune transition vers une quelconque pratique n’est possible. C'est une situation classique où on n'a pas le temps d'aiguiser la hache, il faut abattre les arbres, alors ils les coupent avec une hache émoussée. Il n’y a pas de conseils simples ici.
(Dmitry) Je vais lire une clarification du chat : « Mais nous avons besoin de beaucoup de couverture de tests à différents niveaux. Combien de temps est alloué aux tests ? C’est un peu cher et prend beaucoup de temps.
(Oleg) C'est une idée fausse classique. Il devrait y avoir suffisamment de tests pour que vous soyez confiant. L'intégration continue n'est pas une chose où 100 % des tests sont effectués en premier et ensuite seulement vous commencez à appliquer cette pratique. L'intégration continue réduit votre charge cognitive car chacun des changements que vous voyez avec vos yeux est si évident que vous comprenez si cela va casser quelque chose ou non, même sans tests. Vous pouvez rapidement tester cela dans votre tête car les changements sont minimes. Même si vous ne disposez que de testeurs manuels, c’est aussi plus facile pour eux. Vous vous êtes déployé et avez dit : « Écoutez, est-ce que quelque chose est cassé ? » Ils ont vérifié et ont dit : « Non, rien n’est cassé. » Parce que le testeur sait où chercher. Vous avez un commit associé à un morceau de code. Et cela est exploité par des comportements spécifiques.
Ici, bien sûr, vous avez embelli.
(Dmitry) Je ne suis pas d'accord ici. Il existe une pratique - le développement piloté par les tests, qui vous en évitera.
(Oleg) Eh bien, je n’en suis pas encore là. La première illusion est que vous devez écrire 100 % des tests ou que vous n’avez pas du tout besoin de faire de l’intégration continue. Ce n'est pas vrai. Ce sont deux pratiques parallèles. Et ils ne sont pas directement dépendants. Votre couverture de test doit être optimale. Optimal - cela signifie que vous êtes vous-même sûr que la qualité du master dans lequel votre master est resté après le commit vous permet d'appuyer en toute confiance sur le bouton « Déployer » un vendredi soir ivre. Comment y parvenir ? Grâce à un examen, à une couverture médiatique et à un bon suivi.
Une bonne surveillance ne se distingue pas des tests. Si vous exécutez des tests une fois en pré-prod, ils vérifient tous vos scripts utilisateur une fois et c'est tout. Et si vous les exécutez dans une boucle sans fin, alors c'est votre système de surveillance déployé, qui teste tout sans fin - qu'il tombe en panne ou non. Dans ce cas, la seule différence est de savoir si cela est fait une ou deux fois. Une très bonne série de tests... fonctionnant sans fin, c'est de la surveillance. Et une surveillance appropriée devrait être comme ça.
Et par conséquent, comment exactement vous atteindrez cet état lorsque vous vous préparerez vendredi soir et rentrerez chez vous est une autre question. Peut-être que tu n'es qu'un salopard audacieux.
Revenons un peu à l'intégration continue. Nous nous sommes enfuis dans une pratique complexe légèrement différente.
Et la deuxième illusion est que le MVP, disent-ils, doit être réalisé rapidement, donc les tests ne sont donc pas du tout nécessaires. Pas certainement de cette façon. Le fait est que lorsque vous écrivez une user story dans un MVP, vous pouvez soit la développer sur le coup, c'est-à-dire que vous avez entendu qu'il y avait une sorte de user story et que vous avez immédiatement couru pour la coder, soit vous pouvez travailler en utilisant TDD. Et selon TDD, comme le montre la pratique, cela ne prend pas plus de temps, c'est-à-dire que les tests sont un effet secondaire. La pratique du TDD ne consiste pas à tester. Malgré ce qu’on appelle le Test Driven Development, il ne s’agit pas du tout de tests. Il s’agit aussi plutôt d’une approche architecturale. Il s’agit d’une approche permettant d’écrire exactement ce qui est nécessaire et de ne pas écrire ce qui n’est pas nécessaire. Il s'agit d'une pratique consistant à se concentrer sur la prochaine itération de votre réflexion en termes de création d'une architecture d'application.
Il n’est donc pas si facile de se débarrasser de ces illusions. MVP et tests ne se contredisent pas. Même au contraire, si vous faites MVP en utilisant la pratique du TDD, vous le ferez mieux et plus rapidement que si vous le faites sans pratique du tout, mais sur un ballon.
C’est une idée très peu évidente et complexe. Quand vous entendez que maintenant je vais écrire plus de tests et en même temps je ferai quelque chose de plus rapide, cela semble absolument inadéquat.
(Dmitry) Beaucoup de gens ici, lorsqu'ils appellent MVP, sont trop paresseux pour écrire quelque chose de normal. Et ce sont encore des choses différentes. Il n’est pas nécessaire de transformer MVP en une mauvaise chose qui ne fonctionne pas.
Oui, oui, tu as raison.
Et puis du coup MVP en prod.
Toujours.
Et TDD semble très inhabituel lorsque vous entendez que vous écrivez des tests et semblez faire plus de travail. Cela semble très étrange, mais en fait, cela s'avère plus rapide et plus joli de cette façon. Lorsque vous écrivez un test, vous réfléchissez déjà beaucoup au type de code qui sera appelé et comment, ainsi qu'au comportement que nous attendons de lui. Vous ne dites pas simplement que j'ai écrit une fonction et qu'elle fait quelque chose. Au début, on pensait qu'elle avait telles ou telles conditions, qu'elle serait sollicitée de telle ou telle manière. Vous couvrez cela avec des tests et à partir de là, vous comprenez à quoi ressembleront vos interfaces dans votre code. Cela a un impact énorme sur l’architecture. Votre code devient automatiquement plus modulaire, car vous essayez d'abord de comprendre comment vous allez le tester, puis de l'écrire ensuite seulement.
Ce qui m'est arrivé avec TDD, c'est qu'à un moment donné, j'ai embauché un mentor Ruby alors que j'étais encore programmeur Ruby. Et il dit : « Faisons-le selon TDD ». J'ai pensé : "Merde, maintenant je dois écrire quelque chose de plus." Et nous avons convenu que dans deux semaines, j'écrirais tout le code de travail en Python en utilisant TDD. Au bout de deux semaines, j’ai réalisé que je ne voulais pas y retourner. Après deux semaines passées à essayer d’appliquer cela partout, vous réalisez à quel point il est devenu plus facile pour vous de simplement réfléchir. Mais ce n’est pas évident, donc je recommande à tout le monde que si vous avez le sentiment que le TDD est difficile, prend du temps et est inutile, essayez de vous y tenir pendant seulement deux semaines. Deux me suffisaient.
(Dmitry) Nous pouvons étendre cette idée du point de vue de l'exploitation des infrastructures. Avant de lancer quelque chose de nouveau, nous effectuons une surveillance puis lançons. Dans ce cas, la surveillance devient pour nous un test normal. Et il y a du développement grâce au suivi. Mais presque tout le monde dit que c’est long, je suis paresseux, j’ai fait un brouillon provisoire. Si nous avons effectué une surveillance normale, nous comprenons l'état du système CI. Et le système CI a beaucoup de surveillance. Nous comprenons l’état du système, nous comprenons ce qu’il contient. Et pendant le développement, nous faisons simplement en sorte que le système atteigne l'état souhaité.
Ces pratiques sont connues depuis longtemps. Nous en avons discuté il y a environ 4 ans. Mais en 4 ans, pratiquement rien n'a changé.
Mais sur ce point, je propose de mettre fin à la discussion officielle.
Vidéo (insérée comme élément multimédia, mais pour une raison quelconque, ne fonctionne pas) :
Source: habr.com