Implementatiestrategieën
DevOps-procedures omvatten veelvuldige releasecycli die organisaties en hun eindgebruikers op verschillende manieren voordelen bieden. Omdat afzonderlijke implementaties kleiner zijn, zijn ze sneller en minder stressvol, maar kunnen er nog steeds dingen misgaan. Als u de kans op problemen wilt verminderen, moet u een implementatiestrategie aannemen die het beste past bij de behoeften van uw organisatie.
U weet al over de 'epische implementatie'-benadering, die sommigen de 'big bang'-strategie noemen. U weet dat deze methode niet goed werkt voor moderne toepassingen. Er is een aantal andere implementatiestrategieën die populair zijn geworden in de context van moderne Ops, waarvan elk sterke en zwakke punten heeft, afhankelijk van de situatie.
Doorlopende implementatiestrategie
De implementatiestrategie voor rollend gebruik maakt geleidelijk gebruik van de introductie van nieuwe versies van code. De nieuwe versie wordt gedurende een bepaalde periode gefaseerd geïntroduceerd, waardoor de instanties van de nieuwe code geleidelijk toenemen, terwijl die van de oude code afnemen. Dit betekent dat de oude en nieuwe instanties naast elkaar zullen bestaan binnen de organisatie. U kunt bijvoorbeeld de software op één server, virtuele machine of container tegelijk bijwerken.
Een voordeel van deze strategie is dat u de nieuwe code in de productieomgeving kunt bewaken om ervoor te zorgen dat deze voldoet aan uw prestaties, beveiliging, betrouwbaarheid en andere standaarden voordat deze op grote schaal wordt geïmplementeerd.
Blauw-groene implementatiestrategie
De blauw-groene implementatiestrategie maakt gebruik van twee afzonderlijke omgevingen die identiek zijn aan elkaar. Een is een testomgeving met de nieuwe versie van de software, de andere is de huidige productieomgeving. Wanneer u tevreden bent dat de software goed werkt en aan uw standaarden voldoet, kunt u een volledige switch uitvoeren van de huidige productieomgeving naar de nieuwe, zodat deze nu al het productieverkeer verwerkt.
De blauwe omgeving is uw huidige productieomgeving. De groene omgeving is een exacte kopie. U implementeert eerst de nieuwe versie van de software in de groene omgeving en vervolgens wanneer u klaar bent, routeert u het toepassingsverkeer van de blauwe omgeving naar het groen, dat nu uw productieomgeving is.
Een voordeel van deze strategie is dat u de switch vrijwel onmiddellijk kunt omzetten, zonder uitvaltijd. Het is ook eenvoudig om terug te schakelen naar blauw als er een probleem optreedt nadat u de groene omgeving live hebt gemaakt.
Canary-implementatiestrategie
In de canary-implementatiestrategie wordt een aantal elementen van de doorlopende implementatie gecombineerd met die van de blauw-groene implementatie. U maakt de overstap niet allemaal tegelijk, maar implementeert in plaats daarvan de nieuwe versie in een beperkt deel van de productieomgeving en verschuift vervolgens geleidelijk al het verkeer naar de nieuwe versie. De software wordt in incrementele stappen geïmplementeerd voor een beperkt aantal exemplaren of gebruikers totdat u hebt gecontroleerd of deze goed werkt en wordt vervolgens geïmplementeerd in de rest van de infrastructuur.
De naam is afkomstig uit de kolenmijnbouw, waar kanaries werden gebruikt als waarschuwingssysteem. In een canary-implementatie kunt u geautomatiseerd testen en bewaking en analyse gebruiken om een vroege waarschuwing te krijgen van eventuele problemen met de nieuwe versie binnen de subset van exemplaren of gebruikers. Op die manier wordt de volledige productieomgeving niet beïnvloed.
Functievlaggen
Het idee van de functievlag is een andere strategie die iets meer verfijning vereist voor het gedeelte van de ontwikkelaars. In plaats van twee afzonderlijke versies van dezelfde software te gebruiken, een oude en een nieuwe versie (met waarschijnlijk nieuwe functies), verzenden we de software die zowel de oude als de nieuwe software bevat, plus de nieuwe wijzigingen (functies, enzovoort). De nieuwe wijzigingen zijn standaard actief en niet zichtbaar totdat de functievlag voor die wijziging wordt geactiveerd door de vlag te spiegelen. Deze vlag kan vele vormen aannemen, waaronder een regel in een configuratiebestand, een opdrachtregelargument, een speciale reactie van een onlineserver die de software raadpleegt bij het opstarten, enzovoort.
Een sterk pluspunt voor deze aanpak is het gemak waarmee we kunnen terugdraaien als er een probleem is, of het gemak bij het langzaam implementeren van wijzigingen. U hoeft geen nieuwe release (met alle bits) te verzenden naar uw servers of klanten. U hoeft hoeven alleen de juiste vlag in of uit te schakelen om de release te downgraden of upgraden.
Aanbevolen best practices voor implementatie
Ongeacht de implementatiestrategie die u gebruikt, zijn er enkele best practices waarmee u het risico kunt minimaliseren bij het implementeren van nieuwe software of een nieuwe versie van bestaande software:
Gebruik de juiste hulpprogramma's, zoals Azure Pipelines, om een continue integratie- en implementatiepijplijn te maken.
Automatisch testen integreren.
Gebruik communicatiekanalen om de juiste partijen op de hoogte te stellen van de resultaten van de test; Dat wil gezegd, waarschuw teams als implementaties mislukken, problemen ondervinden, enzovoort.
Direct na de implementatie controleren op problemen.
Zorg ervoor dat u een plan hebt om terug te draaien als een nieuwe versie-implementatie geen statuscontroles doorgeeft of goed werkt.