Release pipelines in Azure DevOps

Wat is Continue deployment?

Continu deployment is een benadering om software automatisch vrij te geven naar de inzetbare regio's ervan. Zodra de code het continue integratieproces heeft voltooid (het compileren van de broncode, valideren van de broncode, beoordelen van de code, uitvoeren van unit tests, en het creëren van build-artefacten), zullen de build-artefacten geleidelijk worden ingezet met behulp van de continue deployment-benadering, vanaf de lagere omgeving tot aan de productieomgeving.

De software-releasecyclus heeft zich ontwikkeld. Continue implementatie vervangt de foutgevoelige legacy-aanpak van het verplaatsen van code van de ene machine naar de andere en het valideren van de code na implementatie, wat ook een tijdrovend en resource-intensief proces is.

Voordelen van continue deployment

• Automatiseert repetitieve handmatige taken en helpt het team zich te concentreren op het product. 
• Verbetering van de algehele productiviteit. 
• Biedt consistentie door vergelijkbare implementaties over verschillende omgevingen te produceren.
• Helpt bij het eenvoudig volgen en terugdraaien van wijzigingen in geval van problemen.
• Verwijdert de kans op menselijke fouten bij het bijwerken van configuraties die specifiek zijn voor omgevingen.
• Stelt bedrijven in staat om sneller nieuwe functies uit te rollen als reactie op veranderende markteisen.

Wat is een release-pipeline in Azure DevOps? 

De release-pipeline in Azure DevOps helpt teams om software continu en met minder risico's aan de klant te leveren, en dit op een sneller tempo. Het kan volledig geautomatiseerd worden om de software naar meerdere fasen te leveren tot aan de productieomgeving.

Het biedt ook opties voor semi-geautomatiseerde implementaties met mogelijkheden voor on-demand-implementaties en op goedkeuring gebaseerde implementaties, waar menselijke tussenkomst vereist is om de implementatie goed te keuren of te activeren op basis van de behoefte.

Een release is een pakket dat de versie gebaseerde set artefacten bevat die zijn gespecificeerd in de release-pipeline. Het bevat informatie over de taken die als onderdeel van de release moeten worden uitgevoerd. Samen met die informatie bevat het ondersteunende gegevens zoals de fasen waarin het pakket moet worden vrijgegeven, goedkeuringsdetails, omgeving gerelateerde gegevens die zijn opgeslagen in releasevariabelen, en wachtopties. Al deze informatie wordt gedurende een specifieke retentieperiode opgeslagen in Azure-pipelines.

Releasepipeline-workflow

De release-pipeline doorloopt de volgende stappen als onderdeel van elke implementatie.

• Goedkeuring voor implementatie: Release-Pipelines bieden een optie voor implementatie op basis van goedkeuringen. Voor elke nieuwe implementatie die wordt getriggerd, doorloopt de release-Pipelines een toegangscontrole voorafgaand aan de implementatie voordat een release naar een omgeving wordt geïmplementeerd. Bovendien bieden release-Pipelines opties om een melding naar goedkeurders te sturen om hen te informeren.
• In de wacht zetten van implementatietaken: Het proces van geautomatiseerde implementatie van wijzigingen wordt uitgevoerd door automatiseringsagenten die aanwezig zijn in Azure-pipelines. Een agent is een software die in staat is om taken uit te voeren in het implementatieproces. Release-Pipelines plannen de implementatietaak in op de beschikbare agents.
• Agentselectie: Release-Pipelines kunnen een van de twee instellingen hebben - automatisch toegewezen agents gebruiken of uw eigen voorkeursagent gebruiken voor het uitvoeren van de implementatietaken.
• Verwijzing naar artefacten: Tijdens het maken van de release biedt Azure de optie om een specifieke versie van build-artefacten te implementeren. De artefacten die zijn gemaakt door de build-pipelines worden gedownload door de agents voor implementatie. Momenteel ondersteunen de agents Azure-pijplijnartefacten en Jenkins-artefacten.
• Implementatietaken: De release-pipeline biedt een optie om de vereiste implementatietaken te configureren. De agent voert alle geconfigureerde taken sequentieel uit en implementeert de app op de doelserver.
• Logboeken voor monitoring: Tijdens het implementatieproces maken agents gedetailleerde logboeken aan tijdens het uitvoeren van elke implementatietaak. Dit helpt het team verder om fouten te achterhalen in geval van implementatiefouten.
• Goedkeuring na implementatie: Zodra de implementatie naar een omgeving is voltooid, valideert de release-pipeline of er goedkeuringen na implementatie vereist zijn voor de omgeving of fasen.

Wat biedt de releasepipeline? 

Azure-pijplijnen stellen gebruikers in staat om release-Pipelines op applicatieniveau te maken, vergelijkbaar met build-pipelines. Release-Pipelines nemen de bron van implementatie op, namelijk het artefact dat nodig is voor implementatie en dat wordt gemaakt met behulp van een build-pipeline.

De releasepijplijn biedt stages om de implementatie voor verschillende omgevingen te scheiden. Elke stage heeft een aparte reeks workflow componenten geconfigureerd, zoals voor- en na-implementatiegoedkeuringen, releasevariabelen, implementatiestaken en triggers. Om instellingen te configureren op basis van de omgeving, kunnen releasevariabelen worden gebruikt. Releasevariabelen bieden opties om dezelfde variabele te configureren voor verschillende stages met verschillende waarden.

In het bovenstaande voorbeeld implementeert de releasepijplijn eerst de artefacten naar de ontwikkelingsregio. Zodra de ontwikkelingsregio slaagt, wordt er geïmplementeerd naar de QA-regio gevolgd door UAT. Voor de productieregio is er een pre-implementatievoorwaarde aanwezig. Dus, zodra het team alle wijzigingen in de UAT-regio valideert, keuren de geschikte goedkeurders de pre-implementatievoorwaarde goed in de productiestadium. Zodra goedgekeurd, wordt de code geïmplementeerd naar de productieregio.

Samenvattingen van implementaties kunnen per e-mail worden verzonden door de optie voor het verzenden van e-mails te selecteren onder de releasepijplijn. Voor identificatiedoeleinden bieden de releasepijplijnen namen voor elke release. De naam van de release bestaat doorgaans uit de naam van de toepassing, het release-id, de branche van de bron, het buildnummer en de definitie. Hiermee kunnen gebruikers de vereiste release identificeren uit de geschiedenis van de releasepijplijn.

Conclusie

Continue integratie is een proces waarbij elke functie gerelateerde wijziging wordt geïntegreerd in de hoofdbranche en de build, unit tests worden gevalideerd, en een gebundeld pakket van de oplossing wordt gemaakt dat kan worden geïmplementeerd. Aan de andere kant is continue implementatie een krachtig instrument voor moderne engineeringorganisaties. De cyclus van DevOps wordt voltooid met continue implementatie, zoals we hebben gezien in deze post. En we hebben de Release-pijplijnen in Azure DevOps die de beste functies bieden om continue implementatie op een probleemloze manier te bereiken.