Distributionsstrategier

DevOps-metoder omfattar frekventa lanseringscykler som gagnar organisationer och deras slutanvändare på många sätt. Eftersom enskilda distributioner är mindre är de snabbare och mindre stressiga, men saker kan fortfarande gå fel. För att minska risken för problem måste du anta en distributionsstrategi som bäst passar din organisations behov.

Du känner redan till metoden "episk distribution", som vissa kallar "big bang"-strategin. Du vet att den här metoden inte fungerar bra för moderna program. Det finns flera andra strategier som blivit populära vad gäller modern drift. Var och en av dessa har egna styrkor och svagheter beroende på situationen.

Strategi för rullande distribution

Den löpande distributionsstrategin tar en gradvis metod för att introducera nya versioner av kod. Den nya versionen fasas in under en viss tidsperiod och ökar gradvis instanserna av den nya koden samtidigt som instanserna av den gamla minskar. Därför samexisterar gamla och nya instanser över distributionsmålet under utrullningen. Du kan till exempel uppgradera programvaran på en server, virtuell dator eller container i taget.

En fördel med den här strategin är att du kan övervaka den nya koden i produktionsmiljön för att säkerställa att den uppfyller dina prestanda, säkerhet, tillförlitlighet och andra standarder innan den distribueras i stor utsträckning.

Strategi för blågrön distribution

Den blågröna distributionsstrategin använder två separata miljöer som hålls så lika som möjligt och som båda kan hantera produktionstrafik. Den ena miljön hanterar den aktuella produktionsbelastningen medan den andra är värd för den nya versionen av programvaran så att du kan verifiera den innan du flyttar trafik. När du är nöjd med att den nya versionen är felfri kan du växla trafik på en gång eller gradvis öka andelen trafik som går till den nya miljön medan du övervakar resultatet.

Den blå miljön är den som för närvarande hanterar produktionstrafik. Den gröna miljön är dess parallella motsvarighet. Du distribuerar först den nya versionen av programvaran till grön, validerar den och dirigerar sedan produktionstrafik från blått till grönt. Efter övergången kan rollerna växla: grön blir den aktiva miljön och blå kan förberedas för nästa version.

En fördel med den här strategin är att du kan växla snabbt, ofta med liten eller ingen stilleståndstid. Det är också relativt enkelt att dirigera trafik tillbaka till den tidigare miljön om ett problem uppstår efter att den nya miljön har gått igång.

Strategi för "canary"-utplacering

Strategin för kanariefågelutplacering kombinerar vissa delar av den rullande distributionen med den blågröna distributionens element. Du gör inte övergången på en gång, utan fasar istället in den nya versionen till en begränsad del av produktionsmiljön och överför sedan gradvis all trafik till den nya versionen. Programvaran distribueras i stegvisa steg till ett begränsat antal instanser eller användare tills du har verifierat att den fungerar korrekt och sedan distribueras till resten av infrastrukturen.

Namnet kommer från användningen av kanariefåglar i kolgruvor som ett tidigt varningssystem. I en kanariedistribution kan du utföra automatiserad testning och använda övervakning och analys för att få en tidig varning om eventuella problem med den nya versionen i delmängden av instanser eller användare. På så sätt påverkas inte hela produktionsmiljön.

Funktionsflaggor

Funktionsflaggans idé är en annan strategi som kräver lite mer sofistikering från utvecklarnas sida. I stället för att ha två separata versioner av samma programvara (en gammal och en ny med nya funktioner) skickar du en enda version som innehåller det gamla beteendet plus de nya ändringarna. De nya ändringarna är vilande som standard och visas inte förrän motsvarande "funktionsflagga" har aktiverats. En flagga kan ta många former, inklusive en rad i en konfigurationsfil, ett kommandoradsargument eller ett värde som hämtats från en fjärrkonfigurationstjänst och utvärderats vid körning.

En stor fördel med den här metoden är att det är enkelt att återställa om ett problem uppstår och hur enkelt det är att långsamt rulla ut ändringar. I många fall behöver du inte skicka en ny version för att exponera eller dölja funktionen. Du kan helt enkelt inaktivera eller aktivera lämplig flagga och låta det program som körs reagera på den nya inställningen.

På Azure tillhandahåller funktionen feature för Azure App Configuration en hanterad funktionsflagga som dina program kan läsa från vid körning, med SDK-stöd för .NET, Java, Python, JavaScript och Go.

Ringbaserade distributioner

En ringbaserad distribution är en strukturerad form av progressiv distribution som används i stor utsträckning inom Microsoft och Azure. Ny kod släpps till en sekvens med "ringar". Till exempel en intern ring eller hundmatsring, en tidig adopterring, en bred distributionsring och slutligen en allmän tillgänglighetsring. Varje ring är större än den föregående och distributionen går bara vidare till nästa ring efter hälsosignaler från den aktuella ringen uppfyller definierade kriterier. Ringbaserade distributioner kombinerar den gradvisa exponeringen av kanariedistributioner med explicita, namngivna målgrupper och godkännandegrindar mellan ringar.

Progressiv leverans

Strategierna ovan (kanarieflaggor, ringbaserade flaggor och funktionsflaggor) grupperas ofta under paraplytermen progressiv leverans. Den enande idén är att en utgåva exponeras för en kontrollerad, växande publik, försedd med hälso- och affärsmetrik, och antingen utvecklas vidare eller återställs automatiskt baserat på dessa indikatorer. Progressiv leverans är i allt högre grad standardmodellen för molntjänster med hög tillförlitlighet eftersom den begränsar explosionsradien för varje enskild ändring.

Bästa metoder för distribution

Oavsett vilken distributionsstrategi du använder hjälper vissa metodtips dig att minimera risken när du distribuerar ny programvara eller en ny version av befintlig programvara:

• Använd rätt verktyg, till exempel Azure-pipelines eller GitHub Actions, för att skapa en pipeline för kontinuerlig integrering och distribution.

• Integrera automatiserad testning.

• Använd kommunikationskanaler för att meddela rätt parter om testresultat. Till exempel, informera team när distributioner misslyckas eller stöter på problem.

• Övervaka problem omedelbart efter distributionen.

• Ha en plan för att återställa om en ny version inte klarar hälsokontroller eller fungerar korrekt.