Infrastructure as Code : comment surmonter les problèmes avec XP

Bonjour, Habr ! Auparavant, je me plaignais de vivre dans la paradigme de l'Infrastructure as Code sans proposer de solutions pour la situation actuelle. Aujourd'hui, je suis de retour pour partager des approches et des pratiques qui peuvent nous sortir du désespoir et orienter la situation dans la bonne direction.

Dans l'article précédent « Infrastructure as Code : première acquaintance » J'ai partagé mes impressions sur ce domaine, tenté de réfléchir à la situation actuelle et même suggéré que les pratiques standards, connues de tous les développeurs, pourraient aider. On aurait pu croire qu'il y avait beaucoup de plaintes sur la vie, mais peu de propositions pour sortir de cette situation.

Qui nous sommes, où nous nous trouvons et quels sont nos problèmes

Nous faisons partie de l'équipe SRE Onboarding, qui se compose de six programmeurs et de trois ingénieurs en infrastructure. Nous essayons tous d'écrire Infrastructure as Code (IaC). Nous le faisons parce que nous savons en principe écrire du code et que nous avons un passé de développeurs de niveau 'au-dessus de la moyenne'.

• Nous avons un certain nombre d'avantages : un certain diplôme, la connaissance des pratiques, la capacité d'écrire du code et l'envie d'apprendre de nouvelles choses.
• Et il y a une lacune, qui est un inconvénient : un manque de connaissances sur les fondamentaux de l'infrastructure.

La pile technologique que nous utilisons dans notre IaC.

• Terraform pour créer des ressources.
• Packer pour la création d'images. Ce sont des images Windows et CentOS 7.
• Jsonnet pour créer des constructions puissantes dans drone.io, ainsi que pour générer du JSON Packer et nos modules Terraform.
• Azure.
• Ansible lors de la préparation des images.
• Python pour les services auxiliaires, ainsi que pour les scripts de provisionnement.
• Et tout cela dans VSCode avec des plugins partagés entre les membres de l'équipe.

Le résultat de mon dernier article était le suivant : j'ai tenté d'insuffler (en premier lieu à moi-même) de l'optimisme, je voulais dire que nous allions essayer les approches et pratiques connues pour surmonter les difficultés et les complexités présentes dans ce domaine.

Actuellement, nous faisons face à ces problèmes d'IaC :

• L'imperfection des outils et des moyens de développement de code.
• Déploiement lent. L'infrastructure fait partie du monde réel, et celui-ci peut être lent.
• Manque d'approches et de pratiques.
• Nous sommes nouveaux et savons peu de choses.

La programmation extrême (XP) vient à la rescousse

Tous les développeurs connaissent bien la programmation extrême (XP) et les pratiques qui l'accompagnent. Beaucoup d'entre nous ont travaillé selon cette approche, et elle a été fructueuse. Alors, pourquoi ne pas profiter des principes et des pratiques établis pour surmonter les difficultés d'infrastructure ? Nous avons décidé d'appliquer cette approche et de voir ce que cela donnerait.

Vérifier l'applicabilité de l'approche XP à votre domaineVoici la description de l'environnement pour lequel XP convient bien, et comment cela se rapporte à nous :

1. Exigences logicielles changeant dynamiquement. Nous avions une idée claire de notre objectif final. Mais les détails peuvent varier. Nous décidons nous-mêmes de notre orientation, donc les exigences changent périodiquement (généralement par nos propres décisions). Dans le cas d'une équipe SRE qui automatise elle-même et limite également les exigences et le périmètre de travail, ce point s'applique favorablement.

2. Risques causés par des projets à durée fixe utilisant de nouvelles technologies. Nous pouvons rencontrer des risques avec des choses qui ne nous sont pas familières. Et c'est 100 % notre cas. L'ensemble de notre projet repose sur l'utilisation de technologies dont nous n'avions pas une connaissance approfondie. En effet, c'est un problème constant, car de nombreuses nouvelles technologies apparaissent sans cesse dans le domaine de l'infrastructure.

3,4. Équipe de développement étendue, petite et co-localisée. La technologie que vous utilisez permet des tests unitaires et fonctionnels automatisés. Ces deux points ne s'appliquent pas vraiment à nous. Tout d'abord, nous ne sommes pas une équipe co-localisée, et ensuite, nous sommes neuf, ce qui peut être considéré comme une grande équipe. Bien que, selon certaines définitions, une « grande » équipe commence à partir de 14 personnes.

Examinons certaines pratiques de XP et comment elles influencent la rapidité et la qualité des retours.

Le principe du cycle de retour d'expérience en XP

À mon avis, le retour d'expérience est la réponse à la question, fais-je les choses correctement, allons-nous dans la bonne direction ? En XP, il y a ce schéma divin : le cycle de retour d'expérience dans le temps. L'intérêt réside dans le fait que plus nous sommes en bas, plus nous avons la possibilité de recevoir des retours rapidement pour répondre aux questions nécessaires.

C'est un sujet assez intéressant à discuter, car dans notre industrie informatique, il est possible d'obtenir rapidement des retours. Imaginez à quel point il est douloureux de travailler sur un projet pendant six mois et de découvrir ensuite qu'une erreur a été commise dès le début. Cela arrive aussi bien dans la conception que dans la construction de systèmes complexes.

Dans notre cas, l'IaC nous aide avec le retour d'information. Je vais immédiatement apporter un petit ajustement au schéma ci-dessus : le plan de publication ne se fait pas sur un cycle mensuel, mais plusieurs fois par jour. À ce cycle, certaines pratiques sont associées, que nous examinerons en détail.

Important : le retour d'information peut résoudre tous les problèmes mentionnés ci-dessus. En combinaison avec les pratiques XP, il peut sortir du gouffre du désespoir.

Comment se sortir du gouffre du désespoir : trois pratiques

Tests

Les tests sont mentionnés deux fois dans le cycle de retour d'information XP. Ce n'est pas par hasard. Ils sont extrêmement importants pour toute la technique de programmation extrême.

Il est supposé que vous avez des tests unitaires et d'acceptation. Les premiers vous donnent un retour en quelques minutes, les autres en quelques jours, car ils sont écrits plus longtemps, mais exécutés moins fréquemment.

Il existe une pyramide classique des tests qui montre qu'il doit y avoir plus de certains tests.

Comment ce schéma s'applique-t-il à notre projet IaC ? En réalité... pas du tout.

• Malgré le fait qu'il devrait y avoir beaucoup de tests unitaires, il ne peut pas y en avoir trop. Soit ils testent quelque chose de manière très indirecte. En fait, on peut dire qu'on n'en écrit pratiquement pas. Mais voici quelques applications pour de tels tests que nous avons tout de même pu réaliser :
  1. Test du code en jsonnet. C'est, par exemple, notre pipeline de construction dans drone, qui est assez complexe. Le code en jsonnet est bien couvert par des tests.
     Nous utilisons ce Cadre de test unitaire pour Jsonnet.
  2. Tests sur des scripts qui s'exécutent au démarrage de la ressource. Scripts en Python, donc des tests peuvent également être écrits pour eux.
• Il est potentiellement possible de vérifier la configuration dans les tests, mais nous ne le faisons pas. Il y a aussi la possibilité de configurer la vérification des règles de configuration des ressources via tflint. Cependant, pour Terraform, il y a trop de vérifications basiques, mais beaucoup de scénarios de vérification sont écrits pour AWS. Et nous sommes sur Azure, donc cela ne convient encore pas.
• Tests d'intégration des composants : cela dépend de la manière dont vous les classifiez et les structurez. Mais en principe, ils fonctionnent.

  Voici à quoi ressemblent les tests d'intégration.

  
  
  C'est un exemple lors de la construction d'images dans Drone CI. Pour y parvenir, il faut attendre 30 minutes que l'image Packer se construise, puis encore 15 minutes pour qu'elles passent. Mais elles existent !

  Algorithme de vérification des images

  1. Tout d'abord, Packer doit préparer complètement l'image.
  2. À côté du test, il y a Terraform avec un état local qui nous permet de déployer cette image.
  3. Lors du déploiement, un petit module, placé à proximité, est utilisé pour faciliter le travail avec l'image.
  4. Lorsque la VM est déployée à partir de l'image, nous pouvons commencer les vérifications. En général, les tests sont effectués sur la machine. Nous vérifions comment les scripts ont fonctionné au démarrage et comment les démons fonctionnent. Pour cela, nous accédons à la machine récemment levée via SSH ou WinRM, et vérifions l'état de la configuration ou si les services sont actifs.

• Une situation similaire s'applique aux tests d'intégration et aux modules pour Terraform. Voici un tableau récapitulatif expliquant les particularités de ces tests.

  
  
  Le retour sur le pipeline prend environ 40 minutes. Tout se passe très lentement. On peut l'utiliser pour des tests de régression, mais pour un nouveau développement, c'est pratiquement irréaliste. Si l'on se prépare vraiment très bien, en préparant des scripts d'exécution, cela peut être réduit à 10 minutes. Mais ce n'est pas pour autant des tests unitaires, qui en 5 secondes peuvent en exécuter 100.

L'absence de tests unitaires lors de la construction d'images ou de modules Terraform incite à déléguer le travail à des services distincts, que l'on peut simplement interroger via REST, ou à des scripts Python.

Par exemple, nous devions faire en sorte que, lors du démarrage de la machine virtuelle, elle s'enregistre dans le service ScaleFT, et qu'à la destruction de la VM, elle se supprime elle-même.

Comme ScaleFT est un service, nous devons interagir avec lui via l'API. Une couche a été écrite pour que l'on puisse simplement dire : « Va et supprime tel ou tel élément ». Elle conserve tous les paramètres et accès nécessaires.

Nous pouvons déjà écrire des tests appropriés, car cela ne diffère en rien d'un logiciel ordinaire : on simule un API, on l'interroge et on observe ce qui se passe.

Résultats des tests : Les tests unitaires, qui devraient être effectués par l'OS en une minute, ne le sont pas. Des niveaux de tests plus élevés dans la pyramide sont efficaces, mais ne couvrent qu'une partie des problèmes.

Programmation en binôme

Les tests, c'est bien sûr important. On peut en écrire beaucoup, il en existe de différents types. Ils fonctionneront à leurs niveaux respectifs et nous fourniront des retours d'information. Cependant, le problème avec les mauvais tests unitaires, qui offrent le système d'exploitation le plus rapide, persiste. Malgré cela, on aspire toujours à un système d'exploitation performant, avec lequel il est facile et agréable de travailler, sans parler de la qualité de la solution obtenue. Heureusement, il existe des techniques permettant de donner un feedback encore plus rapide que les tests unitaires. C'est là que le pair programming entre en jeu.

Lors de l'écriture de code, on souhaite obtenir un retour sur sa qualité aussi rapidement que possible. Oui, on peut tout écrire dans une branche de fonctionnalité (pour ne déranger personne), faire une demande de tirage sur GitHub, nommer quelqu'un dont l'opinion compte, et attendre une réponse.

Mais l'attente peut être longue. Les gens sont tous occupés, et même si une réponse arrive, elle peut ne pas être de la meilleure qualité. Supposons que la réponse arrive immédiatement, que le réviseur saisisse instantanément l'idée, mais la réponse arrive tout de même avec un retard, a posteriori. Ce qu'on souhaite, c'est de l'avoir plus tôt. C'est justement l'objectif du pair programming : intervenir immédiatement, au moment de l'écriture.

Voici les styles de pair programming et leur applicabilité dans le travail sur l'Infrastructure as Code (IaC) :

1. Classique, Expérimenté + expérimenté, changement au timer. Deux rôles – conducteur et navigateur. Deux personnes. Elles travaillent sur le même code et échangent leurs rôles après un certain laps de temps défini à l'avance.

Examinons la compatibilité de nos problèmes avec le style :

• Problème : imperfection des outils et des moyens de développement du code.
  Impact négatif : développement plus long, nous ralentissons, ce qui perturbe le rythme de travail.
  Comment nous luttons : nous utilisons d'autres outils, une IDE commune et nous apprenons également les raccourcis clavier.
• Problème : déploiement lent.
  Impact négatif : augmente le temps pour créer un morceau de code fonctionnel. Nous nous ennuyons en attendant, nos mains ont tendance à chercher à faire autre chose pendant que nous attendons.
  Comment nous luttons : nous n'avons pas réussi à résoudre ce problème.
• Problème : manque d'approches et de pratiques.
  Impact négatif : pas de connaissance sur ce qui est bien fait et ce qui est mal fait. Cela prolonge le temps de retour d'information.
  Comment nous luttons : l'échange d'opinions et de pratiques lors du travail en binôme résout presque le problème.

Le principal problème de l'application de ce style en IaC est le rythme de travail irrégulier. Dans le développement traditionnel de logiciels, tu as un mouvement très uniforme. Tu peux passer cinq minutes à écrire N, dix minutes à écrire 2N, et quinze minutes à écrire 3N. Ici, tu peux passer cinq minutes à écrire N, puis encore trente minutes à écrire un dixième de N. Ici, tu ne sais rien, tu es bloqué, tu éprouves des difficultés. Les clarifications prennent du temps et te détournent de la programmation proprement dite.

Conclusion : en l'état, cela ne nous convient pas.

2. Ping-pong. Cette approche suppose qu'un participant écrit le test, tandis qu'un autre en fait l'implémentation. Étant donné que les tests unitaires sont compliqués, et qu'il faut écrire un test d'intégration qui nécessite beaucoup de temps, toute la simplicité du ping-pong disparaît.

Je peux dire que nous avons essayé de diviser les responsabilités entre la conception du scénario de test et l'implémentation du code correspondant. Un participant imaginait le scénario, il était responsable dans cette partie du travail, il avait le dernier mot. L'autre était responsable de l'implémentation. Cela fonctionnait bien. La qualité du scénario augmente avec cette approche.

Conclusion : hélas, le rythme de travail ne permet pas d'utiliser le ping-pong comme pratique de programmation en binôme en IaC.

3. Strong Style. Pratique complexe.. L'idée est qu'un participant devient le navigateur directif, tandis que l'autre prend le rôle de pilote exécutant. Dans ce cas, le droit de décision appartient uniquement au navigateur. Le pilote ne fait que taper et peut influencer le déroulement par ses mots. Les rôles ne changent pas pendant longtemps.

Bien adapté pour l'apprentissage, mais nécessite de fortes compétences interpersonnelles. C'est à ce niveau que nous avons rencontré des difficultés. La technique était difficile à mettre en œuvre. Et il ne s'agit même pas d'infrastructure.

Conclusion : potentiellement applicable, nous ne renonçons pas à nos tentatives.

4. Mobbing, swarming et tous les styles connus, mais non mentionnés ici ne sont pas considérés, car nous ne les avons pas essayés et il n'est pas possible d'en parler dans le contexte de notre travail.

Bilan général sur l'utilisation de la programmation en binôme :

• Nous avons un rythme de travail irrégulier qui perturbe.
• Nous avons rencontré des compétences interpersonnelles insuffisamment bonnes. Et le domaine d'application ne facilite pas la surmonter de ces défauts.
• Les tests longs et les problèmes d'outils rendent le développement en binôme laborieux.

5. Cependant, il y a eu des succès. Nous avons inventé notre propre méthode « Convergence - Divergence ». Je vais décrire brièvement comment cela fonctionne.

Nous avons des partenaires réguliers pour quelques jours (moins d'une semaine). Nous traitons une tâche ensemble. Pendant un certain temps, nous sommes ensemble : l'un écrit, l'autre observe, comme une équipe de support. Ensuite, nous nous séparons un moment, chacun s'occupe de choses indépendantes, puis nous nous réunissons à nouveau, nous nous synchronisons très rapidement, nous faisons quelque chose ensemble et nous nous séparons à nouveau.

Planification et communication

Le dernier bloc de pratiques par lequel nous résolvons les problèmes de l'OS est l'organisation du travail autour des tâches elles-mêmes. Cela inclut également l'échange d'expérience qui se déroule en dehors du travail en binôme. Examinons trois pratiques :

1. Tâches par arbre d'objectifs. Nous avons organisé la gestion du projet via un arbre qui s'étend indéfiniment dans le futur. Techniquement, la gestion se fait dans Miro. Il y a une tâche - c'est un objectif intermédiaire. De celle-ci, il y a soit des objectifs plus petits, soit des groupes de tâches. À partir de là, les tâches elles-mêmes sont dérivées. Toutes les tâches sont créées et gérées sur ce tableau.

Ce schéma offre également un retour d'information qui se produit une fois par jour, lorsque nous nous synchronisons lors de réunions. Avoir un plan commun, structuré et entièrement transparent, permet à chacun d'être au courant de ce qui se passe et des progrès réalisés.

Avantages de la visualisation des tâches :

• Causalité. Chaque tâche conduit à un objectif global. Les tâches sont regroupées par objectifs plus spécifiques. Le domaine de l'infrastructure est en lui-même assez technique. Il n'est pas toujours évident de voir quel impact spécifique a, par exemple, la rédaction d'un guide de migration vers un autre nginx. Avoir une carte d'objectif à côté rend cela plus clair.
  
  La causalité est une propriété importante des tâches. Elle répond directement à la question : « Est-ce que je fais bien cela ? »
• Parallélisme. Nous sommes neuf personnes, et il est physiquement impossible de se concentrer tous sur une seule tâche. Il se peut aussi que les tâches d'un même domaine ne suffisent pas à elles seules. Nous sommes contraints de paralléliser le travail entre de petits groupes de travail. Pendant un certain temps, ces groupes se consacrent à leur tâche, et ils peuvent être renforcés par d'autres personnes. Des membres de ce groupe de travail peuvent parfois s'absenter. Certains prennent des congés, d'autres préparent une présentation pour la conférence DevOps conf, ou encore écrivent un article pour Habr. Il est très important de savoir quelles objectifs et tâches peuvent être réalisés en parallèle.

2. Rotations des animateurs des réunions du matin. Lors des stand-ups, un problème s'est posé : beaucoup de tâches sont réalisées en parallèle. Parfois, les tâches sont faiblement liées et il n'y a pas de compréhension claire de ce que chacun fait. L'avis d'un autre membre de l'équipe est très important. C'est une information supplémentaire capable de modifier le cours de la résolution d'une tâche. Bien sûr, il y a généralement quelqu'un d'autre avec toi, mais les conseils et les suggestions ne sont jamais superflus.

Pour améliorer cette situation, nous avons appliqué la technique du « Changement d'animateur du stand-up ». Maintenant, ils sont tirés au sort selon une liste précise, et cela a un effet positif. Lorsque ton tour arrive, tu es obligé de te plonger et de comprendre ce qui se passe, afin de bien mener la réunion de scrum.

3. Démonstration interne. L'aide à la résolution des tâches par la programmation en binôme, la visualisation sur l'arbre des tâches et l'aide lors des scrum-mitings du matin – c'est bien, mais pas parfait. En binôme, vous êtes limités par vos propres connaissances. L'arbre des tâches aide à comprendre globalement qui fait quoi. Mais l'animateur et les collègues lors de la réunion du matin ne vont pas plonger en profondeur dans vos problèmes. Ils peuvent certainement passer quelque chose.

La solution trouvée a été de démontrer le travail réalisé à l'autre et de discuter ensuite. Nous nous réunissons une fois par semaine pendant une heure et montrons les détails des solutions aux tâches que nous avons réalisées durant la semaine écoulée.

Lors de la démonstration, il faut dévoiler les détails de la tâche et montrer impérativement son fonctionnement.

Le rapport peut être fait selon une liste de contrôle.1. Mettez en contexte. D'où provient la tâche, pourquoi était-elle nécessaire ?

2. Comment la tâche était-elle résolue auparavant ? Par exemple, il fallait cliquer massivement avec la souris, ou bien il n'était pas possible de faire quoi que ce soit.

3. Comment nous améliorons cela. Par exemple : « Regardez, maintenant, il y a un petit script, voici le readme ».

4. Montrez comment cela fonctionne. Idéalement, réalisez un scénario utilisateur concret. Je veux X, je fais Y, je vois Z (ou quelque chose d'équivalent). Par exemple, je déploie NGINX, je consulte l'URL, et je reçois un 200 OK. Si l'action prend du temps, préparez-la à l'avance pour pouvoir la montrer. Idéalement, ne cassez pas nécessairement le système dans l'heure qui précède la démonstration, surtout si c'est fragile.

5. Expliquez à quel point le problème a été bien résolu, quelles difficultés restent, ce qui n'est pas terminé, et quelles améliorations sont possibles à l'avenir. Par exemple, maintenant nous avons des CLI, ensuite il y aura une automatisation complète dans le CI.

Il est souhaitable que chaque intervenant se limite à 5-10 minutes. Si votre présentation est particulièrement importante et prendra plus de temps, assurez-vous de l'avoir convenu à l'avance dans le canal sre-takeover.

Après la partie en direct, il y a forcément un débat dans le thread. C'est là que nous obtenons le retour d'information nécessaire concernant nos tâches.

En fin de compte, un sondage est effectué pour évaluer l'utilité de ce qui s'est passé. C'est déjà un retour d'information sur la pertinence de la présentation et l'importance de la tâche.

Conclusions longues et prochaines étapes

Il peut sembler que le ton de l'article soit quelque peu pessimiste. Ce n'est pas le cas. Les deux niveaux de base pour obtenir des retours d'information, à savoir les tests et la programmation en binôme, fonctionnent. Pas aussi parfaitement que dans le développement traditionnel, mais il y a un effet positif.

Les tests, dans leur forme actuelle, n'offrent qu'une couverture partielle du code. De nombreuses fonctions de configuration ne sont pas testées. Leur impact direct lors de l'écriture du code est faible. Cependant, il y a un effet des tests d'intégration, et c'est précisément ce qui permet d'effectuer des refactorings en toute confiance. C'est un grand accomplissement. De plus, avec le recentrage sur le développement dans des langages de haut niveau (nous utilisons Python, Go), le problème disparaît. Pas besoin de nombreuses vérifications pour le "colle", une intégration générale suffit.

Le travail en binôme dépend davantage des personnes. Il y a le facteur tâche et nos compétences interpersonnelles. Avec certains, cela se passe très bien, avec d'autres moins bien. Il est clair qu'il y a certainement un bénéfice. Même si les règles du travail en binôme ne sont pas toujours respectées, le simple fait d'accomplir des tâches ensemble a un impact positif sur la qualité du résultat. Personnellement, je trouve plus facile et agréable de travailler en couple.

Des méthodes plus avancées d'influence sur le système d'exploitation – la planification et le travail sur les tâches – produisent clairement des effets : un échange de connaissances de qualité et une amélioration de la qualité du développement.

Résumé court en une ligne

• Les pratiques XP fonctionnent dans l'IaC, mais avec une efficacité moindre.
• Renforcez ce qui fonctionne.
• Invente tes propres mécanismes compensatoires et pratiques.

Source : habr.com