At bringe en ny projektudgivelse i produktion kræver en omhyggelig balance mellem implementeringshastighed og løsningspålidelighed. Slack værdier hurtige iterationer, korte feedback-cyklusser og hurtig respons på brugeranmodninger. Derudover har virksomheden hundredvis af programmører, der stræber efter at være så produktive som muligt.
Forfatterne af materialet, hvis oversættelse vi udgiver i dag, siger, at en virksomhed, der stræber efter at overholde sådanne værdier og samtidig vokser, konstant skal forbedre sit system til implementering af projekter. Virksomheden skal investere i gennemsigtighed og pålidelighed af arbejdsprocesser, hvilket gør dette for at sikre, at disse processer svarer til projektets omfang. Her vil vi fortælle om de arbejdsgange, der har udviklet sig i Slack, og om nogle af de beslutninger, der fik virksomheden til at bruge det projektimplementeringssystem, der findes i dag.
Hvordan projektimplementeringsprocesser fungerer i dag
Hver PR (pull request) i Slack skal være genstand for kodegennemgang og skal bestå alle tests. Først efter at disse betingelser er opfyldt, kan programmøren flette sin kode ind i projektets mastergren. Denne kode implementeres dog kun i åbningstiden, nordamerikansk tid. Som et resultat, på grund af det faktum, at vores medarbejdere er på deres arbejdsplads, er vi fuldt ud parate til at løse eventuelle uventede problemer.
Hver dag gennemfører vi omkring 12 planlagte udsendelser. Under hver implementering er programmøren, der er udpeget som implementeringsleder, ansvarlig for at få den nye build i produktion. Dette er en flertrinsproces, der sikrer, at samlingen bringes i produktion uden problemer. Takket være denne tilgang kan vi opdage fejl, før de påvirker alle vores brugere. Hvis der er for mange fejl, kan implementeringen af samlingen rulles tilbage. Hvis et specifikt problem opdages efter udgivelsen, kan der nemt frigives en rettelse til det.
Interface af Checkpoint-systemet, som bruges i Slack til at implementere projekter
Processen med at implementere en ny udgivelse til produktion kan opfattes som bestående af fire trin.
▍1. Oprettelse af en udgivelsesgren
Hver udgivelse starter med en ny udgivelsesgren, et punkt i vores Git-historie. Dette giver dig mulighed for at tildele tags til udgivelsen og giver et sted, hvor du kan lave live rettelser til fejl fundet i processen med at forberede udgivelsen til udgivelse til produktion.
▍2. Implementering i et iscenesættelsesmiljø
Det næste trin er at implementere assembly på iscenesættelsesservere og køre en automatisk test for projektets overordnede ydeevne (røgtest). Staging-miljøet er et produktionsmiljø, der ikke modtager ekstern trafik. I dette miljø udfører vi yderligere manuelle tests. Dette giver os yderligere tillid til, at det ændrede projekt fungerer korrekt. Automatiserede test alene er ikke nok til at give dette niveau af tillid.
▍3. Udrulning i dogfood og kanariske miljøer
Implementering til produktion starter med et dogfood-miljø, repræsenteret af et sæt værter, der betjener vores interne Slack-arbejdsområder. Da vi er meget aktive Slack-brugere, hjalp denne tilgang os med at fange en masse fejl tidligt i implementeringen. Efter at vi har sikret os, at systemets grundlæggende funktionalitet ikke er brudt, udplaceres samlingen i kanariemiljøet. Det repræsenterer systemer, der tegner sig for ca. 2% af produktionstrafikken.
▍4. Gradvis frigivelse til produktion
Hvis overvågningsindikatorerne for den nye udgivelse viser sig at være stabile, og hvis vi efter implementeringen af projektet i det kanariske miljø ikke har modtaget nogen klager, fortsætter vi gradvist med at overføre produktionsserverne til den nye udgivelse. Implementeringsprocessen er opdelt i følgende faser: 10 %, 25 %, 50 %, 75 % og 100 %. Som et resultat kan vi langsomt overføre produktionstrafik til den nye udgivelse af systemet. Samtidig har vi tid til at undersøge situationen, hvis der opdages uregelmæssigheder.
▍Hvad hvis noget går galt under implementeringen?
Det er altid en risiko at lave ændringer i koden. Men vi klarer dette takket være tilstedeværelsen af veluddannede "implementeringsledere", som styrer processen med at bringe en ny udgivelse i produktion, overvåger overvågningsindikatorer og koordinerer arbejdet med programmører, der udgiver kode.
I tilfælde af at noget virkelig går galt, forsøger vi at opdage problemet så tidligt som muligt. Vi undersøger problemet, finder den PR, der forårsager fejlene, ruller den tilbage, analyserer den grundigt og opretter en ny build. Sandt nok, nogle gange går problemet ubemærket hen, indtil projektet går i produktion. I en sådan situation er det vigtigste at genoprette tjenesten. Derfor, før vi begynder at undersøge problemet, går vi straks tilbage til den tidligere fungerende build.
Byggesten i et implementeringssystem
Lad os se på de teknologier, der ligger til grund for vores projektimplementeringssystem.
▍Hurtige implementeringer
Den ovenfor beskrevne arbejdsgang kan, set i bakspejlet, virke noget indlysende. Men vores implementeringssystem blev ikke på denne måde med det samme.
Da virksomheden var meget mindre, kunne hele vores applikation køre på 10 Amazon EC2-instanser. At implementere projektet i denne situation betød at bruge rsync til hurtigt at synkronisere alle servere. Tidligere var ny kode kun et skridt væk fra produktion, repræsenteret ved et iscenesættelsesmiljø. Samlinger blev skabt og testet i et sådant miljø, og gik derefter direkte i produktion. Det var meget nemt at forstå et sådant system; det tillod enhver programmør at implementere den kode, han havde skrevet, til enhver tid.
Men efterhånden som antallet af vores kunder voksede, voksede omfanget af den infrastruktur, der var nødvendig for at støtte projektet. Snart, givet systemets konstante vækst, gjorde vores implementeringsmodel, baseret på at skubbe ny kode til serverne, ikke længere sit job. Tilføjelse af hver ny server betød nemlig at øge den tid, der var nødvendig for at fuldføre implementeringen. Selv strategier baseret på parallel brug af rsync har visse begrænsninger.
Vi endte med at løse dette problem ved at flytte til et fuldstændig parallelt udrulningssystem, som var designet anderledes end det gamle system. Nu sendte vi nemlig ikke kode til serverne ved hjælp af et synkroniseringsscript. Nu downloadede hver server uafhængigt den nye samling, vel vidende at den skulle gøre det ved at overvåge Consul-nøgleændringen. Serverne indlæste koden parallelt. Dette gjorde det muligt for os at opretholde en høj implementeringshastighed selv i et miljø med konstant systemvækst.
1. Produktionsservere overvåger Consul-nøglen. 2. Nøglen ændres, dette fortæller serverne, at de skal begynde at downloade ny kode. 3. Servere downloader tarball-filer med applikationskode
▍ Atominstallationer
En anden løsning, der hjalp os med at nå et multi-tier implementeringssystem, var atomær implementering.
Før du bruger atom-implementeringer, kan hver implementering resultere i et stort antal fejlmeddelelser. Faktum er, at processen med at kopiere nye filer til produktionsservere ikke var atomisk. Dette resulterede i et kort tidsrum, hvor koden, der kaldte nye funktioner, var tilgængelig, før selve funktionerne var tilgængelige. Når en sådan kode blev kaldt, resulterede det i, at interne fejl blev returneret. Dette manifesterede sig i mislykkede API-anmodninger og ødelagte websider.
Holdet, der arbejdede på dette problem, løste det ved at introducere begrebet "varme" og "kolde" mapper. Koden i hot directory er ansvarlig for behandling af produktionstrafik. Og i "kolde" mapper bliver koden, mens systemet kører, kun klargjort til brug. Under installationen kopieres ny kode til en ubrugt kold mappe. Derefter, når der ikke er nogen aktive processer på serveren, udføres en øjeblikkelig mappeskift.
1. Udpakning af applikationskoden i en "kold" mappe. 2. Skift af systemet til en "kold" mappe, som bliver "varm" (atomisk drift)
Resultater: skift i vægt til pålidelighed
I 2018 voksede projektet til et sådant omfang, at meget hurtig implementering begyndte at skade produktets stabilitet. Vi havde et meget avanceret implementeringssystem, som vi investerede meget tid og kræfter i. Alt, hvad vi skulle gøre, var at genopbygge og forbedre vores implementeringsprocesser. Vi er vokset til en ret stor virksomhed, hvis udvikling er blevet brugt over hele verden til at organisere uafbrudt kommunikation og til at løse vigtige problemer. Derfor blev pålidelighed i fokus for vores opmærksomhed.
Vi var nødt til at gøre processen med at implementere nye Slack-udgivelser mere sikker. Dette behov fik os til at forbedre vores implementeringssystem. Faktisk diskuterede vi dette forbedrede system ovenfor. I dybet af systemet fortsætter vi med at bruge hurtige og atomare implementeringsteknologier. Den måde, implementeringen udføres på, har ændret sig. Vores nye system er designet til gradvist at implementere ny kode på forskellige niveauer i forskellige miljøer. Vi bruger nu mere avancerede supportværktøjer og systemovervågningsværktøjer end tidligere. Dette giver os mulighed for at fange og rette fejl, længe før de har en chance for at nå slutbrugeren.
Men vi vil ikke stoppe der. Vi forbedrer hele tiden dette system ved at bruge mere avancerede hjælpeværktøjer og arbejdsautomatiseringsværktøjer.
Kære læsere! Hvordan fungerer processen med at implementere nye projektudgivelser, hvor du arbejder?
Kilde: www.habr.com