Testautomatisering en de leveringspijplijn

U hebt geleerd over continue implementatie en levering van software en services, maar de twee maken eigenlijk deel uit van een triad. DevOps-procedures zijn gericht op het bereiken van continue integratie, levering en implementatie. Deze praktijken zijn doorgaans opgebouwd in die volgorde, waarbij elke afhankelijk is van de voorgaande.

Nu is het tijd om even terug te gaan en de eerste hiervan te bespreken: integratie. Dit maakt deel uit van het ontwikkelingsproces dat voor de implementatie plaatsvindt. DevOps beveelt een ontwikkelingsprocedure aan waarbij teamleden code vaak integreren in een gedeelde opslagplaats met een enkelvoudige 'main'- of 'trunk'-codebasis. Het doel is dat iedereen bijdraagt aan de code die wordt verzonden in plaats van aan hun eigen kopie te werken en alles op het laatste moment samen te voegen.

Geautomatiseerde tests kunnen vervolgens de integratie van elk teamlid verifiëren. Deze tests helpen na elke wijziging en toevoeging vast te stellen of de code in orde is. Het testen maakt deel uit van een pijplijn. De rest van deze eenheid is gericht op geïntegreerde test- en leveringspijplijnen.

De doorlopende leveringspijplijn

Als u de rol van geautomatiseerde tests in het implementatiemodel voor continue levering wilt begrijpen, moet u kijken waar deze in de leveringspijplijn past. Een doorlopende leveringspijplijn is de implementatie van de reeks stappen die code doorloopt wanneer er wijzigingen worden ingevoerd tijdens het ontwikkelingsproces voordat de code wordt geïmplementeerd in de productieomgeving. Hier volgt een grafische weergave van voorbeeldstappen in een vereenvoudigde leveringspijplijn:

Doorloop deze pijplijn stapsgewijs:

• Een exemplaar van de pijplijn start wanneer code- of infrastructuurwijzigingen worden doorgevoerd in een code-opslagplaats, mogelijk door middel van een pull-aanvraag.

• Vervolgens worden eenheidstests uitgevoerd, vaak gevolgd door integratie- of end-to-endtests. De resultaten worden teruggestuurd naar de ontwikkelaar die de pull-aanvraag heeft geopend.

• In deze fase wordt de code in de opslagplaats vaak gescand op geheimen, beveiligingsproblemen en onjuiste configuraties.

• Wanneer alles in orde is, wordt de code gebouwd en voorbereid voor implementatie.

• Vervolgens wordt de code geïmplementeerd in een testomgeving. Een revisor kan op de hoogte worden gesteld van de nieuwe implementatie, zodat deze de preproductieoplossing kan onderzoeken. De beoordelaar keurt vervolgens de promotie naar productie goed of weigert deze, waarmee het laatste deel van het implementatieproces begint waarin de code wordt doorgevoerd naar productie.

In deze pijplijn kunt u de afbakening tussen integratie en implementatie noteren. De gemarkeerde markeringen wijzen op enkele logische plaatsen waar u de pijplijn kunt stoppen via opgenomen logica en automatisering, of mogelijk zelfs menselijke interventie.

Hulpprogramma's voor continue integratie en levering: Azure-pipelines en GitHub Actions

Als u continue integratie en continue levering wilt gebruiken, hebt u de juiste hulpprogramma’s nodig. Microsoft biedt twee eigen CI/CD-opties voor het bouwen en implementeren van Azure: Azure-pipelines (onderdeel van Azure DevOps) en GitHub Actions. Beide kunnen het bouwen en consistent testen van uw code automatiseren, en beide kunnen worden geïmplementeerd op Azure services, virtuele machines en andere doelen in de cloud en on-premises. Veel teams gebruiken GitHub Actions wanneer hun broncode al in GitHub woont, terwijl Azure-pipelines een sterke keuze blijft voor teams die zijn gestandaardiseerd op Azure DevOps.

De rest van deze les is gericht op Azure-pipelines, maar GitHub Actions maakt gebruik van vergelijkbare ideeën op hoog niveau, ook al verschilt de terminologie. In GitHub Actions bevatten werkstromen taken en stappen, verpakken acties herbruikbare automatisering, voeren uitvoerders het werk uit, en kunnen omgevingen implementaties beveiligen.

De invoer voor een pijplijn (uw code of configuraties) bevindt zich in een versiebeheersysteem, zoals GitHub of een andere Git-provider.

Azure-pipelines wordt uitgevoerd op computatiefaciliteiten, zoals een virtuele machine of een container, en biedt bovendien Microsoft-gehoste buildagents die draaien op Windows, Linux en macOS. U kunt ook uw eigen zelfgehoste agents registreren wanneer u volledige controle over de build-omgeving nodig hebt. Het biedt ook integratie met invoegtoepassingen voor testen, beveiliging en codekwaliteit. Ten slotte is het eenvoudig uit te breidbaar, zodat u uw eigen automatisering in Azure-pipelines kunt brengen.

Pijplijnen worden gedefinieerd met behulp van DE YAML-syntaxis die naast uw code is opgeslagen in een Git-opslagplaats. YAML-pijplijnen zijn de aanbevolen benadering voor nieuwe projecten. Een klassieke gebruikersinterface in Azure DevOps is ook beschikbaar voor verouderde pijplijnen, maar de meeste nieuwe functionaliteit (inclusief containertaken en veel geavanceerde functies) is ALLEEN YAML. Pijplijnen bieden ook sjablonen die u kunt gebruiken om eenvoudig pijplijnen te maken, zoals een sjabloon voor een Docker-image of een Node.js-project. U kunt ook een bestaand YAML-bestand opnieuw gebruiken.

De basisstappen voor het instellen van een pijplijn zijn:

1. Configureer Azure-pipelines voor het gebruik van uw Git-opslagplaats.
2. Definieer uw build door het azure-pipelines.yml-bestand te bewerken (of, voor verouderde pijplijnen, met behulp van de klassieke editor).
3. Push uw code naar uw opslagplaats voor versiebeheer. Met deze actie wordt de pijplijn geactiveerd om uw code te bouwen en te testen.

Zodra de code is bijgewerkt, gebouwd en getest, kunt u deze implementeren op elk gewenst doel.

Azure pijplijnconstructie

Pijplijnen worden onderverdeeld in:

• Taken: Een taak is een groepering van taken of stappen die worden uitgevoerd op één buildagent. Een taak is het kleinste onderdeel van het werk dat u kunt plannen om uit te voeren. Alle stappen in een taak worden opeenvolgend uitgevoerd. Deze stappen kunnen elke actie zijn die u nodig hebt, waaronder het bouwen of compileren van software, het voorbereiden van voorbeeldgegevens voor testen, het uitvoeren van specifieke tests, enzovoort.

• Fasen: Een fase is een logische groepering van gerelateerde taken.

Elke pijplijn heeft ten minste één fase. Gebruik meerdere fasen om de pijplijn in te delen in grote afdelingen en markeer de punten in uw pijplijn waar u kunt onderbreken en controles kunt uitvoeren.

Pijplijnen kunnen zo eenvoudig of zo complex zijn als u nodig hebt. Zie het leertraject Build-toepassingen met Azure DevOps voor zelfstudies over het bouwen en gebruiken van pijplijnen.

Traceerbaarheid van de omgeving

Er is nog een ander aspect van pijplijnen met betrekking tot betrouwbaarheid die het vermelden waard zijn. U kunt uw pijplijnen zo opzetten dat het mogelijk is om wat in productie wordt uitgevoerd, in verband te brengen met een specifieke build-instance. In het ideale geval moet u een build kunnen traceren naar een specifieke pull-aanvraag of codewijziging. Deze traceerbaarheid is waardevol tijdens een incident en daarna tijdens de incidentbeoordeling wanneer u probeert te identificeren welke wijziging heeft bijgedragen aan een probleem. Sommige CI/CD-systemen (zoals Azure-pipelines en GitHub Actions) maken deze correlatie eenvoudig, terwijl andere vereisen dat u handmatig een pijplijn maakt waarmee een build-id wordt doorgegeven in elke fase.