Est-il nécessaire d'interdire le déploiement en production à certains moments? Ou le mouvement #NoDeployFriday est devenu une relique de l'époque où il n'y avait pas de tests d'intégration complets et de déploiement continu?

Dans votre équipe, vous pourriez être confronté au même dilemme. Qui a raison et qui est à blâmer? L'abandon du déploiement le vendredi est-il une stratégie raisonnable pour réduire les risques, ou est-ce une mauvaise culture qui nous empêche de créer des systèmes meilleurs et plus stables?

Ding ding

Je suis sûr que les ingénieurs qui ont eu la chance d’être «en contact» ont perdu leurs jours de congé à cause de tous les changements du vendredi qui ont éclaté. J'étais aussi dans cette situation. Un coup de téléphone lorsque vous sortez en famille ou au milieu de la nuit, vous informant du plantage de l'application. Après avoir accédé à l'ordinateur et vérifié les journaux à croissance rapide, il devient évident que tout a été ruiné par une rare exception non gérée. Dégoûtant.

L'analyse révèle que pour le scénario qui a conduit à l'échec, aucun test n'a été écrit, apparemment parce qu'il n'était pas considéré comme probable. Après une longue série d'appels téléphoniques avec d'autres ingénieurs à la recherche d'un meilleur moyen d'annuler les modifications et de tout corriger, le système recommence à fonctionner. Fuh.

Une réunion pour cinq raisons a lieu lundi.

" Arrêtons simplement le déploiement le vendredi. Ensuite, le week-end, tout fonctionnera de manière stable, et la semaine prochaine, nous serons en alerte après toutes sortes de sorties ."

Tout le monde acquiesce. Si quelque chose ne fonctionne pas avant midi jeudi, il attend le lundi matin. Cette approche nuit-elle ou aide-t-elle?


Comme vous le savez, les déclarations Twitter sont souvent très subjectives. Bien que l'interdiction des versions du vendredi semble raisonnable, quelqu'un indiquera rapidement qu'il ne s'agit que d'une béquille en raison de la fragilité de la plate-forme, qui est due à de mauvais processus de test et de déploiement.

Certains suggèrent même que vous aimez plus les déploiements silencieux que le week-end lui-même:


D'autres utilisateurs pensent que l'implémentation de drapeaux de fonction peut être une solution possible.


Cet utilisateur estime que les problèmes d'un déploiement risqué ne devraient pas survenir en raison des processus et des outils dont nous disposons aujourd'hui.

Qui prend les décisions?

Tous ces échanges d'opinions indiquent que nous, en tant que communauté d'ingénieurs, pouvons être fortement en désaccord et ne sommes pas nécessairement d'accord les uns avec les autres. Qui aurait pensé. Cette situation démontre probablement aussi que l'image globale avec #NoDeployFriday contient de telles nuances qui ne sont pas trop bien reflétées sur Twitter. Est-il vrai que nous devons tous appliquer un déploiement continu, sinon nous «faisons mal»?

Prendre une telle décision comporte un aspect psychologique. L'hostilité aux libérations du vendredi provient de la peur de faire des erreurs au cours de la semaine (en raison de la fatigue ou de la précipitation), ce qui peut nuire à la plupart des employés pendant deux jours de repos. En conséquence, un commit du vendredi contenant un problème potentiel peut gâcher le week-end pour un tas de personnes: des ingénieurs de service, d'autres ingénieurs qui aideront à distance à résoudre le problème, et éventuellement des spécialistes de l'infrastructure qui doivent récupérer des données endommagées. Si l'échec s'avère sérieux, d'autres employés de l'entreprise peuvent également être impliqués dans la situation, qui devront contacter les clients et minimiser les dommages.

En prenant la position d'un idéaliste, nous pouvons supposer que dans un monde idéal avec un code parfait, une couverture de test parfaite et une assurance qualité parfaite, aucun changement ne peut entraîner de problème. Mais nous sommes des gens et les gens ont tendance à faire des erreurs. Il y aura toujours d'étranges cas de frontière qui ne seront pas fermés pendant le développement. C'est la vie. Le mouvement #NoDeployFriday est donc logique, du moins en théorie. Cependant, ce n'est qu'un outil aveugle. Je pense qu'il est nécessaire d'évaluer les changements opérés en fonction de la situation, et a priori il faut partir du fait que nous déployons tous les jours, même le vendredi, mais en même temps il faut pouvoir isoler ces changements qui doivent attendre jusqu'à lundi.

Nous pouvons discuter de certaines questions. Je les ai divisés en catégories:

1. Comprendre le «rayon de destruction» du changement.
   
2. La solidité du processus de déploiement.
   
3. La capacité de détecter automatiquement les erreurs.
   
4. Combien de temps faut-il pour résoudre les problèmes.
   

Voyons maintenant.

Comprendre le "rayon de destruction"

Lorsque les lances en ligne sur les versions du vendredi recommencent à se rompre, elles oublient toujours l'important - la nature même des changements. Il n'y a pas de changements identiques dans la base de code. Certains commits gouvernent un peu l'interface et rien de plus; d'autres refactorisent des centaines de classes sans affecter la fonctionnalité du programme; d'autres encore modifient les schémas de base de données et apportent des changements majeurs au processus de consommation de données en temps réel; les quatrièmes peuvent redémarrer une instance, tandis que les cinquièmes peuvent lancer un redémarrage en cascade de toutes sortes de services.

En regardant le code, les ingénieurs devraient avoir une bonne idée du «rayon de destruction» des modifications apportées. Quelle partie du code et de l'application sera affectée? Que pourrait tomber si le nouveau code plante? Est-ce juste un clic sur un bouton qui générera une erreur ou toutes les nouvelles entrées seront-elles perdues? Une modification est-elle apportée à un seul service isolé ou de nombreux services et dépendances changeront-ils simultanément?

Je ne peux pas imaginer qui refusera de faire des changements avec un petit "rayon de destruction" et un simple déploiement n'importe quel jour de la semaine. Mais en même temps, des changements majeurs - en particulier ceux liés à l'infrastructure de stockage - doivent être effectués avec plus de soin, peut-être à un moment où il y a moins d'utilisateurs en ligne. Ce sera encore mieux si de tels changements à grande échelle sont mis en œuvre en parallèle pour tester et évaluer leur travail sous charge réelle, et personne ne le saura même.

Ici, vous devez prendre des décisions en fonction de la situation. Chaque ingénieur est-il conscient du «rayon de destruction» des changements dans l'environnement de production, et pas seulement dans l'environnement de développement? Sinon, pourquoi? Est-il possible d'améliorer la documentation, la formation et l'affichage des effets des changements de code en production?

Le "rayon de destruction" est-il petit? Lancement vendredi.

Le "rayon de destruction" est-il grand? Attendez jusqu'à lundi.

La solidité du processus de déploiement

Une façon de réduire les risques consiste à améliorer continuellement le processus de déploiement. Si, pour lancer une nouvelle version de l'application, il est toujours nécessaire qu'un spécialiste sache quel script exécuter, quel fichier et où copier, il est temps de passer à l'automatisation. Ces dernières années, les outils dans ce domaine sont allés très loin. Nous utilisons souvent Jenkins Pipeline et Concourse , ils vous permettent de définir directement les pipelines d'assemblage, de test et de déploiement avec du code.

Le processus de déploiement de déploiement complet est une chose intéressante. Il vous permet de prendre du recul et d'essayer d'abstraire ce qui devrait se passer entre le moment où la demande d'extraction est initialisée et la mise en service de l'application. Une description de toutes les étapes du code, par exemple dans les outils mentionnés ci-dessus, vous aidera à généraliser les définitions des étapes et à les réutiliser dans toutes les applications. De plus, il sera intéressant pour vous de noter certaines décisions étranges ou paresseuses que vous avez prises et réconciliées.

À chaque ingénieur qui a lu les deux paragraphes précédents et a réagi dans le style de «Bien sûr! Nous faisons cela depuis des années! » Je peux garantir que 9 autres personnes ont présenté leur infrastructure d'application et ont grimacé, réalisant la quantité de travail qui doit être fait pour transférer le système vers un pipeline de déploiement moderne. Cela implique de tirer parti des outils modernes qui non seulement effectuent une intégration continue, mais vous permettent également de fournir en continu des bogues au producteur, et les ingénieurs n'ont qu'à appuyer sur le bouton pour la mise en service (ou même le faire automatiquement si vous êtes assez courageux).

L'amélioration du convoyeur de déploiement nécessite une implication et un personnel approprié - ce n'est certainement pas un projet parallèle. Une bonne solution serait de mettre en valeur une équipe pour améliorer les outils internes. S'ils ne connaissent toujours pas les problèmes existants - et ils le savent probablement - alors vous pouvez collecter des informations sur les situations les plus douloureuses associées au processus de publication, puis les hiérarchiser et les résoudre avec d'autres. Lentement, mais sûrement, la situation s'améliorera: le code sera mis en service plus rapidement et avec moins de problèmes. De plus en plus de personnes pourront apprendre de meilleures approches et apporter des améliorations par elles-mêmes. Au fur et à mesure que la situation s'améliore, les approches seront réparties en équipes, et ce nouveau projet se terminera correctement, sans la copie habituelle des vieilles mauvaises habitudes.

À partir du moment de la fusion, la demande de pull vers le commit doit être automatisée afin que vous n'ayez même pas besoin d'y penser. Cela permet non seulement d'isoler les vrais problèmes de QA, car la seule variable est le code modifié, mais cela rend l'écriture du code beaucoup plus agréable. La mise en service est décentralisée, ce qui augmente l'autonomie et la responsabilité personnelles. Et cela, à son tour, conduit à des décisions plus délibérées concernant le moment et la manière de déployer le nouveau code.

Convoyeur de déploiement fiable? Déployez-vous vendredi.

Copier manuellement des scripts? Attendez jusqu'à lundi.

Capacité à détecter les erreurs

La mise en service ne s'arrête pas une fois que le code a commencé à fonctionner. Si quelque chose se passe mal, nous devons en être informés et il est conseillé que nous en soyons informés et que nous ne soyons pas obligés de rechercher des informations par nous-mêmes. Pour ce faire, vous devez rechercher automatiquement les erreurs dans les journaux d'application, suivre explicitement les mesures clés (par exemple, le nombre de messages traités par seconde ou la proportion d'erreurs), ainsi qu'un système d'avertissement qui informe les ingénieurs des problèmes critiques et montre une tendance négative pour certaines mesures.

Le fonctionnement est toujours différent du développement et les ingénieurs doivent surveiller le fonctionnement de certaines parties du système. Vous devez répondre à des questions sur chaque changement ultérieur: cela a-t-il accéléré ou ralenti le système? Il y a plus ou moins de timeouts? Sommes-nous limités par le processeur ou les E / S?

Les données sur les mesures et les erreurs doivent être transmises au système d'alerte. Les équipes devraient pouvoir déterminer quels signaux indiquent une situation négative et envoyer des messages automatiques à ce sujet. Pour nos équipes et les incidents les plus graves, nous utilisons PagerDuty.

La mesure des métriques du système de production signifie que les ingénieurs peuvent voir si quelque chose a changé après chaque déploiement, pour le meilleur ou pour le pire. Et dans le pire des cas, le système informera automatiquement quelqu'un du problème.

Bonne surveillance, notifications et spécialistes sur appel? Déployer vendredi.

Afficher manuellement les journaux via ssh? Attendez jusqu'à lundi.

Combien de temps faut-il pour résoudre les problèmes?

Enfin, le critère principal est le temps qu'il faudra pour résoudre les problèmes. Cela dépend en partie du «rayon de dégâts» des modifications apportées. Même si vous avez un pipeline de déploiement léché, certaines modifications sont difficiles à corriger rapidement. L'annulation des modifications dans le système d'extraction de données et dans le schéma d'index de recherche peut nécessiter une réindexation laborieuse, en plus de corriger une ligne de code. Le déploiement, la validation, la correction et le redéploiement moyens des modifications CSS peuvent prendre quelques minutes, tandis que les modifications majeures du référentiel peuvent nécessiter des jours de travail.

Pour tous les travaux au sein du pipeline de déploiement, qui au niveau macro peuvent augmenter la fiabilité des modifications, aucune modification n'est identique, vous devez donc les évaluer séparément. En cas de problème, pouvons-nous le réparer rapidement?

Est-il entièrement résolu avec un seul commit de restauration? Déployer vendredi.

Y a-t-il de grandes difficultés en cas de problème? Attendez jusqu'à lundi.

Pensez par vous-même, décidez par vous-même

Quelle est ma position sur #NoDeployFriday? Je pense que tout dépend de la sortie. Les modifications avec un petit «rayon de frappe» faciles à annuler peuvent être déployées à tout moment et en tout temps. Avec des changements importants, dont l'impact doit être étroitement surveillé dans le système de production, je recommande fortement d'attendre jusqu'à lundi.

En fait, c'est à vous de déployer le vendredi. Si vous travaillez avec un système grinçant et fragile, il est préférable d'éviter les vendredis jusqu'à ce que vous ayez fait tout ce qui est nécessaire pour améliorer le processus de déploiement. Assurez-vous simplement de le faire, ne le brossez pas. Refuser les versions du vendredi est un moyen normal de couvrir les failles temporaires de l'infrastructure. Il s'agit d'une réduction raisonnable des dommages pour le bien de l'entreprise. Mais c'est mauvais si cette règle couvre des défauts constants.

Si vous n'êtes pas sûr de l'effet que les modifications auront, reportez-le au lundi. Mais réfléchissez à ce que vous pouvez faire la prochaine fois pour mieux comprendre cet effet et améliorer l'infrastructure associée pour cela. Comme toujours dans la vie, chaque décision a ses propres nuances. Les solutions ne sont pas divisées en «noir» et «blanc», en «bien» et «mal»: alors que nous faisons tout ce que nous pouvons pour les entreprises, les applications et les autres, en améliorant nos systèmes, nous faisons tout bien.

Déploiement réussi.