🆔 🍅 ✌🏻 Méthodologie de déploiement de projet utilisée par Slack ⏏️ 🌙 📥

La conclusion d'une nouvelle version de projet en production nécessite un équilibre minutieux entre la vitesse de déploiement et la fiabilité de la solution. Slack apprécie les itérations rapides, les boucles de rétroaction courtes et la réactivité aux demandes des utilisateurs. De plus, l'entreprise compte des centaines de programmeurs qui visent la productivité la plus élevée possible.

Les auteurs du matériel, dont nous publions la traduction aujourd'hui, disent qu'une entreprise qui cherche à adhérer à ces valeurs et en même temps à grandir devrait constamment améliorer son système de déploiement de projets. L'entreprise doit investir dans la transparence et la fiabilité des processus de travail, afin de s'assurer que ces processus correspondent à la portée du projet. Ici, nous parlerons des processus de travail qui se sont développés dans Slack, et de certaines des solutions qui ont conduit l'entreprise à utiliser le système de déploiement de projet qui existe aujourd'hui.

Fonctionnement des processus de déploiement de projets aujourd'hui

Chaque PR (pull request) dans Slack doit être soumis à une révision de code et doit réussir tous les tests. Ce n'est qu'une fois ces conditions remplies qu'un programmeur peut fusionner son code avec la branche principale du projet. Cependant, le déploiement d'un tel code n'est effectué que pendant les heures ouvrables selon l'heure nord-américaine. En conséquence, nous, étant donné que nos employés sont au travail, nous sommes pleinement préparés à résoudre tout problème inattendu.

Chaque jour, nous effectuons environ 12 déploiements planifiés. Lors de chaque déploiement, le programmeur, qui est affecté en tant que déploiement principal, est responsable de la mise en production du nouvel assemblage. Il s'agit d'un processus en plusieurs étapes, qui fournit une conclusion en douceur de l'assemblage en mode de travail. Grâce à cette approche, nous pouvons détecter les erreurs avant qu'elles n'affectent tous nos utilisateurs. S'il y a trop d'erreurs, le déploiement de l'assemblage peut être annulé. Si un problème particulier est détecté après la publication, un correctif peut être facilement publié pour celui-ci.

L'interface du système Checkpoint utilisé par Slack pour déployer des projets

Le processus de déploiement d'une nouvelle version en production peut être représenté en quatre étapes.

▍1. Création d'une branche de publication

Chaque version commence par une nouvelle branche de version, à partir du moment de notre histoire Git. Cela vous permet d'attribuer des balises à la version et fournit un endroit où vous pouvez apporter des corrections opérationnelles aux erreurs détectées lors du processus de préparation de la version pour la version en production.

▍2. Déploiement intermédiaire

L'étape suivante consiste à déployer l'assembly sur des serveurs intermédiaires et à exécuter un test automatique pour les performances globales du projet (test de fumée). Un environnement intermédiaire est un environnement de production dans lequel le trafic externe ne tombe pas. Dans cet environnement, nous effectuons des tests manuels supplémentaires. Cela nous donne une confiance supplémentaire que le projet modifié fonctionne correctement. Les tests automatisés seuls ne suffisent pas à gagner une telle confiance.

▍3. Déploiement en environnement dogfood et canari

Le déploiement en production commence par un environnement dogfood représenté par un ensemble d'hôtes qui desservent nos espaces de travail internes Slack. Étant donné que nous sommes des utilisateurs très actifs de Slack, l'utilisation de cette approche a permis de détecter de nombreuses erreurs dans les premières étapes du déploiement. Après nous être assurés que la fonctionnalité de base du système n'est pas cassée, l'assemblage est déployé dans un environnement canari. Il s'agit d'un système qui reçoit environ 2% du trafic de production.

▍4. Conclusion progressive en production

Si les indicateurs de suivi de la nouvelle version s'avèrent stables, et si après déploiement du projet dans l'environnement canarien nous n'avons pas reçu de réclamations, nous poursuivons le transfert progressif des serveurs de production vers la nouvelle version. Le processus de déploiement est divisé en plusieurs étapes: 10%, 25%, 50%, 75% et 100%. Par conséquent, nous pouvons lentement transférer le trafic de production vers une nouvelle version du système. Dans le même temps, nous avons le temps d'enquêter sur la situation en cas de révélation de quelques anomalies.

HatQue se passe-t-il si quelque chose s'est mal passé pendant le déploiement?

Apporter des modifications au code est toujours un risque. Mais nous pouvons y faire face grâce à nos «gestionnaires de déploiement» bien formés qui gèrent le processus d'introduction d'une nouvelle version en production, surveillent les performances de surveillance et coordonnent le travail des programmeurs qui publient le code.

En cas de problème, nous essayons de détecter le problème le plus tôt possible. Nous enquêtons sur le problème, trouvons le PR à l'origine des erreurs, le restaurons, l'analysons soigneusement et créons un nouvel assemblage. Certes, le problème passe parfois inaperçu avant la mise en production du projet. Dans une telle situation, le plus important est de restaurer le service. Par conséquent, avant de commencer l'enquête sur le problème, nous revenons immédiatement à l'assemblage de travail précédent.

Blocs de construction du déploiement

Considérez les technologies sous-jacentes à notre système de déploiement de projet.

▍ Déploiements rapides

Le flux de travail décrit ci-dessus peut sembler rétrospectivement être quelque chose de complètement évident. Mais notre système de déploiement n'est pas devenu si loin tout de suite.

Lorsque l'entreprise était beaucoup plus petite, notre application entière pouvait fonctionner sur 10 instances Amazon EC2. Déployer un projet dans cette situation signifiait utiliser rsync pour synchroniser rapidement tous les serveurs. Auparavant, le nouveau code était séparé de la production par une seule étape, représentée par un environnement intermédiaire. Les assemblages ont été créés et testés dans un tel environnement, puis ont été directement mis en production. La compréhension d'un tel système était très simple; elle permettait à tout programmeur de déployer le code qu'il écrivait à tout moment.

Mais à mesure que le nombre de nos clients augmentait, l'échelle de l'infrastructure nécessaire pour assurer le fonctionnement du projet augmentait. Bientôt, compte tenu de la croissance constante du système, notre modèle de déploiement, basé sur l'envoi de nouveau code aux serveurs, a cessé de faire face à sa tâche. A savoir, l'ajout de chaque nouveau serveur signifiait une augmentation du temps requis pour terminer le déploiement. Même les stratégies basées sur l'utilisation parallèle de rsync ont certaines limites.

En conséquence, nous avons résolu ce problème en passant à un système de déploiement entièrement parallèle, qui n'est pas agencé comme l'ancien système. À savoir, maintenant, nous n'avons pas envoyé le code aux serveurs à l'aide du script de synchronisation. Désormais, chaque serveur a téléchargé indépendamment un nouvel assemblage, apprenant que cela devait être fait, grâce à l'observation du changement de clé du consul. Les serveurs ont téléchargé le code en parallèle. Cela nous a permis de maintenir une vitesse de déploiement élevée même dans un environnement de croissance constante du système.

1. Les serveurs de production surveillent la clé Consul. 2. La clé change, cela indique aux serveurs qu'ils doivent commencer à télécharger le nouveau code. 3. Les serveurs téléchargent des fichiers tarball avec le code d'application

▍ Déploiements atomiques

Une autre solution qui nous a aidés à arriver à un système de déploiement à plusieurs niveaux était le déploiement atomique.

Avant d'utiliser des déploiements atomiques, chaque déploiement peut entraîner un grand nombre de messages d'erreur. Le fait est que le processus de copie de nouveaux fichiers sur des serveurs de production n'était pas atomique. Cela a conduit à l'existence d'un court laps de temps lorsque le code dans lequel les nouvelles fonctions ont été appelées était disponible avant que les fonctions elles-mêmes ne soient disponibles. Lorsqu'un tel code était appelé, il renvoyait des erreurs internes. Cela s'est manifesté par des demandes d'API infructueuses et des pages Web cassées.

L'équipe qui a traité ce problème l'a résolu en introduisant le concept de répertoires «chaud» (chaud) et «froid» (froid). Le code du répertoire "hot" est responsable du traitement du trafic de production. Et dans les répertoires «froids», le code, alors que le système est en cours d'exécution, ne se prépare qu'à être utilisé. Pendant le déploiement, le nouveau code est copié dans le répertoire «froid» inutilisé. Ensuite, lorsqu'il n'y a aucun processus actif sur le serveur, les répertoires sont commutés instantanément.

1. Déballage du code d'application dans un répertoire «froid». 2. Passage du système à un répertoire «froid», qui devient «chaud» (fonctionnement atomique)

Conclusion: un changement dans l'accent mis sur la fiabilité

En 2018, le projet a pris une telle ampleur qu'un déploiement très rapide a commencé à nuire à la stabilité du produit. Nous avions un système de déploiement très avancé dans lequel nous avons investi beaucoup de temps et d'efforts. Nous n'avions besoin que de restructurer et d'améliorer les processus d'organisation du déploiement. Nous sommes devenus une entreprise assez importante, dont le développement a été utilisé dans le monde entier pour organiser une communication ininterrompue et résoudre des problèmes importants. Par conséquent, notre attention était centrée sur la fiabilité.

Nous devions sécuriser le processus de déploiement des nouvelles versions de Slack. Ce besoin nous a amenés à améliorer notre système de déploiement. En fait, nous avons discuté ci-dessus de ce système amélioré. Dans les entrailles du système, nous continuons à utiliser des technologies de déploiement rapide et atomique. Modification de la façon dont le déploiement est effectué. Notre nouveau système est conçu pour déployer progressivement du nouveau code à différents niveaux, dans différents environnements. Maintenant, nous utilisons des outils auxiliaires et des outils plus avancés qu'auparavant pour surveiller le système. Cela nous donne la possibilité de détecter et d'éliminer les erreurs bien avant qu'elles n'atteignent l'utilisateur final.

Mais nous ne nous arrêterons pas là. Nous améliorons constamment ce système en utilisant des outils auxiliaires et des outils d'automatisation plus avancés.

Chers lecteurs! Comment se déroule le déploiement de nouvelles versions de projet là où vous travaillez?

Méthodologie de déploiement de projet utilisée par Slack