Procesbeschrijving Develop, Deploy & Release

In dit hoofdstuk is beschreven:

In een DevOps-omgeving zijn er verschillende soorten releaseprocessen die elk hun eigen specifieke doelen en toepassingen hebben. Deze processen zijn essentieel voor het waarborgen van de kwaliteit en betrouwbaarheid van softwareleveringen en stellen teams in staat om snel te reageren op veranderende omstandigheden en eisen. Voor een succesvolle deployment naar de productieomgeving (Prod) is het belangrijk om bij iedere release een grondige code check uit te voeren. Dit omvat verschillende cruciale stappen:

• Logging: Het is van groot belang dat alle logbestanden correct worden bijgehouden. Logging helpt bij het monitoren van de prestaties van de applicatie en het identificeren van eventuele problemen die zich tijdens de deployment kunnen voordoen. Door gedetailleerde logbestanden bij te houden, kunnen ontwikkelaars snel reageren op fouten en de oorzaak van problemen achterhalen.
• Property Decryption & Deployment: Controleer of alle eigenschappen correct worden ontsleuteld en gedeployed. Dit is essentieel voor de beveiliging en correcte werking van de applicatie. Eigenschappen kunnen gevoelige informatie bevatten, zoals wachtwoorden en API-sleutels, die veilig moeten worden behandeld en correct moeten worden toegepast tijdens de deployment.
• Gestandaardiseerde ASV (Aansluitvoorwaarden): Zorg ervoor dat de Aansluitvoorwaarden (ASV) worden nageleefd. Deze voorwaarden worden middels code afgedwongen om ervoor te zorgen dat de applicatie voldoet aan de gestelde eisen en normen. Het naleven van de ASV helpt bij het waarborgen van de kwaliteit en consistentie van de software.

Quality gates

Deze paragraaf beschrijft de stappen die door verschillende teams worden uitgevoerd om een API te ontwikkelen, te testen en succesvol te implementeren op een productieomgeving. Het bestaat uit verschillende fasen, onderverdeeld over drie hoofdgroepen: de Klant, Team Blue, en het Platform Team. Elk team speelt een specifieke rol in de cyclus, met kwaliteitscontroles (Quality Gates) om ervoor te zorgen dat de API aan de vereiste normen voldoet voordat deze verder kan worden doorgevoerd.
Customer (Klant)
De cyclus begint bij de klant, die een applicatie bouwt die gebruik zal maken van de API. Deze stap is de trigger voor de rest van het ontwikkelproces. Nadat de applicatie-eisen zijn gedefinieerd, start Team Blue met de ontwikkeling van de API.
Team Blue: Ontwikkeling en Testimplementatie
Team Blue is verantwoordelijk voor het ontwerpen, ontwikkelen en testen van de API voordat deze naar acceptatie en productie gaat. Dit team doorloopt meerdere stappen en kwaliteitscontroles.
Platform Team: Implementatie op Productie
Nadat de API is goedgekeurd door het acceptatieteam, neemt het Platform Team het over om de API op de productieomgeving te implementeren. Ook hier vinden kwaliteitscontroles plaats om ervoor te zorgen dat alles vlekkeloos verloopt.
Het beschreven proces is ontworpen om de kwaliteit van de API gedurende het hele traject te waarborgen, van ontwikkeling tot productie. Door gebruik te maken van meerdere kwaliteitscontroles en beslismomenten worden mogelijke fouten vroegtijdig opgespoord en opgelost. Dit vermindert het risico op problemen in de productieomgeving en zorgt voor een stabiele, veilige en goed functionerende API voor eindgebruikers.

Figuur 2: Proces model voor API development en deployment
Hieronder volgt een uitgebreide uitleg van het API-ontwikkelings- en implementatieproces zoals weergegeven in het diagram.

Stap 1: Develop API

In deze stap ontwikkelt het team de API op basis van de functionele en technische vereisten.
Na de initiële ontwikkeling gaat de API door de eerste kwaliteitscontrole, Quality Gate 1.

Quality Gate 1: Peer Review, Unit Test, ASW Checks

Peer Review: Collega's binnen het team beoordelen de ontwikkelde API-code om fouten en verbeterpunten te identificeren.
Unit Test: De API wordt onderworpen aan unit-tests om te controleren of afzonderlijke onderdelen correct werken.
ASW Checks: Er worden geautomatiseerde kwaliteitscontroles uitgevoerd om te controleren op veiligheids- en codeerstandaarden.
Beslismoment (OK?):

• Ja: Als de API slaagt voor deze tests, gaat het proces verder naar de volgende stap: Create Pipeline.
• Nee: Als er fouten worden gevonden, keert het team terug naar de ontwikkelfase om deze te corrigeren.

Stap 2: Create Pipeline

Hier wordt een CI/CD-pipeline (Continuous Integration/Continuous Deployment) opgezet. Deze pipeline automatiseert de processen van het bouwen, testen en implementeren van de API.

Stap 3: Deploy on Test

De API wordt geïmplementeerd op een testomgeving. Hier worden verdere integratietests uitgevoerd in een gesimuleerde omgeving.

Quality Gate 2: Integration Test (Integratietest)

In deze kwaliteitscontrole wordt getest of de API correct samenwerkt met andere systemen en onderdelen.
Beslismoment (OK?):

• Ja: Als de API slaagt voor de integratietests, gaat het proces verder met implementatie op de acceptatieomgeving.
• Nee: Bij falen wordt de API opnieuw aangepast en getest.

Stap 4: Deploy on Acceptance

De API wordt geïmplementeerd op de acceptatieomgeving, waar meer geavanceerde tests worden uitgevoerd.

Quality Gate 3: Acceptance Test (Acceptatietest)

Hier wordt gecontroleerd of de API voldoet aan de eisen en verwachtingen van de klant.
Beslismoment (OK?):

• Ja: Als de API is goedgekeurd, wordt de implementatie op productie gepland.
• Nee: Als de API faalt, wordt deze opnieuw aangepast en getest.

Quality Gate 4: Final Check

Het Platform Team voert een laatste controle uit op de API. Dit omvat een definitieve check op codekwaliteit, beveiliging en stabiliteit.
Beslismoment (OK?):

• Ja: De API mag worden geïmplementeerd op de productieomgeving.
• Nee: Bij problemen keert de API terug naar een eerdere stap voor aanpassing.

Stap 5: Deploy on Production

De API wordt geïmplementeerd op de productieomgeving en is nu live en beschikbaar voor gebruik door eindgebruikers.

Quality Gate 5: Smoke Test

Na implementatie wordt een Smoke Test uitgevoerd. Dit is een snelle, oppervlakkige test om te controleren of de belangrijkste functionaliteiten van de API correct werken.
Beslismoment (OK?):

• Ja: Als de Smoke Test slaagt, is het proces voltooid en eindigt de implementatiecyclus.
• Nee: Als de test faalt, wordt de API aangepast en opnieuw getest.

API Deployment: API Gateway & Policies

Het is van cruciaal belang dat elke API die wordt gedeployed via de bouwstraat en gebruik maakt van RAML, automatisch een eigen API Gateway krijgt gedeployed in de runtimes. Dit proces zorgt ervoor dat de API en de gateway direct aan elkaar gekoppeld zijn via specifieke properties en configuratie-instellingen. Deze koppeling maakt gebruik van auto discovery via APIGatewayID-2-API, waardoor het meteen duidelijk wordt waar de API moet binnenkomen. Zowel de API als de gateway draaien binnen de runtimes, wat zorgt voor een naadloze integratie en werking.
Deze setup wordt gebruikt voor vier belangrijke policies:

• Client ID Enforcement: Deze policy wordt automatisch toegepast op de API Gateway en zorgt ervoor dat elke client die toegang wil tot de API, een geldige client ID moet hebben. Dit helpt bij het beheren van toegangsrechten en het waarborgen van de veiligheid van de API.
• OIN Header: Specifiek voor LAVS, deze policy vereist dat elke aanvraag een OIN header bevat. Dit helpt bij het identificeren en valideren van aanvragen die afkomstig zijn van specifieke bronnen.
• Certificate Validation: Ook specifiek voor LAVS, deze policy zorgt ervoor dat alle certificaten die worden gebruikt voor het beveiligen van communicatie met de API, worden gevalideerd. Dit draagt bij aan de beveiliging en betrouwbaarheid van de API.
• SLA Policy: Deze policy beperkt het aantal aanvragen per seconde dat naar de API kan worden gestuurd. Dit helpt bij het beheren van de belasting op de API en zorgt ervoor dat de prestaties consistent blijven, zelfs onder hoge belasting.

Door deze policies en configuraties te implementeren, wordt een robuuste en veilige omgeving gecreëerd waarin API's efficiënt kunnen draaien en communiceren met andere systemen. Dit proces is essentieel voor het waarborgen van de betrouwbaarheid en veiligheid van API's in een steeds complexer wordende digitale wereld.

Release processen

Door de verschillende soorten releaseprocessen te begrijpen en correct toe te passen, kunnen teams de kwaliteit en betrouwbaarheid van hun softwareleveringen verbeteren. Hieronder worden de belangrijkste soorten releases beschreven:

Snapshot Release

Een snapshot release biedt ontwikkelaars de mogelijkheid om deze wijzigingen in een test-runtime te valideren. Dit type release kan alleen naar de testomgeving worden uitgevoerd en is een optionele stap die voorafgaat aan de officiële release naar de OTAP-omgevingen (Ontwikkeling, Test, Acceptatie, Productie).
Een snapshot release wordt getriggerd bij codewijzigingen na lokale tests. Dit betekent dat ontwikkelaars eerst hun wijzigingen lokaal testen om ervoor te zorgen dat ze correct werken. Zodra deze lokale tests succesvol zijn, kunnen de wijzigingen worden opgenomen in een snapshot release. Dit stelt ontwikkelaars in staat om hun wijzigingen op het platform uit te proberen en te testen zonder een officiële release uit te voeren.
Het belangrijkste voordeel van een snapshot release is dat het ontwikkelaars de flexibiliteit biedt om snel fixes, nieuwe features of grote wijzigingen te valideren. Door deze wijzigingen eerst in een testomgeving te implementeren, kunnen eventuele problemen vroegtijdig worden geïdentificeerd en opgelost. Dit helpt bij het minimaliseren van risico's en zorgt ervoor dat de uiteindelijke officiële release naar de OTAP-omgevingen soepel verloopt.
Snapshot releases zijn ideaal voor het snel valideren van wijzigingen, omdat ze een laagdrempelige manier bieden om nieuwe code te testen. Ontwikkelaars kunnen experimenteren met verschillende oplossingen en configuraties zonder de druk van een officiële release. Dit proces draagt bij aan een iteratieve en agile ontwikkelomgeving, waarin continue verbetering en snelle feedback centraal staan.
Het uitvoeren van een snapshot release vereist zorgvuldige planning en uitvoering. Ontwikkelaars moeten ervoor zorgen dat alle benodigde bestanden en configuraties beschikbaar zijn en dat de juiste stappen worden gevolgd om de snapshot release succesvol te voltooien. Daarnaast is het belangrijk om duidelijke communicatie te hebben met alle betrokken partijen, zodat iedereen op de hoogte is van de situatie en de stappen die worden ondernomen om de wijzigingen te testen.
Door gebruik te maken van snapshot releases kunnen organisaties hun ontwikkelproces optimaliseren en de kwaliteit van hun software verbeteren. Dit type release is een essentieel onderdeel van een robuuste release- en teststrategie, die helpt om de stabiliteit en betrouwbaarheid van softwaretoepassingen te waarborgen.

New Release

Een nieuwe release, ook wel bekend als een "new release", houdt in dat er een nieuwe versie van de applicatie wordt uitgebracht. Deze nieuwe versie kan een reguliere update zijn die nieuwe functionaliteiten, verbeteringen of bugfixes bevat.
Het proces van een nieuwe release volgt doorgaans een gestructureerd releaseproces. Dit proces begint met de ontwikkeling van nieuwe functies en verbeteringen door het ontwikkelteam. Zodra de code is geschreven, begint de testfase, waarin de nieuwe versie door verschillende testfasen gaat om ervoor te zorgen dat alle nieuwe functies en verbeteringen correct werken en dat eventuele bugs worden geïdentificeerd en opgelost.
De testfasen kunnen bestaan uit unit tests, integratietests, systeemtests en acceptatietests. Tijdens deze fasen wordt de nieuwe versie grondig getest om ervoor te zorgen dat deze voldoet aan de kwaliteitsnormen en dat er geen kritieke problemen zijn die de werking van de applicatie kunnen verstoren. Het doel van deze tests is om ervoor te zorgen dat de nieuwe versie stabiel en betrouwbaar is voordat deze in productie wordt genomen.
Na succesvolle afronding van de testfasen wordt de nieuwe versie voorbereid voor release. Dit omvat het creëren van de benodigde artifacts, zoals Jar-bestanden, en het configureren van de deployment-instellingen. Vervolgens wordt de nieuwe versie gedeployed naar de productieomgeving, waar deze beschikbaar wordt gesteld aan de gebruikers.
Nieuwe releases zijn essentieel voor het verbeteren van de gebruikerservaring en het toevoegen van waarde aan de applicatie. Door regelmatig nieuwe versies uit te brengen, kunnen organisaties ervoor zorgen dat hun applicaties up-to-date blijven en voldoen aan de veranderende behoeften van hun gebruikers. Bovendien helpen nieuwe releases bij het oplossen van bugs en het verbeteren van de prestaties van de applicatie, wat bijdraagt aan de algehele betrouwbaarheid en stabiliteit.
Het gestructureerde releaseproces zorgt ervoor dat elke nieuwe versie grondig wordt getest en voorbereid voordat deze in productie wordt genomen. Dit helpt bij het minimaliseren van risico's en het waarborgen van een soepele overgang naar de nieuwe versie. Door deze aanpak kunnen organisaties hun applicaties continu verbeteren en hun gebruikers een optimale ervaring bieden.

Redeploy

Een redeploy wordt uitgevoerd wanneer er problemen zijn opgetreden tijdens de initiële deployment of wanneer er wijzigingen zijn aangebracht in de configuratie zonder dat de code zelf is gewijzigd. Een redeploy zorgt ervoor dat de meest recente versie van de applicatie opnieuw wordt geïmplementeerd, zonder dat er wijzigingen in de code worden aangebracht.
Het uitvoeren van een redeploy kan om verschillende redenen noodzakelijk zijn. Soms kunnen er tijdens de initiële deployment onverwachte problemen optreden, zoals fouten in de configuratie of netwerkproblemen, die de succesvolle implementatie van de applicatie verhinderen. In andere gevallen kunnen er wijzigingen worden aangebracht in de configuratie-instellingen die een hernieuwde deployment vereisen om effectief te worden toegepast.
Een redeploy biedt de mogelijkheid om deze problemen snel en efficiënt op te lossen. Door dezelfde artifact opnieuw te deployen, kunnen systeembeheerders ervoor zorgen dat de meest recente versie van de applicatie correct wordt geïmplementeerd en dat eventuele configuratiewijzigingen worden toegepast. Dit proces helpt bij het waarborgen van de stabiliteit en betrouwbaarheid van de productieomgeving, zonder dat er wijzigingen in de onderliggende code nodig zijn.
Het proces van een redeploy vereist zorgvuldige planning en uitvoering. Systeembeheerders moeten ervoor zorgen dat alle benodigde bestanden en configuraties beschikbaar zijn en dat de juiste stappen worden gevolgd om de redeploy succesvol te voltooien. Daarnaast is het belangrijk om duidelijke communicatie te hebben met alle betrokken partijen, zodat iedereen op de hoogte is van de situatie en de stappen die worden ondernomen om het probleem op te lossen.
Door een redeploy uit te voeren, kunnen organisaties snel reageren op onverwachte problemen en de impact op hun gebruikers minimaliseren. Dit proces is een essentieel onderdeel van een robuuste release- en incidentmanagementstrategie, die helpt om de stabiliteit en betrouwbaarheid van softwaretoepassingen te waarborgen.

Roll-back

Soms is het noodzakelijk om terug te keren naar een oudere, stabiele versie van een applicatie. Dit proces, bekend als een roll-back, wordt uitgevoerd wanneer er kritieke problemen worden ontdekt in de nieuwste release die niet snel kunnen worden opgelost. Een roll-back zorgt ervoor dat de stabiliteit van de productieomgeving wordt hersteld, terwijl er wordt gewerkt aan een oplossing voor de problemen in de nieuwste versie.
Het uitvoeren van een roll-back houdt in dat een oudere versie van de applicatie opnieuw wordt gedeployed. Deze oudere versie is eerder getest en bewezen stabiel te zijn, waardoor het risico op verdere problemen wordt geminimaliseerd. Door terug te keren naar deze stabiele versie, kunnen gebruikers en klanten blijven werken zonder onderbrekingen, terwijl het ontwikkelteam de tijd krijgt om de problemen in de nieuwste release grondig te onderzoeken en op te lossen.
Een roll-back kan om verschillende redenen noodzakelijk zijn. Soms worden er na de release van een nieuwe versie onverwachte bugs of prestatieproblemen ontdekt die niet tijdens de testfase zijn opgemerkt. In andere gevallen kunnen er compatibiliteitsproblemen optreden met andere systemen of applicaties. Ongeacht de oorzaak, het belangrijkste doel van een roll-back is om de continuïteit en betrouwbaarheid van de productieomgeving te waarborgen.
Het proces van een roll-back vereist zorgvuldige planning en uitvoering. Systeembeheerders moeten ervoor zorgen dat alle benodigde bestanden en configuraties beschikbaar zijn om de oudere versie succesvol te deployen. Daarnaast is het belangrijk om duidelijke communicatie te hebben met alle betrokken partijen, zodat iedereen op de hoogte is van de situatie en de stappen die worden ondernomen om het probleem op te lossen.
Door een roll-back uit te voeren, kunnen organisaties snel reageren op onverwachte problemen en de impact op hun gebruikers minimaliseren. Dit proces is een essentieel onderdeel van een robuuste release- en incidentmanagementstrategie, die helpt om de stabiliteit en betrouwbaarheid van softwaretoepassingen te waarborgen.

Nood-release (handmatig)

Soms is het noodzakelijk om snel te reageren op onverwachte problemen die de normale werking van systemen kunnen verstoren. In dergelijke noodsituaties wordt een nood-release handmatig uitgevoerd via het Anypoint Platform of rechtstreeks op de runtime servers. Dit type release is ontworpen om snelle actie mogelijk te maken wanneer er kritieke problemen optreden die onmiddellijke aandacht vereisen.
Het proces van een nood-release omvat het plaatsen van één of meerdere Jar-bestanden in de Apps-map. Deze bestanden worden vervolgens automatisch opgepakt door de Mule Runtime, waardoor de benodigde updates of fixes snel worden geïmplementeerd. Door deze aanpak kunnen ontwikkelaars en systeembeheerders snel reageren op problemen zonder te hoeven wachten op de reguliere releasecyclus.
Nood-releases worden meestal uitgevoerd buiten de reguliere releasecyclus om ervoor te zorgen dat kritieke problemen snel en efficiënt worden opgelost. Dit is essentieel om de continuïteit en betrouwbaarheid van systemen te waarborgen, vooral in situaties waarin elke seconde telt. Door deze flexibiliteit kunnen organisaties hun systemen draaiende houden en de impact van onverwachte problemen minimaliseren.
Het uitvoeren van een nood-release vereist een goed begrip van de onderliggende infrastructuur en de tools die beschikbaar zijn binnen het Anypoint Platform. Systeembeheerders moeten snel kunnen handelen en de juiste stappen volgen om ervoor te zorgen dat de nood-release succesvol is en de gewenste resultaten oplevert.