La mise en production d’une nouvelle version de projet nécessite un équilibre judicieux entre vitesse de déploiement et fiabilité de la solution. Slack valorise les itérations rapides, les cycles de retour courts et la réponse rapide aux demandes des utilisateurs. De plus, l'entreprise compte des centaines de programmeurs qui s'efforcent d'être aussi productifs que possible.
Les auteurs du document, dont nous publions aujourd'hui la traduction, affirment qu'une entreprise qui s'efforce d'adhérer à de telles valeurs et qui en même temps se développe doit 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 garantir que ces processus correspondent à l'ampleur du projet. Nous parlerons ici des flux de travail développés dans Slack et de certaines des décisions qui ont conduit l'entreprise à utiliser le système de déploiement de projets qui existe aujourd'hui.
Comment fonctionnent les processus de déploiement de projets aujourd'hui
Chaque PR (pull request) dans Slack doit être soumis à une révision du code et doit réussir tous les tests. Ce n'est qu'une fois ces conditions remplies que le programmeur peut fusionner son code dans la branche master du projet. Cependant, ce code est déployé uniquement pendant les heures ouvrables, heure nord-américaine. Ainsi, étant donné que nos employés sont sur leur lieu de 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 désigné comme responsable du déploiement est responsable de la mise en production de la nouvelle version. Il s’agit d’un processus en plusieurs étapes qui garantit que l’assemblage entre en production sans problème. 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'assembly peut être annulé. Si un problème spécifique est découvert après la publication, un correctif peut facilement être publié.
Interface du système Checkpoint, utilisé dans Slack pour déployer des projets
Le processus de déploiement d’une nouvelle version en production peut être considéré comme composé de quatre étapes.
▍1. Créer une branche de publication
Chaque version commence par une nouvelle branche de version, un point dans notre historique Git. Cela vous permet d'attribuer des balises à la version et fournit un endroit où vous pouvez apporter des correctifs en direct aux bogues trouvés lors du processus de préparation de la version pour la mise en production.
▍2. Déploiement dans un environnement 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 (smoke test). L'environnement intermédiaire est un environnement de production qui ne reçoit pas de trafic externe. Dans cet environnement, nous effectuons des tests manuels supplémentaires. Cela nous donne une confiance supplémentaire dans le bon fonctionnement du projet modifié. Les tests automatisés ne suffisent pas à eux seuls à fournir ce niveau de confiance.
▍3. Déploiement dans les environnements dogfood et canari
Le déploiement en production commence par un environnement dogfood, représenté par un ensemble d'hôtes qui servent nos espaces de travail Slack internes. Étant donné que nous sommes des utilisateurs très actifs de Slack, cette approche nous a aidé à détecter de nombreux bugs au début du déploiement. Après nous être assurés que les fonctionnalités de base du système ne sont pas interrompues, l'assembly est déployé dans l'environnement Canary. Il s'agit de systèmes qui représentent environ 2 % du trafic de production.
▍4. Mise en production progressive
Si les indicateurs de suivi de la nouvelle version s'avèrent stables, et si après déploiement du projet dans l'environnement Canary nous n'avons reçu aucune réclamation, nous continuons à transférer progressivement les serveurs de production vers la nouvelle version. Le processus de déploiement est divisé selon les étapes suivantes : 10 %, 25 %, 50 %, 75 % et 100 %. En conséquence, nous pouvons transférer lentement le trafic de production vers la nouvelle version du système. En même temps, nous avons le temps d'enquêter sur la situation si des anomalies sont détectées.
▍Que se passe-t-il si quelque chose ne va pas pendant le déploiement ?
Apporter des modifications au code est toujours un risque. Mais nous y faisons face grâce à la présence de « chefs de déploiement » bien formés qui gèrent le processus de mise en production d'une nouvelle version, surveillent les indicateurs de suivi et coordonnent le travail des programmeurs publiant le code.
En cas de problème, nous essayons de détecter le problème le plus tôt possible. Nous étudions le problème, trouvons le PR à l'origine des erreurs, l'annulons, l'analysons en profondeur et créons une nouvelle version. Certes, le problème passe parfois inaperçu jusqu'à ce que le projet entre en production. Dans une telle situation, le plus important est de rétablir le service. Par conséquent, avant de commencer à enquêter sur le problème, nous revenons immédiatement à la version de travail précédente.
Éléments constitutifs d'un système de déploiement
Examinons les technologies qui sous-tendent notre système de déploiement de projets.
▍Déploiements rapides
Le flux de travail décrit ci-dessus peut sembler, rétrospectivement, quelque peu évident. Mais notre système de déploiement n’est pas devenu tel d’emblée.
Lorsque l'entreprise était beaucoup plus petite, l'ensemble de notre application pouvait fonctionner sur 10 instances Amazon EC2. Déployer le projet dans cette situation impliquait d'utiliser rsync pour synchroniser rapidement tous les serveurs. Auparavant, le nouveau code n'était qu'à une étape de la production, représentée par un environnement de test. Les assemblages ont été créés et testés dans un tel environnement, puis sont passés directement en production. Il était très simple de comprendre un tel système ; il permettait à n'importe quel programmeur de déployer à tout moment le code qu'il avait écrit.
Mais à mesure que le nombre de nos clients augmentait, l’ampleur de l’infrastructure requise pour soutenir le projet augmentait également. Très vite, compte tenu de la croissance constante du système, notre modèle de déploiement, basé sur le push de nouveau code vers les serveurs, ne faisait plus son travail. À savoir, ajouter chaque nouveau serveur signifiait augmenter le temps nécessaire pour terminer le déploiement. Même les stratégies basées sur l'utilisation parallèle de rsync présentent certaines limites.
Nous avons fini par résoudre ce problème en passant à un système de déploiement complètement parallèle, conçu différemment de l'ancien système. À savoir, nous n’envoyons plus de code aux serveurs à l’aide d’un script de synchronisation. Désormais, chaque serveur téléchargeait indépendamment le nouvel assembly, sachant qu'il devait le faire en surveillant le changement de clé Consul. Les serveurs chargeaient 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 du nouveau code. 3. Les serveurs téléchargent les fichiers tarball avec le code de l'application
▍Déploiements atomiques
Une autre solution qui nous a aidé à atteindre un système de déploiement à plusieurs niveaux était le déploiement atomique.
Avant d'utiliser les déploiements atomiques, chaque déploiement pouvait 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 entraîné une courte période de temps pendant laquelle le code qui appelait de nouvelles fonctions était disponible avant que les fonctions elles-mêmes ne soient disponibles. Lorsqu’un tel code était appelé, des erreurs internes étaient renvoyées. Cela s'est manifesté par des requêtes API échouées et des pages Web cassées.
L'équipe qui a travaillé sur ce problème l'a résolu en introduisant le concept de répertoires « chauds » et « froids ». Le code du répertoire chaud est responsable du traitement du trafic de production. Et dans les répertoires « froids », le code, pendant que le système est en cours d'exécution, est uniquement préparé pour être utilisé. Lors du déploiement, le nouveau code est copié dans un répertoire froid inutilisé. Ensuite, lorsqu'il n'y a aucun processus actif sur le serveur, un changement de répertoire instantané est effectué.
1. Décompresser le code de l'application dans un répertoire « froid ». 2. Basculer le système vers un répertoire « froid », qui devient « chaud » (fonctionnement atomique)
Résultats : 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 disposions d'un système de déploiement très avancé dans lequel nous avons investi beaucoup de temps et d'efforts. Tout ce que nous avions à faire était de reconstruire et d'améliorer nos processus de déploiement. Nous sommes devenus une entreprise assez grande dont les développements ont été utilisés dans le monde entier pour organiser des communications ininterrompues et résoudre des problèmes importants. La fiabilité est donc devenue le centre de notre attention.
Nous devions rendre le processus de déploiement des nouvelles versions de Slack plus sécurisé. Ce besoin nous a amené à améliorer notre système de déploiement. En fait, nous avons discuté de ce système amélioré ci-dessus. Dans les profondeurs du système, nous continuons à utiliser des technologies de déploiement rapide et atomique. La manière dont le déploiement est effectué a changé. Notre nouveau système est conçu pour déployer progressivement du nouveau code à différents niveaux, dans différents environnements. Nous utilisons désormais des outils de support et des outils de surveillance du système plus avancés qu’auparavant. Cela nous donne la possibilité de détecter et de corriger les erreurs bien avant qu’elles n’atteignent l’utilisateur final.
Mais nous n'allons pas nous arrêter là. Nous améliorons constamment ce système, en utilisant des outils auxiliaires et des outils d'automatisation du travail plus avancés.
Chers lecteurs, Comment se déroule le processus de déploiement de nouvelles versions de projet là où vous travaillez ?
Source: habr.com