Het in productie brengen van een nieuwe projectrelease vereist een zorgvuldige balans tussen implementatiesnelheid en betrouwbaarheid van de oplossing. Slack waardeert snelle iteraties, korte feedbackcycli en snelle reactie op gebruikersverzoeken. Daarnaast heeft het bedrijf honderden programmeurs die ernaar streven zo productief mogelijk te zijn.
De auteurs van het materiaal, waarvan we de vertaling vandaag publiceren, zeggen dat een bedrijf dat ernaar streeft dergelijke waarden na te leven en tegelijkertijd groeit, zijn projectimplementatiesysteem voortdurend moet verbeteren. Het bedrijf moet investeren in transparantie en betrouwbaarheid van werkprocessen, om ervoor te zorgen dat deze processen overeenkomen met de schaal van het project. Hier zullen we het hebben over de workflows die zich in Slack hebben ontwikkeld, en over enkele beslissingen die ertoe hebben geleid dat het bedrijf het huidige projectimplementatiesysteem heeft gebruikt.
Hoe projectimplementatieprocessen vandaag de dag werken
Elke PR (pull request) in Slack moet worden onderworpen aan een codebeoordeling en moet alle tests met succes doorstaan. Pas nadat aan deze voorwaarden is voldaan, kan de programmeur zijn code samenvoegen in de masterbranch van het project. Deze code wordt echter alleen tijdens kantooruren, Noord-Amerikaanse tijd, geïmplementeerd. Hierdoor zijn wij, doordat onze medewerkers op hun werkplek zijn, volledig voorbereid om eventuele onverwachte problemen op te lossen.
Dagelijks voeren wij ongeveer 12 geplande inzet uit. Tijdens elke implementatie is de programmeur die is aangewezen als implementatieleider verantwoordelijk voor het in productie brengen van de nieuwe build. Dit is een proces dat uit meerdere stappen bestaat en ervoor zorgt dat de assemblage soepel in productie wordt gebracht. Dankzij deze aanpak kunnen we fouten opsporen voordat ze al onze gebruikers beïnvloeden. Als er te veel fouten zijn, kan de inzet van de assemblage worden teruggedraaid. Als er na de release een specifiek probleem wordt ontdekt, kan er eenvoudig een oplossing voor worden vrijgegeven.
Interface van het Checkpoint-systeem, dat in Slack wordt gebruikt om projecten uit te rollen
Het proces van het implementeren van een nieuwe release naar productie kan worden gezien als bestaande uit vier stappen.
▍1. Een releasebranch maken
Elke release begint met een nieuwe release branch, een punt in onze Git-geschiedenis. Hierdoor kunt u tags aan de release toewijzen en kunt u live reparaties uitvoeren voor bugs die zijn aangetroffen tijdens het voorbereiden van de release voor release voor productie.
▍2. Implementatie in een staging-omgeving
De volgende stap is het implementeren van de assembly op staging-servers en het uitvoeren van een automatische test voor de algehele prestaties van het project (rooktest). De stagingomgeving is een productieomgeving die geen extern verkeer ontvangt. In deze omgeving voeren we aanvullende handmatige tests uit. Dit geeft ons extra vertrouwen dat het aangepaste project correct werkt. Geautomatiseerde tests alleen zijn niet voldoende om dit niveau van vertrouwen te bieden.
▍3. Inzet in dogfood- en kanarieomgevingen
Implementatie naar productie begint met een dogfood-omgeving, vertegenwoordigd door een reeks hosts die onze interne Slack-werkruimten bedienen. Omdat we zeer actieve Slack-gebruikers zijn, heeft deze aanpak ons geholpen om veel bugs vroeg in de implementatie op te sporen. Nadat we er zeker van zijn dat de basisfunctionaliteit van het systeem niet wordt verbroken, wordt de assemblage ingezet in de kanarieomgeving. Het vertegenwoordigt systemen die ongeveer 2% van het productieverkeer voor hun rekening nemen.
▍4. Geleidelijke vrijgave voor productie
Als de monitoringindicatoren voor de nieuwe release stabiel blijken te zijn, en als we na de implementatie van het project in de canarische omgeving geen klachten hebben ontvangen, gaan we door met het geleidelijk overbrengen van de productieservers naar de nieuwe release. Het implementatieproces is verdeeld in de volgende fasen: 10%, 25%, 50%, 75% en 100%. Hierdoor kunnen we het productieverkeer langzaam overzetten naar de nieuwe release van het systeem. Tegelijkertijd hebben we de tijd om de situatie te onderzoeken als er afwijkingen worden ontdekt.
▍Wat als er iets misgaat tijdens de implementatie?
Het aanbrengen van wijzigingen in de code is altijd een risico. Maar we kunnen dit aan dankzij de aanwezigheid van goed opgeleide ‘implementatieleiders’ die het proces van het in productie brengen van een nieuwe release beheren, monitoringindicatoren monitoren en het werk van programmeurs die code vrijgeven, coördineren.
Mocht er echt iets misgaan, dan proberen wij het probleem zo vroeg mogelijk op te sporen. We onderzoeken het probleem, vinden de PR die de fouten veroorzaakt, draaien het terug, analyseren het grondig en maken een nieuwe build. Het is waar dat het probleem soms onopgemerkt blijft totdat het project in productie gaat. In een dergelijke situatie is het belangrijkste om de service te herstellen. Voordat we het probleem gaan onderzoeken, gaan we daarom onmiddellijk terug naar de vorige werkende build.
Bouwstenen van een implementatiesysteem
Laten we eens kijken naar de technologieën die ten grondslag liggen aan ons projectimplementatiesysteem.
▍Snelle implementaties
De hierboven beschreven workflow lijkt achteraf gezien misschien enigszins voor de hand liggend. Maar ons implementatiesysteem werd niet meteen zo.
Toen het bedrijf nog veel kleiner was, kon onze hele applicatie op 10 Amazon EC2-instances draaien. Het implementeren van het project in deze situatie betekende het gebruik van rsync om snel alle servers te synchroniseren. Voorheen was nieuwe code slechts één stap verwijderd van de productie, vertegenwoordigd door een testomgeving. In een dergelijke omgeving werden assemblages gemaakt, getest en vervolgens direct in productie genomen. Het was heel gemakkelijk om zo'n systeem te begrijpen; het stelde elke programmeur in staat de code die hij had geschreven op elk moment in te zetten.
Maar naarmate het aantal van onze klanten groeide, groeide ook de schaal van de infrastructuur die nodig was om het project te ondersteunen. Gezien de constante groei van het systeem deed ons implementatiemodel, gebaseerd op het pushen van nieuwe code naar de servers, al snel zijn werk niet meer. Het toevoegen van elke nieuwe server betekende namelijk dat de tijd die nodig was om de implementatie te voltooien, langer werd. Zelfs strategieën die gebaseerd zijn op parallel gebruik van rsync hebben bepaalde beperkingen.
Uiteindelijk hebben we dit probleem opgelost door over te stappen op een volledig parallel implementatiesysteem, dat anders was ontworpen dan het oude systeem. We hebben nu namelijk geen code naar de servers gestuurd met behulp van een synchronisatiescript. Nu downloadde elke server onafhankelijk de nieuwe assembly, wetende dat dit nodig was door de wijziging van de Consul-sleutel te monitoren. De servers laadden de code parallel. Hierdoor konden we een hoge implementatiesnelheid handhaven, zelfs in een omgeving met constante systeemgroei.
1. Productieservers bewaken de Consul-sleutel. 2. De belangrijkste wijzigingen, dit vertelt de servers dat ze nieuwe code moeten downloaden. 3. Servers downloaden tarball-bestanden met applicatiecode
▍Atomische implementaties
Een andere oplossing die ons heeft geholpen een implementatiesysteem met meerdere lagen te bereiken, was atomaire implementatie.
Voordat atomaire implementaties werden gebruikt, kon elke implementatie resulteren in een groot aantal foutmeldingen. Feit is dat het proces van het kopiëren van nieuwe bestanden naar productieservers niet atomair was. Dit resulteerde in een kort tijdsbestek waarin de code die nieuwe functies aanriep beschikbaar was voordat de functies zelf beschikbaar waren. Wanneer een dergelijke code werd aangeroepen, resulteerde dit in het retourneren van interne fouten. Dit uitte zich in mislukte API-verzoeken en kapotte webpagina's.
Het team dat aan dit probleem werkte, loste het op door het concept van “hot” en “cold” directory’s te introduceren. De code in de hot directory is verantwoordelijk voor het verwerken van productieverkeer. En in “koude” mappen wordt de code, terwijl het systeem draait, alleen voorbereid voor gebruik. Tijdens de implementatie wordt nieuwe code gekopieerd naar een ongebruikte koude directory. Als er vervolgens geen actieve processen op de server zijn, wordt er onmiddellijk van directory gewisseld.
1. De applicatiecode uitpakken in een “koude” directory. 2. Het systeem naar een “koude” directory schakelen, die “hot” wordt (atomaire werking)
Resultaten: accentverschuiving naar betrouwbaarheid
In 2018 groeide het project zo groot dat een zeer snelle implementatie de stabiliteit van het product begon te schaden. We hadden een zeer geavanceerd implementatiesysteem waarin we veel tijd en moeite hadden geïnvesteerd. Het enige wat we moesten doen was onze implementatieprocessen opnieuw opbouwen en verbeteren. We zijn uitgegroeid tot een vrij groot bedrijf, waarvan de ontwikkelingen over de hele wereld zijn gebruikt om ononderbroken communicatie te organiseren en belangrijke problemen op te lossen. Daarom werd betrouwbaarheid het middelpunt van onze aandacht.
We moesten het proces van het implementeren van nieuwe Slack-releases veiliger maken. Deze behoefte heeft ertoe geleid dat we ons implementatiesysteem hebben verbeterd. In feite hebben we dit verbeterde systeem hierboven besproken. In de diepten van het systeem blijven we snelle en atomaire implementatietechnologieën gebruiken. De manier waarop implementatie plaatsvindt, is veranderd. Ons nieuwe systeem is ontworpen om geleidelijk nieuwe code op verschillende niveaus en in verschillende omgevingen te implementeren. We gebruiken nu geavanceerdere ondersteuningstools en systeemmonitoringtools dan voorheen. Dit geeft ons de mogelijkheid om fouten op te sporen en op te lossen lang voordat ze de kans krijgen de eindgebruiker te bereiken.
Maar daar zullen we niet bij blijven. We verbeteren dit systeem voortdurend, met behulp van geavanceerdere hulptools en werkautomatiseringstools.
Beste lezers! Hoe werkt het proces van het implementeren van nieuwe projectreleases waar u werkt?
Bron: www.habr.com