<\/a><\/noindex><\/p>\nHvordan projekternes implementeringsprocesser fungerer i dag<\/h2>\n \nHver PR (pull request) i Slack skal n\u00f8dvendigvis gennemg\u00e5 en koderevision og skal best\u00e5 alle tests. F\u00f8rst efter at disse betingelser er opfyldt, kan programm\u00f8ren udf\u00f8re sammenl\u00e6gningen af sin kode med master-grenen af projektet. Implementeringen af denne kode udf\u00f8res dog kun i arbejdstimer efter nordamerikansk tid. Som resultat er vi, da vores ansatte er p\u00e5 arbejdspladsen, fuldst\u00e6ndig klare til at h\u00e5ndtere enhver uventet problemstilling.<\/p>\n
Hver dag udf\u00f8rer vi omkring 12 planlagte implementeringer. I forbindelse med hver implementering er programm\u00f8ren, der er udpeget som ansvarlig for implementeringen, ansvarlig for at bringe den nye bygning i produktion. Det er en flertrinsproces, der sikrer en glat overf\u00f8rsel af bygningen til driftsstatus. Takket v\u00e6re denne tilgang kan vi opdage fejl, f\u00f8r de rammer alle vores brugere. Hvis der viser sig at v\u00e6re for mange fejl, kan implementeringen af bygningen rulles tilbage. Hvis en bestemt problemstilling opdages efter udgivelsen, kan der nemt udsendes en rettelse til den.<\/p>\n
Brugerfladen i Checkpoint-systemet, som bruges i Slack til implementering af projekter<\/i><\/p>\n
Processen for implementering af en ny udgivelse i produktion kan opdeles i fire trin.<\/p>\n
\u258d1. Oprettelse af en releasegren<\/h3>\n \nHver release begynder med en ny releasegren fra det punkt i vores Git-historik. Dette muligg\u00f8r at tildele tags til releasen og giver et sted, hvor man kan foretage hurtige rettelser for fejl, der findes under forberedelsen af releasen til produktion.<\/p>\n
\u258d2. Deployment til staging-milj\u00f8<\/h3>\n \nN\u00e6ste trin i arbejdet er at implementere bygningen p\u00e5 staging-servere og k\u00f8re automatiserede tests for den overordnede funktionalitet af projektet (smoke test). Staging-milj\u00f8et er et produktionsmilj\u00f8, der ikke modtager ekstern trafik. I dette milj\u00f8 udf\u00f8rer vi yderligere manuel testning. Dette giver os ekstra sikkerhed for, at det \u00e6ndrede projekt fungerer korrekt. Automatiserede tests alene er ikke tilstr\u00e6kkelige for at opn\u00e5 en s\u00e5dan sikkerhed.<\/p>\n
\u258d3. Deployment til dogfood- og canary-milj\u00f8er<\/h3>\n \nDeployment i produktion starter med dogfood-milj\u00f8et, som best\u00e5r af en r\u00e6kke v\u00e6rter, der betjener vores interne arbejdsrum i Slack. Da vi er meget aktive brugere af Slack, har denne tilgang hjulpet os med at opdage mange fejl tidligt i deploymentsprocessen. Efter at vi har bekr\u00e6ftet, at systemets grundl\u00e6ggende funktionalitet ikke er blevet p\u00e5virket, udf\u00f8res deployment af bygningen i canary-milj\u00f8et. Dette er systemer, der h\u00e5ndterer cirka 2% af produktions-trafikken.<\/p>\n
\u258d4. Gradvis udrulning til produktion<\/h3>\n \nHvis overv\u00e5gningsdataene for den nye release er stabile, og hvis vi ikke har modtaget klager efter deployment i canary-milj\u00f8et, forts\u00e6tter vi med den gradvise overf\u00f8rsel af produktionsservere til den nye release. Udrulningsprocessen er opdelt i f\u00f8lgende trin: 10%, 25%, 50%, 75% og 100%. Dette giver os mulighed for langsomt at lede produktions-trafikken til den nye release af systemet. P\u00e5 den m\u00e5de har vi tid til at unders\u00f8ge situationen, hvis der opdages anomalier.<\/p>\n
\u258dHvad skal man g\u00f8re, hvis noget g\u00e5r galt under udrulning?<\/h3>\n \nAt \u00e6ndre i koden er altid en risiko. Men vi h\u00e5ndterer det takket v\u00e6re vores veluddannede 'deploy-chefer', der leder processen med at bringe en ny version i produktion, overv\u00e5ger overv\u00e5gningsm\u00e5linger og koordinerer arbejdet med programm\u00f8rer, der udsender koden.<\/p>\n
Hvis noget s\u00e5 virkelig gik galt, fors\u00f8ger vi at opdage problemet s\u00e5 tidligt som muligt. Vi unders\u00f8ger problemet, finder PR'en, der for\u00e5rsager fejlene, ruller den tilbage, analyserer grundigt og skaber en ny build. Nogle gange viser det sig dog, at problemet ikke opdages, f\u00f8r projektet er i produktion. I s\u00e5dan en situation er det vigtigste at genoprette tjenestens funktion. Derfor ruller vi umiddelbart tilbage til den tidligere fungerende build, inden vi p\u00e5begynder problemforskningen.<\/p>\n
Byggeblokke i deploymentsystemet<\/h2>\n \nLad os se p\u00e5 teknologierne bag vores projektdistributionssystem.<\/p>\n
\u258dHurtige udrulninger<\/h3>\n \nDen beskrevne arbejdsproces kan fremst\u00e5 som noget helt indlysende i retrospektiv. Men vores distributionssystem blev ikke til p\u00e5 et \u00f8jeblik.<\/p>\n
Da virksomheden var betydeligt mindre, kunne hele vores applikation k\u00f8re p\u00e5 10 Amazon EC2-instanser. Udrulning af projektet i denne situation bet\u00f8d at bruge rsync til hurtig synkronisering af alle servere. Tidligere var der kun \u00e9t skridt, der adskilte den nye kode fra produktionen, repr\u00e6senteret ved et mellemstadie. Builds blev skabt og verificeret i et s\u00e5dant milj\u00f8, og derefter gik de direkte til produktion. At finde rundt i et s\u00e5dant system var meget enkelt; det gjorde det muligt for enhver programm\u00f8r at deploye sin kode n\u00e5r som helst.<\/p>\n
Men efterh\u00e5nden som antallet af vores kunder voksede, voksede ogs\u00e5 st\u00f8rrelsen p\u00e5 den infrastruktur, der var n\u00f8dvendig for at sikre drift af projektet. Snart, i takt med den vedvarende v\u00e6kst af systemet, kunne vores distributionsmodel, der var baseret p\u00e5 at sende ny kode til serverne, ikke l\u00e6ngere klare opgaven. Hver nye server bet\u00f8d \u00f8get tid til udf\u00f8relse af udrulningen. Selv strategier, der er baseret p\u00e5 parallelrsync, har visse begr\u00e6nsninger.<\/p>\n
Som f\u00f8lge af dette har vi l\u00f8st problemet ved at overg\u00e5 til et fuldt parallelt system til implementering, som er opbygget anderledes end det gamle system. Det vil sige, at vi nu ikke sendte koden til serverne ved hj\u00e6lp af et synkroniseringsscript. Nu downloader hver server selv den nye version, idet den f\u00e5r besked om, at dette skal g\u00f8res ved at overv\u00e5ge \u00e6ndringer i Consul-n\u00f8glen. Serverne henter koden parallelt. Dette har gjort det muligt for os at opretholde en h\u00f8j implementeringshastighed, selv i en situation med konstant v\u00e6kst i systemet.<\/p>\n
1. Produktionsserverne overv\u00e5ger Consul-n\u00f8gle. 2. N\u00f8glen \u00e6ndres, hvilket informerer serverne om, at de skal begynde at downloade ny kode. 3. Serverne downloader tarball-filer med applikationskoden.<\/i><\/p>\n\u258dAtomiske implementeringer<\/h3>\n
\nEn anden l\u00f8sning, der hjalp os med at n\u00e5 frem til et multilags implementeringssystem, var atomisk implementering.<\/p>\n
F\u00f8r brugen af atomiske implementeringer kunne hver implementering f\u00f8re til en lang r\u00e6kke fejlmeddelelser. Det skyldes, at processen med at kopiere nye filer til produktionsserverne ikke var atomisk. Dette f\u00f8rte til eksisteringen af et kort tidsvindue, hvor koden, der kaldte nye funktioner, blev tilg\u00e6ngelig, f\u00f8r selve funktionerne blev tilg\u00e6ngelige. N\u00e5r s\u00e5dan kode blev kaldt, medf\u00f8rte det, at der blev returneret interne fejl. Dette kom til udtryk i mislykkede API-anmodninger og \"knuste\" web-sider.<\/p>\n
Holdet, der arbejdede med dette problem, l\u00f8ste det ved at indf\u00f8re begreberne \"varme\" (hot) og \"kolde\" (cold) mapper. Koden i den \"varme\" mappe h\u00e5ndterer produktions-trafikken. I de \"kolde\" mapper forberedes koden til brug, mens systemet k\u00f8rer. Under implementeringen kopieres den nye kode til en ubenyttet \"kold\" mappe. Derefter, n\u00e5r der ikke er aktive processer p\u00e5 serveren, sker der et \u00f8jeblikkeligt skift mellem mapperne.<\/p>\n
1. Udpakning af applikationskoden til den \"kolde\" mappe. 2. Skift af systemet til den \"kolde\" mappe, som bliver \"varm\" (atomisk operation).<\/i><\/p>\nKonklusioner: Fokus p\u00e5 p\u00e5lidelighed<\/h2>\n
\nI 2018 voksede projektet til en st\u00f8rrelse, hvor meget hurtig implementering begyndte at skade stabiliteten af produktet. Vi havde et ganske avanceret implementeringssystem, som vi havde investeret meget tid og kr\u00e6fter i. Vi skulle bare omstrukturere og forbedre processerne omkring implementeringen. Vi var blevet en ret stor virksomhed, hvis udviklinger blev brugt over hele verden til at sikre uafbrudt kommunikation og til at l\u00f8se vigtige opgaver. Derfor blev p\u00e5lidelighed vores hovedfokus.<\/p>\n
Vi skulle g\u00f8re processen med at implementere nye versioner af Slack mere sikker. Denne n\u00f8dvendighed f\u00f8rte til forbedringen af vores implementeringssystem. Faktisk har vi talt om det forbedrede system ovenfor. Inden i systemet forts\u00e6tter vi med at bruge teknologier til hurtig og atomar implementering. Det, der har \u00e6ndret sig, er, hvordan implementeringen faktisk udf\u00f8res. Vores nye system er designet til gradvist at implementere ny kode p\u00e5 forskellige niveauer og i forskellige milj\u00f8er. Nu bruger vi mere avancerede hj\u00e6lpev\u00e6rkt\u00f8jer og systemoverv\u00e5gningsmidler end f\u00f8r. Dette giver os mulighed for at fange og rette fejl l\u00e6nge f\u00f8r, de n\u00e5r den endelige bruger.<\/p>\n
Men vi har ikke t\u00e6nkt os at stoppe her. Vi forbedrer konstant dette system ved at anvende mere avancerede hj\u00e6lpev\u00e6rkt\u00f8jer og automatiseringsmidler.<\/p>\n
K\u00e6re l\u00e6sere!<\/b> Hvordan er processen med at implementere nye versioner af projekterne, hvor du arbejder?<\/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