<\/a><\/noindex><\/p>\nHur distributionsprocesserna f\u00f6r projekt fungerar idag<\/h2>\n \nVarje PR (pull request) i Slack m\u00e5ste obligatoriskt genomg\u00e5 kodgranskning och m\u00e5ste framg\u00e5ngsrikt klara alla tester. F\u00f6rst efter att dessa villkor har uppfyllts kan programmeraren sl\u00e5 samman sin kod med master-grenen i projektet. Dock utf\u00f6rs distribution av s\u00e5dan kod endast under arbetstid enligt nordamerikansk tid. Som en f\u00f6ljd \u00e4r vi, eftersom v\u00e5ra anst\u00e4llda \u00e4r p\u00e5 sina arbetsplatser, helt redo f\u00f6r att hantera eventuella ov\u00e4ntade problem.<\/p>\n
Varje dag genomf\u00f6r vi runt 12 planerade distributioner. Vid varje distribution \u00e4r den programmerare som \u00e4r utsedd som huvudansvarig f\u00f6r distributionen ansvarig f\u00f6r att lansera den nya versionen i produktion. Detta \u00e4r en flertrinsprocess som s\u00e4kerst\u00e4ller en smidig \u00f6verg\u00e5ng av byggnaden till drift. Tack vare denna metod kan vi uppt\u00e4cka fel innan de p\u00e5verkar alla v\u00e5ra anv\u00e4ndare. Om det skulle uppst\u00e5 f\u00f6r m\u00e5nga fel kan distributionen av versionen \u00e5terst\u00e4llas. Om dock ett enskilt problem uppt\u00e4cks efter lanseringen kan en fix enkelt sl\u00e4ppas f\u00f6r det.<\/p>\n
Gr\u00e4nssnittet f\u00f6r Checkpoint-systemet som anv\u00e4nds p\u00e5 Slack f\u00f6r distribution av projekt<\/i><\/p>\n
Processen f\u00f6r att distribuera en ny version i produktion kan beskrivas som best\u00e5ende av fyra steg.<\/p>\n
\u258d1. Skapa en releasegren<\/h3>\n \nVarje release b\u00f6rjar med en ny releasegren, som markerar en punkt i v\u00e5r Git-historia. Detta m\u00f6jligg\u00f6r att vi kan tilldela taggar till releasen och ger en plats f\u00f6r att g\u00f6ra akuta korrigeringar f\u00f6r fel som uppt\u00e4ckts under f\u00f6rberedelserna f\u00f6r att sl\u00e4ppa den i produktion.<\/p>\n
\u258d2. Utrullning i staging-milj\u00f6<\/h3>\n \nN\u00e4sta steg \u00e4r att rulla ut bygget p\u00e5 staging-servrar och k\u00f6ra automatiserade tester f\u00f6r att kontrollera den \u00f6vergripande funktionaliteten hos projektet (smoke test). Staging-milj\u00f6n \u00e4r en produktion-milj\u00f6 d\u00e4r extern trafik inte n\u00e5r. I denna milj\u00f6 utf\u00f6r vi ytterligare manuell testning. Detta ger oss extra trygghet i att det \u00e4ndrade projektet fungerar korrekt. Endast automatiserade tester \u00e4r inte tillr\u00e4ckliga f\u00f6r att uppn\u00e5 samma niv\u00e5 av s\u00e4kerhet.<\/p>\n
\u258d3. Utrullning i dogfood- och canary-milj\u00f6er<\/h3>\n \nUtrullningen i produktionen b\u00f6rjar med dogfood-milj\u00f6n, som best\u00e5r av en upps\u00e4ttning v\u00e4rdar som hanterar v\u00e5ra interna arbetsytor i Slack. Eftersom vi \u00e4r mycket aktiva anv\u00e4ndare av Slack har denna metod hj\u00e4lpt oss att uppt\u00e4cka m\u00e5nga fel i ett tidigt skede av utrullningen. N\u00e4r vi har s\u00e4kerst\u00e4llt att systemets grundl\u00e4ggande funktionalitet inte har p\u00e5verkats, utf\u00f6r vi utrullningen av bygget i canary-milj\u00f6n. Denna milj\u00f6 representerar system som f\u00e5r ungef\u00e4r 2% av produktionstrafiken.<\/p>\n
\u258d4. Gradvis \u00f6verg\u00e5ng till produktion<\/h3>\n \nOm \u00f6vervakningsm\u00e4tningarna f\u00f6r den nya releasen visar sig vara stabila, och om vi inte har f\u00e5tt n\u00e5gra klagom\u00e5l efter att projektet rullats ut i canary-milj\u00f6n, forts\u00e4tter vi den gradvisa \u00f6verg\u00e5ngen av produktionsservrarna till den nya releasen. Utrullningsprocessen \u00e4r uppdelad i f\u00f6ljande steg: 10%, 25%, 50%, 75% och 100%. Detta g\u00f6r att vi l\u00e5ngsamt kan dirigera produktionstrafiken till den nya releasen av systemet. Under tiden har vi tid att unders\u00f6ka situationen ifall vi uppt\u00e4cker n\u00e5gra anomalier.<\/p>\n
\u258dVad ska man g\u00f6ra om n\u00e5got g\u00e5r fel under utrullningen?<\/h3>\n \nAtt g\u00f6ra \u00e4ndringar i koden inneb\u00e4r alltid en risk. Men vi hanterar detta tack vare v\u00e5ra v\u00e4lutbildade 'deploy-chefer' som leder processen f\u00f6r att f\u00e5 ut nya versioner i produktion, \u00f6vervakar \u00f6vervakningsdata och koordinerar programmerarnas arbete med kodutg\u00e5vor.<\/p>\n
Om n\u00e5got faktiskt g\u00e5r fel f\u00f6rs\u00f6ker vi uppt\u00e4cka problemet s\u00e5 tidigt som m\u00f6jligt. Vi unders\u00f6ker problemet, hittar PR som orsakar fel, rullar tillbaka det, analyserar noggrant och skapar en ny byggnad. Ibland kan problemet dock f\u00f6rbli ouppt\u00e4ckt fram till projektet g\u00e5r i produktion. I s\u00e5dana situationer \u00e4r det viktigast att \u00e5teruppr\u00e4tta tj\u00e4nsten. D\u00e4rf\u00f6r rullar vi tillbaka till den senaste fungerande byggnaden innan vi p\u00e5b\u00f6rjar problemet.<\/p>\n
Byggstenarna i v\u00e5rt distributionssystem<\/h2>\n \nL\u00e5t oss titta p\u00e5 teknologierna som ligger till grund f\u00f6r v\u00e5rt projektdistributionssystem.<\/p>\n
\u258dSnabba distributioner<\/h3>\n \nArbetsprocessen som beskrivits ovan kan i efterhand verka helt sj\u00e4lvklart. Men v\u00e5rt distributionssystem blev inte s\u00e5 direkt.<\/p>\n
N\u00e4r f\u00f6retaget var betydligt mindre kunde hela v\u00e5r applikation k\u00f6ras p\u00e5 10 Amazon EC2-instansar. Distribution av projektet i en s\u00e5dan situation innebar att anv\u00e4nda rsync f\u00f6r snabb synkronisering av alla servrar. Tidigare skilde det bara ett steg, representerat av en mellanliggande milj\u00f6, den nya koden fr\u00e5n produktion. Byggnader skapades och testades i en s\u00e5dan milj\u00f6 och gick sedan direkt till produktion. Det var mycket enkelt att f\u00f6rst\u00e5 ett s\u00e5dant system, det gjorde det m\u00f6jligt f\u00f6r vilken programmerare som helst att n\u00e4r som helst distribuera den kod de skrivit.<\/p>\n
Men i takt med att antalet kunder \u00f6kade, v\u00e4xte ocks\u00e5 omfattningen av infrastrukturen som beh\u00f6vdes f\u00f6r att st\u00f6dja projektets drift. Snart, med den kontinuerliga tillv\u00e4xten av systemet, slutade v\u00e5r distributionsmodell, som var baserad p\u00e5 att skicka ny kod till servrar, att fungera. Varje ny server som lades till innebar en \u00f6kning av den tid som kr\u00e4vdes f\u00f6r distribution. \u00c4ven strategier som baserades p\u00e5 parallella rsync-till\u00e4mpningar har sina begr\u00e4nsningar.<\/p>\n
Som ett resultat beslutade vi att l\u00f6sa detta problem genom att \u00f6verg\u00e5 till ett helt parallellt distributionssystem, som \u00e4r uppbyggt p\u00e5 ett annat s\u00e4tt \u00e4n det gamla systemet. N\u00e4mligen, nu skickade vi inte koden till servrarna med hj\u00e4lp av ett synkroniseringsskript. Nu laddade varje server ner den nya versionen sj\u00e4lv, genom att ta reda p\u00e5 att detta beh\u00f6vdes genom att observera f\u00f6r\u00e4ndringen av Consul-nyckeln. Servrarna laddade ner koden parallellt. Detta gjorde att vi kunde uppr\u00e4tth\u00e5lla en h\u00f6g distributionshastighet \u00e4ven i en milj\u00f6 med st\u00e4ndig systemtillv\u00e4xt.<\/p>\n
1. Produktionsservrarna \u00f6vervakar Consul-nyckeln. 2. Nyckeln \u00e4ndras, vilket meddelar servrarna att de ska b\u00f6rja ladda ner ny kod. 3. Servrarna laddar ner tarball-filer med applikationskoden.<\/i><\/p>\n\u258dAtom\u00e4ra distributioner<\/h3>\n
\nEn annan l\u00f6sning som hj\u00e4lpte oss att n\u00e5 ett flerlagers distributionssystem var atom\u00e4r distribution.<\/p>\n
Innan vi anv\u00e4nde atom\u00e4ra distributioner kunde varje distribution leda till en stor m\u00e4ngd felmeddelanden. Det berodde p\u00e5 att processen med att kopiera nya filer till produktionsservrarna inte var atom\u00e4r. Detta ledde till att det fanns en kort tidsperiod d\u00e5 koden som gav tillg\u00e5ng till nya funktioner var tillg\u00e4nglig innan dessa funktioner sj\u00e4lva var aktiverade. N\u00e4r s\u00e5dan kod anropades ledde det till interna fel. Det visade sig i misslyckade API-anrop och 'trasiga' webbsidor.<\/p>\n
Teamet som arbetade med detta problem l\u00f6ste det genom att inf\u00f6ra begreppen 'heta' (hot) och 'kalla' (cold) kataloger. Koden i den 'heta' katalogen ansvarar f\u00f6r behandlingen av produktionstrafik. I de 'kalla' katalogerna f\u00f6rbereds koden under systemets drift f\u00f6r anv\u00e4ndning. Under distributionen kopieras den nya koden till en oanv\u00e4nd 'kall' katalog. Sedan, n\u00e4r det inte finns n\u00e5gra aktiva processer p\u00e5 servern, g\u00f6rs en omedelbar v\u00e4xling av katalogerna.<\/p>\n
1. Packa upp applikationskoden i den 'kalla' katalogen. 2. V\u00e4xla systemet till den 'kalla' katalogen, som blir 'het' (atom\u00e4r operation)<\/i><\/p>\nSammanfattning: F\u00f6rflyttning av fokus mot tillf\u00f6rlitlighet<\/h2>\n
\nUnder 2018 n\u00e5dde projektet en storlek d\u00e4r snabb distribution b\u00f6rjade skada produktens stabilitet. Vi hade ett ganska avancerat distributionssystem, d\u00e4r vi nedlagt mycket tid och kraft. Vi beh\u00f6vde bara omorganisera och f\u00f6rb\u00e4ttra distributionsprocesserna. Vi hade blivit ett tillr\u00e4ckligt stort f\u00f6retag, vars l\u00f6sningar anv\u00e4ndes v\u00e4rlden \u00f6ver f\u00f6r att s\u00e4kerst\u00e4lla oavbruten kommunikation och l\u00f6sa viktiga problem. D\u00e4rf\u00f6r blev tillf\u00f6rlitlighet v\u00e5rt fokus.<\/p>\n
Vi beh\u00f6vde g\u00f6ra processen f\u00f6r att distribuera nya Slack-versioner s\u00e4krare. Detta behov ledde oss till att f\u00f6rb\u00e4ttra v\u00e5rt distributionssystem. Som vi n\u00e4mnde tidigare diskuterade vi just detta f\u00f6rb\u00e4ttrade system. Inom systemet forts\u00e4tter vi att anv\u00e4nda teknologier f\u00f6r snabb och atom\u00e4r distribution. Det har f\u00f6r\u00e4ndrat s\u00e4ttet p\u00e5 vilket distributionen utf\u00f6rs. V\u00e5rt nya system \u00e4r utformat f\u00f6r att gradvis distribuera ny kod p\u00e5 olika niv\u00e5er och i olika milj\u00f6er. Vi anv\u00e4nder nu mer avancerade verktyg och \u00f6vervakningsmedel \u00e4n tidigare. Detta ger oss m\u00f6jlighet att f\u00e5nga och \u00e5tg\u00e4rda fel l\u00e5ngt innan de f\u00e5r chans att n\u00e5 slutanv\u00e4ndaren.<\/p>\n
Men vi t\u00e4nker inte stanna h\u00e4r. Vi f\u00f6rb\u00e4ttrar st\u00e4ndigt detta system genom att till\u00e4mpa mer avancerade hj\u00e4lpverktyg och automatiseringsmedel.<\/p>\n
K\u00e4ra l\u00e4sare!<\/b> Hur fungerar processen f\u00f6r distribution av nya projektversioner p\u00e5 din arbetsplats?<\/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