Att ta en ny projektversion i produktion kräver en noggrann balans mellan distributionshastighet och lösningens tillförlitlighet. Slack värden snabba iterationer, korta återkopplingscykler och snabba svar på användarförfrågningar. Dessutom har företaget hundratals programmerare som strävar efter att vara så produktiva som möjligt.
Författarna till materialet, vars översättning vi publicerar idag, säger att ett företag som strävar efter att hålla fast vid sådana värderingar och samtidigt växer måste ständigt förbättra sitt system för att implementera projekt. Företaget behöver investera i transparens och tillförlitlighet i arbetsprocesser, vilket gör detta för att säkerställa att dessa processer motsvarar projektets omfattning. Här kommer vi att prata om de arbetsflöden som har utvecklats i Slack, och om några av de beslut som ledde till att företaget använde det projektinstallationssystem som finns idag.
Hur processer för projektimplementering fungerar idag
Varje PR (pull request) i Slack måste vara föremål för kodgranskning och måste klara alla tester. Först efter att dessa villkor är uppfyllda kan programmeraren slå samman sin kod i huvudgrenen av projektet. Den här koden distribueras dock endast under kontorstid, nordamerikansk tid. Som ett resultat av det, på grund av att våra anställda är på sina arbetsplatser, är vi fullt beredda att lösa eventuella oväntade problem.
Varje dag genomför vi cirka 12 planerade insatser. Under varje distribution är programmeraren som utsetts som distributionsledare ansvarig för att få den nya byggnaden i produktion. Detta är en flerstegsprocess som säkerställer att monteringen tas i produktion smidigt. Tack vare detta tillvägagångssätt kan vi upptäcka fel innan de påverkar alla våra användare. Om det finns för många fel kan driftsättningen av enheten rullas tillbaka. Om ett specifikt problem upptäcks efter release kan en fix lätt släppas för det.
Gränssnitt för Checkpoint-systemet, som används i Slack för att distribuera projekt
Processen att distribuera en ny version till produktion kan ses som att den består av fyra steg.
▍1. Skapa en utgivningsgren
Varje release börjar med en ny releasegren, en punkt i vår Git-historik. Detta gör att du kan tilldela taggar till releasen och ger en plats där du kan göra livefixar för buggar som hittas i processen att förbereda releasen för release till produktion.
▍2. Implementering i en iscensättningsmiljö
Nästa steg är att distribuera sammansättningen på staging-servrar och köra ett automatiskt test för projektets övergripande prestanda (röktest). Staging-miljön är en produktionsmiljö som inte tar emot extern trafik. I denna miljö utför vi ytterligare manuella tester. Detta ger oss ytterligare förtroende för att det modifierade projektet fungerar korrekt. Enbart automatiserade tester räcker inte för att ge denna nivå av förtroende.
▍3. Utplacering i dogfood- och kanariefågelmiljöer
Implementering till produktion börjar med en dogfood-miljö, representerad av en uppsättning värdar som betjänar våra interna Slack-arbetsytor. Eftersom vi är mycket aktiva Slack-användare, hjälpte det här tillvägagångssättet oss att fånga många buggar tidigt i implementeringen. Efter att vi har försäkrat oss om att systemets grundläggande funktionalitet inte är trasig, utplaceras monteringen i kanariefågelmiljön. Det representerar system som står för cirka 2 % av produktionstrafiken.
▍4. Gradvis släpp till produktion
Om övervakningsindikatorerna för den nya utgåvan visar sig vara stabila och om vi efter att ha distribuerat projektet i kanariefågelmiljön inte har fått några klagomål, fortsätter vi att gradvis överföra produktionsservrarna till den nya utgåvan. Implementeringsprocessen är uppdelad i följande steg: 10 %, 25 %, 50 %, 75 % och 100 %. Som ett resultat kan vi långsamt överföra produktionstrafik till den nya versionen av systemet. Samtidigt har vi tid att utreda situationen om några avvikelser upptäcks.
▍Vad händer om något går fel under driftsättningen?
Att göra ändringar i koden är alltid en risk. Men vi klarar detta tack vare närvaron av välutbildade "distributionsledare" som hanterar processen att ta en ny version i produktion, övervakar övervakningsindikatorer och koordinerar arbetet med programmerare som släpper kod.
I händelse av att något verkligen går fel försöker vi upptäcka problemet så tidigt som möjligt. Vi undersöker problemet, hittar PR som orsakar felen, rullar tillbaka det, analyserar det grundligt och skapar ett nytt bygge. Det är sant, ibland går problemet obemärkt förbi tills projektet går i produktion. I en sådan situation är det viktigaste att återställa tjänsten. Därför, innan vi börjar undersöka problemet, återgår vi omedelbart till den tidigare fungerande versionen.
Byggstenar i ett distributionssystem
Låt oss titta på de teknologier som ligger till grund för vårt projektdistributionssystem.
▍Snabb driftsättning
Arbetsflödet som beskrivs ovan kan i efterhand tyckas något självklart. Men vårt distributionssystem blev inte så här direkt.
När företaget var mycket mindre kunde hela vår applikation köras på 10 Amazon EC2-instanser. Att distribuera projektet i den här situationen innebar att man använde rsync för att snabbt synkronisera alla servrar. Tidigare var ny kod bara ett steg bort från produktionen, representerad av en iscensättningsmiljö. Sammansättningar skapades och testades i en sådan miljö och gick sedan direkt till produktion. Det var väldigt lätt att förstå ett sådant system, det gjorde det möjligt för alla programmerare att distribuera koden han hade skrivit när som helst.
Men i takt med att antalet kunder växte, ökade också omfattningen av den infrastruktur som krävdes för att stödja projektet. Snart, med tanke på den ständiga tillväxten av systemet, gjorde vår implementeringsmodell, baserad på att skicka ny kod till servrarna, inte längre sitt jobb. Att lägga till varje ny server innebar nämligen att den tid som krävs för att slutföra distributionen ökade. Även strategier baserade på parallell användning av rsync har vissa begränsningar.
Det slutade med att vi löste detta problem genom att gå över till ett helt parallellt distributionssystem, som var utformat annorlunda än det gamla systemet. Nu skickade vi nämligen inte kod till servrarna med hjälp av ett synkroniseringsskript. Nu laddade varje server självständigt ner den nya sammansättningen, med vetskapen om att den behövde göra det genom att övervaka Consul-nyckeländringen. Servrarna laddade koden parallellt. Detta gjorde det möjligt för oss att upprätthålla en hög utbyggnadshastighet även i en miljö med konstant systemtillväxt.
1. Produktionsservrar övervakar Consul-nyckeln. 2. Nyckeln ändras, detta talar om för servrarna att de måste börja ladda ner ny kod. 3. Servrar laddar ner tarball-filer med applikationskod
▍Atominstallationer
En annan lösning som hjälpte oss att nå ett multi-tier-distributionssystem var atomär utbyggnad.
Innan du använder atominstallationer kan varje distribution resultera i ett stort antal felmeddelanden. Faktum är att processen att kopiera nya filer till produktionsservrar inte var atomär. Detta resulterade i ett kort tidsfönster där koden som anropade nya funktioner var tillgänglig innan själva funktionerna var tillgängliga. När en sådan kod anropades resulterade det i att interna fel returnerades. Detta manifesterade sig i misslyckade API-förfrågningar och trasiga webbsidor.
Teamet som arbetade med det här problemet löste det genom att introducera konceptet "heta" och "kalla" kataloger. Koden i hot directory är ansvarig för bearbetning av produktionstrafik. Och i "kalla" kataloger förbereds koden, medan systemet körs, bara för användning. Under distributionen kopieras ny kod till en oanvänd kall katalog. Sedan, när det inte finns några aktiva processer på servern, utförs en omedelbar katalogväxling.
1. Packa upp applikationskoden i en "kall" katalog. 2. Växla systemet till en "kall" katalog, som blir "het" (atomär drift)
Resultat: förskjutning av tyngdpunkten till tillförlitlighet
Under 2018 växte projektet till en sådan omfattning att mycket snabb implementering började skada produktens stabilitet. Vi hade ett mycket avancerat distributionssystem som vi investerade mycket tid och kraft i. Allt vi behövde göra var att bygga om och förbättra våra distributionsprocesser. Vi har vuxit till ett ganska stort företag, vars utveckling har använts över hela världen för att organisera oavbruten kommunikation och för att lösa viktiga problem. Därför blev tillförlitlighet i fokus för vår uppmärksamhet.
Vi behövde göra processen med att distribuera nya Slack-utgåvor säkrare. Detta behov ledde till att vi förbättrade vårt distributionssystem. Faktum är att vi diskuterade detta förbättrade system ovan. I djupet av systemet fortsätter vi att använda snabba och atomära utbyggnadstekniker. Sättet som distributionen görs har förändrats. Vårt nya system är designat för att gradvis distribuera ny kod på olika nivåer, i olika miljöer. Vi använder nu mer avancerade supportverktyg och systemövervakningsverktyg än tidigare. Detta ger oss möjligheten att fånga upp och åtgärda fel långt innan de har en chans att nå slutanvändaren.
Men vi tänker inte sluta där. Vi förbättrar ständigt detta system genom att använda mer avancerade hjälpverktyg och verktyg för arbetsautomatisering.
Kära läsare! Hur fungerar processen med att distribuera nya projektreleaser där du arbetar?
Källa: will.com