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 in de loop van de tijd gefaseerd ingevoerd, waarbij de gevallen van de nieuwe code geleidelijk worden verhoogd terwijl de gevallen van de oude code afnemen. Als gevolg hiervan bestaan oude en nieuwe instanties binnen het implementatiedoel tijdens de uitrol. U kunt bijvoorbeeld de software op één server, virtuele machine of container tegelijk upgraden.

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 blauwgroene implementatiestrategie maakt gebruik van twee afzonderlijke omgevingen die zo vergelijkbaar mogelijk worden gehouden en die beide geschikt zijn voor productieverkeer. De ene omgeving verwerkt de huidige productiebelasting terwijl de andere als host fungeert voor de nieuwe versie van de software, zodat u deze kunt valideren voordat u verkeer verplaatst. Wanneer u ervan overtuigd bent dat de nieuwe versie stabiel functioneert, kunt u al het verkeer in één keer omleiden of het aandeel van het verkeer naar de nieuwe omgeving geleidelijk verhogen terwijl u de resultaten in de gaten houdt.

De blauwe omgeving is de omgeving die momenteel productieverkeer bedient. De groene omgeving is zijn parallelle tegenhanger. U implementeert eerst de nieuwe versie van de software in groen, valideert deze en routeert vervolgens productieverkeer van blauw naar groen. Na de overgang kunnen de rollen veranderen: groen wordt de liveomgeving en blauw kan worden voorbereid op de volgende release.

Een voordeel van deze strategie is dat u snel kunt schakelen, vaak met weinig of geen downtime. Het is ook relatief eenvoudig om verkeer terug te sturen naar de vorige omgeving als er een probleem optreedt nadat de nieuwe omgeving live gaat.

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 (een oude en een nieuwe met nieuwe functies) te hebben, verzendt u één versie met het oude gedrag plus de nieuwe wijzigingen. De nieuwe wijzigingen zijn standaard inactief en zijn pas zichtbaar als de bijbehorende functievlag is geactiveerd. Een vlag kan veel vormen aannemen, waaronder een regel in een configuratiebestand, een opdrachtregelargument of een waarde die is opgehaald uit een externe configuratieservice en die tijdens runtime wordt geëvalueerd.

Een sterk voordeel van deze benadering is het gemak om terug te draaien als er een probleem optreedt en het gemak van het langzaam implementeren van wijzigingen. In veel gevallen hoeft u geen nieuwe release te verzenden om de functie beschikbaar te maken of te verbergen. U kunt gewoon de juiste vlag in- of uitschakelen en de actieve toepassing laten reageren op de nieuwe instelling.

Op Azure biedt de feature management-mogelijkheid van Azure App Configuration een beheerde feature-flag store die uw applicaties tijdens runtime kunnen lezen, met SDK-ondersteuning voor .NET, Java, Python, JavaScript en Go.

Implementaties op basis van ring

Een ringimplementatie is een gestructureerde vorm van progressieve implementatie die veel wordt gebruikt binnen Microsoft en Azure. Nieuwe code wordt vrijgegeven voor een reeks 'ringen'. Bijvoorbeeld een interne ring of dogfoodring, een vroege adopterring, een brede implementatiering en ten slotte een algemene beschikbaarheidsring. Elke ring is groter dan de vorige ring en de implementatie gaat alleen naar de volgende ring nadat de statussignalen van de huidige ring voldoen aan gedefinieerde criteria. Ringimplementaties combineren de geleidelijke blootstelling van canary-implementaties met expliciete, benoemde doelgroepen en goedkeuringspoorten tussen ringen.

Progressieve levering

De bovenstaande strategieën (kanarie, ringgebaseerd en functievlaggetjes) worden vaak gegroepeerd onder de overkoepelende term progressieve levering. Het centrale idee is dat een release wordt blootgesteld aan een gecontroleerde, groeiende doelgroep, uitgerust met gezondheids- en bedrijfsstatistieken, en automatisch wordt voortgezet of teruggedraaid op basis van deze signalen. Progressieve levering is steeds meer het standaardmodel voor cloudservices met hoge betrouwbaarheid, omdat hiermee de straal van elke afzonderlijke wijziging wordt beperkt.

Best practices voor implementatie

Ongeacht welke implementatiestrategie u gebruikt, helpen sommige aanbevolen procedures u bij het minimaliseren van risico's bij het implementeren van nieuwe software of een nieuwe versie van bestaande software:

• Gebruik de juiste hulpprogramma's, zoals Azure-pipelines of GitHub Actions, om een pijplijn voor continue integratie en implementatie te maken.

• Automatisch testen integreren.

• Gebruik communicatiekanalen om de juiste partijen op de hoogte te stellen van testresultaten. Waarschuw teams bijvoorbeeld wanneer implementaties mislukken of problemen ondervinden.

• Direct na de implementatie controleren op problemen.

• Een plan hebben om terug te draaien als een nieuwe versie geen statuscontroles doorstaat of niet goed werkt.