<\/a><\/noindex><\/p>\nComment fonctionnent aujourd'hui les processus de d\u00e9ploiement de projets<\/h2>\n \nChaque PR (pull request) chez Slack doit faire l'objet d'une r\u00e9vision de code et r\u00e9ussir tous les tests. Ce n'est qu'apr\u00e8s avoir satisfait \u00e0 ces conditions qu'un d\u00e9veloppeur peut fusionner son code avec la branche master du projet. Cependant, le d\u00e9ploiement de ce code n'a lieu que pendant les heures de travail selon l'heure de l'Am\u00e9rique du Nord. En cons\u00e9quence, nos employ\u00e9s \u00e9tant pr\u00e9sents sur leur lieu de travail, nous sommes enti\u00e8rement pr\u00eats \u00e0 r\u00e9soudre tous les probl\u00e8mes inattendus.<\/p>\n
Chaque jour, nous effectuons environ 12 d\u00e9ploiements planifi\u00e9s. Lors de chaque d\u00e9ploiement, le d\u00e9veloppeur d\u00e9sign\u00e9 comme responsable veille \u00e0 la mise en production de la nouvelle version. Il s'agit d'un processus en plusieurs \u00e9tapes qui garantit un d\u00e9ploiement en douceur en mode op\u00e9rationnel. Gr\u00e2ce \u00e0 cette approche, nous pouvons d\u00e9tecter des erreurs avant qu'elles n'affectent tous nos utilisateurs. Si les probl\u00e8mes sont trop nombreux, le d\u00e9ploiement peut \u00eatre annul\u00e9. Si un probl\u00e8me sp\u00e9cifique est d\u00e9tect\u00e9 apr\u00e8s la publication, un correctif peut facilement \u00eatre publi\u00e9.<\/p>\n
L'interface du syst\u00e8me Checkpoint, utilis\u00e9e chez Slack pour le d\u00e9ploiement de projets<\/i><\/p>\n
Le processus de d\u00e9ploiement d'une nouvelle version en production peut \u00eatre pr\u00e9sent\u00e9 comme compos\u00e9 de quatre \u00e9tapes.<\/p>\n
\u258d1. Cr\u00e9ation d'une branche de release<\/h3>\n \nChaque release commence par une nouvelle branche de release \u00e0 partir d'un point de notre historique Git. Cela permet d'attribuer des \u00e9tiquettes \u00e0 la release et offre un espace o\u00f9 l'on peut apporter des corrections rapides pour les bugs identifi\u00e9s lors de la pr\u00e9paration de la release pour la mise en production.<\/p>\n
\u258d2. D\u00e9ploiement dans un environnement interm\u00e9diaire<\/h3>\n \nL'\u00e9tape suivante consiste \u00e0 d\u00e9ployer la build sur les serveurs interm\u00e9diaires (staging) et \u00e0 lancer un test automatique pour v\u00e9rifier la fonctionnalit\u00e9 g\u00e9n\u00e9rale du projet (smoke test). L'environnement interm\u00e9diaire est un environnement de production qui ne re\u00e7oit pas de trafic externe. Dans cet environnement, nous effectuons des tests manuels suppl\u00e9mentaires. Cela nous donne une confiance suppl\u00e9mentaire que le projet modifi\u00e9 fonctionne correctement. Les seuls tests automatis\u00e9s ne suffisent pas pour obtenir une telle certitude.<\/p>\n
\u258d3. D\u00e9ploiement dans des environnements dogfood et canary<\/h3>\n \nLe d\u00e9ploiement en production commence par l'environnement dogfood, constitu\u00e9 d'un ensemble d'h\u00f4tes qui g\u00e8rent nos espaces de travail internes Slack. \u00c9tant de fervents utilisateurs de Slack, cette approche nous a aid\u00e9s \u00e0 d\u00e9tecter de nombreuses erreurs \u00e0 un stade pr\u00e9coce du d\u00e9ploiement. Apr\u00e8s nous \u00eatre assur\u00e9s que les fonctionnalit\u00e9s de base du syst\u00e8me ne sont pas compromises, nous proc\u00e9dons au d\u00e9ploiement de la build dans l'environnement canary. Cet environnement re\u00e7oit environ 2 % du trafic de production.<\/p>\n
\u258d4. Mise en production progressive<\/h3>\n \nSi les indicateurs de surveillance de la nouvelle version restent stables, et si nous ne recevons pas de plaintes apr\u00e8s le d\u00e9ploiement du projet dans l'environnement canary, nous continuons \u00e0 transf\u00e9rer progressivement les serveurs de production vers la nouvelle version. Le processus de d\u00e9ploiement est divis\u00e9 en plusieurs \u00e9tapes : 10 %, 25 %, 50 %, 75 % et 100 %. Cela nous permet de transf\u00e9rer lentement le trafic de production vers la nouvelle version du syst\u00e8me, en ayant du temps pour analyser la situation en cas d'anomalies.<\/p>\n
\u258dQue faire si quelque chose tourne mal lors du d\u00e9ploiement ?<\/h3>\n \nModifier le code comporte toujours des risques. Cependant, nous y faisons face gr\u00e2ce \u00e0 la pr\u00e9sence de nos \u00ab responsables de d\u00e9ploiement \u00bb bien form\u00e9s, qui supervisent le processus de mise en production de nouvelles versions, surveillent les indicateurs de monitoring et coordonnent le travail des d\u00e9veloppeurs qui publient le code.<\/p>\n
Dans le cas o\u00f9 quelque chose ne se passe pas comme pr\u00e9vu, nous essayons de d\u00e9tecter le probl\u00e8me le plus t\u00f4t possible. Nous examinons le probl\u00e8me, trouvons le PR qui cause des erreurs, le r\u00e9gressons, analysons minutieusement et cr\u00e9ons un nouveau build. Il arrive cependant que le probl\u00e8me passe inaper\u00e7u jusqu'\u00e0 la mise en production du projet. Dans une telle situation, l'essentiel est de r\u00e9tablir le service. C'est pourquoi, avant de commencer l'analyse du probl\u00e8me, nous revenons imm\u00e9diatement \u00e0 la derni\u00e8re version fonctionnelle.<\/p>\n
Les briques du syst\u00e8me de d\u00e9ploiement<\/h2>\n \nExaminons les technologies qui sous-tendent notre syst\u00e8me de d\u00e9ploiement de projets.<\/p>\n
\u258dD\u00e9ploiements rapides<\/h3>\n \nLe processus de travail d\u00e9crit ci-dessus peut sembler, avec du recul, compl\u00e8tement \u00e9vident. Mais notre syst\u00e8me de d\u00e9ploiement n'a pas atteint cette efficacit\u00e9 instantan\u00e9ment.<\/p>\n
Lorsque l'entreprise \u00e9tait beaucoup plus petite, l'ensemble de notre application pouvait fonctionner sur 10 instances Amazon EC2. D\u00e9ployer le projet dans cette situation impliquait d'utiliser rsync pour synchroniser rapidement tous les serveurs. Auparavant, un seul pas s\u00e9parait le nouveau code de la production, ce qui se pr\u00e9sentait sous la forme d'un environnement interm\u00e9diaire. Les builds \u00e9taient cr\u00e9\u00e9s et v\u00e9rifi\u00e9s dans cet environnement, puis envoyaient directement en production. Comprendre ce syst\u00e8me \u00e9tait tr\u00e8s simple, il permettait \u00e0 n'importe quel d\u00e9veloppeur de d\u00e9ployer son code \u00e0 tout moment.<\/p>\n
Mais \u00e0 mesure que le nombre de nos clients augmentait, l'infrastructure n\u00e9cessaire pour faire fonctionner le projet s'est \u00e9galement \u00e9largie. Rapidement, face \u00e0 la croissance continue du syst\u00e8me, notre mod\u00e8le de d\u00e9ploiement, bas\u00e9 sur l'envoi de nouveau code vers les serveurs, a cess\u00e9 de fonctionner. En effet, l'ajout de chaque nouveau serveur signifiait une augmentation du temps n\u00e9cessaire pour r\u00e9aliser le d\u00e9ploiement. M\u00eame les strat\u00e9gies bas\u00e9es sur l'application parall\u00e8le de rsync ont leurs limitations.<\/p>\n
Nous avons donc r\u00e9solu ce probl\u00e8me en passant \u00e0 un syst\u00e8me de d\u00e9ploiement enti\u00e8rement parall\u00e8le, con\u00e7u diff\u00e9remment de l'ancien syst\u00e8me. En effet, nous n'envoyions plus le code sur les serveurs en utilisant un script de synchronisation. Chaque serveur charge d\u00e9sormais la nouvelle version de mani\u00e8re autonome, se rendant compte qu'il doit le faire gr\u00e2ce \u00e0 l'observation du changement de cl\u00e9 Consul. Les serveurs chargeaient le code en parall\u00e8le. Cela nous a permis de maintenir une vitesse de d\u00e9ploiement \u00e9lev\u00e9e m\u00eame dans une situation de croissance constante du syst\u00e8me.<\/p>\n
1. Les serveurs de production observent la cl\u00e9 Consul. 2. La cl\u00e9 change, ce qui informe les serveurs qu'ils doivent commencer \u00e0 charger le nouveau code. 3. Les serveurs chargent les fichiers tarball contenant le code de l'application.<\/i><\/p>\n\u258dD\u00e9ploiements atomiques<\/h3>\n
\nUne autre solution qui nous a permis d'atteindre un syst\u00e8me de d\u00e9ploiement \u00e0 plusieurs niveaux a \u00e9t\u00e9 le d\u00e9ploiement atomique.<\/p>\n
Avant d'utiliser des d\u00e9ploiements atomiques, chaque d\u00e9ploiement pouvait entra\u00eener un grand nombre de messages d'erreur. En effet, le processus de copie des nouveaux fichiers sur les serveurs de production n'\u00e9tait pas atomique. Cela cr\u00e9ait une courte p\u00e9riode durant laquelle le code appelant les nouvelles fonctions \u00e9tait accessible avant que ces fonctions ne le soient. Lorsque ce code \u00e9tait appel\u00e9, il entra\u00eenait des erreurs internes. Cela se manifestait par des requ\u00eates API \u00e9chou\u00e9es et des pages web \"cass\u00e9es\".<\/p>\n
L'\u00e9quipe charg\u00e9e de ce probl\u00e8me l'a r\u00e9solu en introduisant les concepts de r\u00e9pertoires \"chauds\" (hot) et \"froids\" (cold). Le code dans le r\u00e9pertoire \"chaud\" traite le trafic de production. Dans les r\u00e9pertoires \"froids\", le code se pr\u00e9pare simplement \u00e0 \u00eatre utilis\u00e9 pendant que le syst\u00e8me fonctionne. Lors du d\u00e9ploiement, le nouveau code est copi\u00e9 dans un r\u00e9pertoire \"froid\" inutilis\u00e9. Ensuite, lorsque le serveur ne comporte plus de processus actifs, un basculement instantan\u00e9 des r\u00e9pertoires est effectu\u00e9.<\/p>\n
1. D\u00e9compression du code de l'application dans le r\u00e9pertoire \"froid\". 2. Basculement du syst\u00e8me vers le r\u00e9pertoire \"froid\", qui devient \"chaud\" (op\u00e9ration atomique).<\/i><\/p>\nR\u00e9sum\u00e9 : un changement de focus vers la fiabilit\u00e9.<\/h2>\n
\nEn 2018, le projet a atteint une taille telle que le d\u00e9ploiement tr\u00e8s rapide a commenc\u00e9 \u00e0 nuire \u00e0 la stabilit\u00e9 du produit. Nous avions un syst\u00e8me de d\u00e9ploiement assez avanc\u00e9, dans lequel nous avions investi beaucoup d'efforts et de temps. Nous devions simplement restructurer et am\u00e9liorer les processus d'organisation du d\u00e9ploiement. Nous \u00e9tions devenus une entreprise suffisamment importante, dont les d\u00e9veloppements \u00e9taient utilis\u00e9s dans le monde entier pour assurer une communication ininterrompue et r\u00e9soudre des probl\u00e8mes cruciaux. C'est pourquoi la fiabilit\u00e9 est devenue notre priorit\u00e9.<\/p>\n
Nous devions rendre le processus de d\u00e9ploiement des nouvelles versions de Slack plus s\u00e9curis\u00e9. Ce besoin nous a conduits \u00e0 am\u00e9liorer notre syst\u00e8me de d\u00e9ploiement. En effet, nous avons discut\u00e9 de ce syst\u00e8me perfectionn\u00e9 plus haut. Au sein du syst\u00e8me, nous continuons \u00e0 utiliser des technologies de d\u00e9ploiement rapide et atomique. Ce qui a chang\u00e9, c'est la mani\u00e8re dont le d\u00e9ploiement est effectivement r\u00e9alis\u00e9. Notre nouveau syst\u00e8me est con\u00e7u pour ex\u00e9cuter progressivement le d\u00e9ploiement de nouveau code \u00e0 diff\u00e9rents niveaux et dans diff\u00e9rents environnements. Nous utilisons d\u00e9sormais des outils de soutien et de surveillance du syst\u00e8me plus avanc\u00e9s qu'auparavant. Cela nous permet d'identifier et de corriger les erreurs bien avant qu'elles n'aient une chance d'atteindre l'utilisateur final.<\/p>\n
Mais nous ne comptons pas en rester l\u00e0. Nous continuons \u00e0 am\u00e9liorer ce syst\u00e8me en appliquant des outils de soutien et des moyens d'automatisation plus sophistiqu\u00e9s.<\/p>\n
Chers lecteurs !<\/b> Comment se d\u00e9roule le processus de d\u00e9ploiement des nouvelles versions de projets l\u00e0 o\u00f9 vous travaillez ?<\/p>\n
habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77784,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t