De pijplijn ontwerpen

11 minuten

In deze les volgt u het Tailspin-webteam tijdens het definiëren van hun release-pijplijn voor de Space Game-website .

Wanneer u een release-pijplijn plant, begint u meestal met het identificeren van de fasen, of belangrijke divisies, van die pijplijn. Elke fase wordt doorgaans toegewezen aan een omgeving. In de vorige module had Andy en Mara's basispijplijn bijvoorbeeld een implementatiefase die is toegewezen aan een Azure-app Service-exemplaar.

In deze module promoot u wijzigingen van de ene fase naar de volgende. Binnen elke fase implementeert u de Space Game-website in de omgeving die aan die fase is gekoppeld.

Nadat u hebt gedefinieerd welke fasen u nodig hebt, kunt u overwegen hoe wijzigingen van de ene fase naar de volgende worden gepromoveerd. Elke fase kan de succescriteria definiëren waaraan moet worden voldaan voordat de build naar de volgende fase kan gaan. Azure Pipelines biedt verschillende manieren om te bepalen hoe en wanneer wijzigingen door de pijplijn worden verplaatst. Als geheel worden deze benaderingen gebruikt voor releasebeheer.

In deze sectie doet u het volgende:

Meer informatie over de verschillen tussen veelvoorkomende pijplijnfasen, zoals Build, Dev, Test en Staging.
Meer informatie over het gebruik van handmatige, geplande en continue implementatietriggers om te bepalen wanneer een artefact naar de volgende fase in de pijplijn wordt verplaatst.
Bekijk hoe een releasegoedkeuring de pijplijn onderbreekt totdat een fiatteur de release accepteert of weigert.

De vergadering

Het hele Tailspin-webteam wordt samengebracht. In Een release-pijplijn maken met Azure Pipelines heeft het team hun taken gepland voor de huidige sprint. Elke taak heeft betrekking op het bouwen van hun release-pijplijn voor de Space Game-website .

Zoals u weet, heeft het team besloten om deze vijf taken voor hun sprint uit te voeren:

Maak een pijplijn met meerdere fases.
Verbinding maken de web-app naar een database.
Automatiseer kwaliteitstests.
Automatiseer prestatietests.
Verbeter het releaseritme.

Het team komt eraan om te praten over de eerste taak, een pijplijn met meerdere fases maken. Nadat het team de pijplijn heeft gedefinieerd, kan deze overstappen van het basistestconcept naar een release-pijplijn met meer fasen, kwaliteitscontroles en goedkeuringen.

Amita en Tim kijken Andy en Mara laten de releasepijplijn een tweede keer zien. Ze zien dat het artefact is gebouwd en geïnstalleerd in App Service.

Welke pijplijnfasen hebt u nodig?

Wanneer u een release-pijplijn wilt implementeren, is het belangrijk om eerst te bepalen welke fasen u nodig hebt. De fasen die u kiest, zijn afhankelijk van uw vereisten. Laten we het team volgen terwijl ze beslissen over hun fasen.

Tim: OK, ik begrijp het idee van een geautomatiseerde pijplijn. Ik vind het leuk om eenvoudig te implementeren in Azure. Maar waar gaan we van deze demo? We hebben iets nodig dat we daadwerkelijk kunnen gebruiken voor onze releases.

Amita: Juist! We moeten andere fasen toevoegen. Momenteel hebben we bijvoorbeeld geen plaats voor een testfase.

Tim: Plus, we hebben een fase nodig waar we nieuwe functies aan het beheer kunnen tonen. Ik kan niets naar productie sturen zonder goedkeuring van het management.

Andy: Absoluut! Nu het aan de slag gaat met wat een release-pijplijn doet, hoe maken we van deze pijplijn wat we nodig hebben?

Mara: Laten we onze vereisten schetsen om ons te helpen onze volgende stappen te plannen. Laten we beginnen met wat we hebben.

Mara gaat naar het whiteboard en schetst de bestaande pijplijn.

Diagram of the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Mara: De buildfase bouwt de broncode en produceert een pakket. In ons geval is dat pakket een ZIP-bestand . De implementatiefase installeert het .zip-bestand , de space game-website , op een App Service-exemplaar. Wat ontbreekt er in onze release-pijplijn?

De dev-fase toevoegen

Andy: Ik ben misschien bevooroordeeld, maar ik denk dat we een Dev-fase nodig hebben. Deze fase moet de eerste stop zijn voor het artefact nadat het is gebouwd. Ontwikkelaars kunnen de hele service niet altijd uitvoeren vanuit hun lokale ontwikkelomgeving. Een e-commercesysteem kan bijvoorbeeld een website, productdatabase en betalingssysteem vereisen. We hebben een fase nodig die alles bevat wat de app nodig heeft.

In ons geval leest de scoreboardfunctie van de Space Game-website hoge scores uit een externe bron. Op dit moment worden fictieve scores uit een bestand gelezen. Het instellen van een Dev-fase geeft ons een omgeving waarin we de web-app kunnen integreren met een echte database. Deze database kan nog steeds fictieve scores bevatten, maar het brengt ons één stap dichter bij onze uiteindelijke app.

Mara: Ik vind het leuk. We integreren nog niet met een echte database. Maar in een dev-fase kunnen we implementeren in een omgeving waar we een database kunnen toevoegen.

Mara werkt haar tekening bij op het whiteboard. Ze vervangt 'Implementeren' door 'Dev' om de fase Dev weer te geven.

Diagram that shows the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Andy: Je brengt een interessant punt op. We bouwen de app telkens wanneer we een wijziging naar GitHub pushen. Betekent dit dat elke build wordt gepromoveerd naar de dev-fase nadat deze is voltooid?

Mara: Bouwen geeft ons continu belangrijke feedback over onze build- en teststatus. Maar we willen alleen promoveren naar de Dev-fase wanneer we code samenvoegen in een centrale vertakking: hoofd- of een andere releasebranch. Ik werk de tekening bij om die vereiste weer te geven.

Diagram that shows whiteboard illustrating build and dev stages. A condition promotes to the Dev stage only when changes happen on a release branch.

Mara: Ik denk dat deze promotie gemakkelijk te bereiken is. We kunnen een voorwaarde definiëren die alleen naar de Dev-fase promoot wanneer er wijzigingen plaatsvinden in een releasebranch.

Wat zijn voorwaarden?

Gebruik in Azure Pipelines een voorwaarde om een taak of taak uit te voeren op basis van de status van de pijplijn. U hebt in eerdere modules met voorwaarden gewerkt.

Houd er rekening mee dat enkele van de voorwaarden die u kunt opgeven zijn:

Alleen wanneer alle vorige afhankelijke taken zijn geslaagd.
Zelfs als een eerdere afhankelijkheid is mislukt, tenzij de uitvoering is geannuleerd.
Zelfs als een eerdere afhankelijkheid is mislukt, zelfs als de uitvoering is geannuleerd.
Alleen wanneer een eerdere afhankelijkheid is mislukt.
Een aangepaste voorwaarde.

Hier volgt een basisvoorbeeld:

steps:
  - script: echo Hello!
    condition: always()

De always() voorwaarde zorgt ervoor dat deze taak 'Hallo!' voorwaardelijke afdrukt, zelfs als eerdere taken zijn mislukt.

Deze voorwaarde wordt gebruikt als u geen voorwaarde opgeeft:

condition: succeeded()

De succeeded() ingebouwde functie controleert of de vorige taak is geslaagd. Als de vorige taak mislukt, worden deze taak en latere taken die gebruikmaken van dezelfde voorwaarde overgeslagen.

Hier wilt u een voorwaarde maken die aangeeft:

De vorige taak is voltooid.
De naam van de huidige Git-vertakking is release.

U maakt deze voorwaarde met de ingebouwde functie and(). Met deze functie wordt gecontroleerd of aan elk van de voorwaarden wordt voldaan. Als een van de voorwaarden niet waar is, mislukt de algehele voorwaarde.

Als u de naam van de huidige vertakking wilt ophalen, gebruikt u de ingebouwde Build.SourceBranchName variabele. U kunt op een aantal manieren toegang krijgen tot variabelen binnen een voorwaarde. Hier gebruikt u de variables[] syntaxis.

Als u de waarde van een variabele wilt testen, kunt u de ingebouwde functie eq() gebruiken. Met deze functie wordt gecontroleerd of de argumenten ervan gelijk zijn.

Daarom past u deze voorwaarde alleen toe om de Dev-fase uit te voeren wanneer de naam van de huidige vertakking 'release' is:

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

De eerste voorwaarde is de functie and(), waarmee wordt gecontroleerd of de voorgaande taak is gelukt. Met de tweede voorwaarde wordt gecontroleerd of de naam van de huidige vertakking gelijk is aan de release.

In YAML gebruikt u de pijpsyntaxis (|) om een tekenreeks te definiëren die meerdere regels omvat. U kunt de voorwaarde op één regel definiëren, maar we schrijven hem zo om hem beter leesbaar te maken.

Notitie

In deze module gebruiken we de releasebranch als voorbeeld. U kunt voorwaarden combineren om het gedrag te definiëren dat u nodig hebt. U kunt bijvoorbeeld een voorwaarde bouwen die de fase alleen uitvoert wanneer de build wordt geactiveerd door een pull-aanvraag voor de hoofdbranch .

In de volgende les, wanneer u de dev-fase instelt, werkt u met een completer voorbeeld.

Zie de documentatie voor expressies voor een volledige beschrijving van voorwaarden in Azure Pipelines.

Mara: Met behulp van voorwaarden kunt u bepalen welke wijzigingen worden gepromoveerd tot welke fasen. We kunnen een buildartefact produceren voor elke wijziging om onze build te valideren en te bevestigen dat deze in orde is. Wanneer we klaar zijn, kunnen we deze wijzigingen samenvoegen in een releasevertakking en die build promoveren naar de dev-fase .

De testfase toevoegen

Mara: Tot nu toe hebben we de fasen Build en Dev . Wat komt hierna?

Amita: Kunnen we de testfase nu toevoegen? Dat lijkt me de juiste plek om de meest recente wijzigingen te testen.

Mara voegt de testfase toe aan haar tekening op het whiteboard.

Diagram that shows the whiteboard illustrating build, dev and test stages. The Test stage deploys the build to Azure App Service.

Amita: Een probleem dat ik heb, is hoe vaak ik de app moet testen. Een e-mailbericht waarschuwt me wanneer Mara of Andy een wijziging aanbrengt. Er gebeuren de hele dag veranderingen en ik weet nooit wanneer ik erin moet springen. Ik denk dat ik een keer per dag een build wil zien, misschien als ik bij het kantoor ben. Kunnen we dat doen?

Andy: Zeker. Waarom implementeren we niet in Testen tijdens vrije uren? Stel dat we u elke dag om 3:00 uur een build sturen.

Mara: Dat klinkt goed. We kunnen het proces altijd handmatig activeren als dat nodig is. We kunnen deze bijvoorbeeld activeren als we u nodig hebben om meteen een belangrijke foutoplossing te controleren.

Mara werkt haar tekening bij om aan te geven dat de build elke ochtend van de Dev-fase naar de testfase gaat.

Diagram that shows the whiteboard showing Build, Dev, and Test stages. The schedule promotes the change from Dev to Test at 3 A.M. each morning.

Wat zijn triggers?

Amita: Ik voel me beter nu we weten hoe de ene fase naar de andere gaat. Maar hoe bepalen we wanneer een fase wordt uitgevoerd?

Mara: In Azure Pipelines kunnen we triggers gebruiken. Een trigger definieert wanneer een fase wordt uitgevoerd. Azure Pipelines biedt een aantal typen triggers. Hier volgen onze keuzes:

Ci-trigger (Continue integratie)
Pull-aanvraagtrigger (PR)
Geplande trigger
Trigger voor voltooiing van build

Met CI- en PULL-triggers kunt u bepalen welke vertakkingen deelnemen aan het algehele proces. U wilt bijvoorbeeld het project bouwen wanneer er een wijziging wordt aangebracht in een vertakking. Een geplande trigger start een implementatie op een bepaald tijdstip. Met een trigger voor voltooiing van de build wordt een build uitgevoerd wanneer een andere build, zoals een voor een afhankelijk onderdeel, is voltooid. Het lijkt erop dat we een geplande trigger willen.

Wat zijn geplande triggers?

Een geplande trigger maakt gebruik van cron-syntaxis om ervoor te zorgen dat een build volgens een gedefinieerd schema wordt uitgevoerd.

Op Unix- en Linux-systemen is cron een populaire manier om taken te plannen om te worden uitgevoerd op een bepaald tijdsinterval of op een bepaald tijdstip. In Azure Pipelines gebruiken geplande triggers de cron-syntaxis om te definiëren wanneer een fase wordt uitgevoerd.

Een cron-expressie bevat velden die overeenkomen met bepaalde tijdparameters. Dit zijn de velden:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Deze cron-expressie beschrijft bijvoorbeeld '3 uur per dag': 0 3 * * *

Een cron-expressie kan speciale tekens bevatten om een lijst met waarden of een bereik met waarden op te geven. In dit voorbeeld komt het sterretje (*) overeen met alle waarden voor de velden Dagen, Maanden en Dagen van week .

Op een andere manier wordt deze cron-expressie gelezen als:

Op minuut 0,
Op het derde uur,
Op elke dag van de maand,
Op elke maand,
Op elke dag van de week,
De taak uitvoeren

Als u 3:00 uur alleen op dagen maandag tot en met vrijdag wilt opgeven, gebruikt u deze expressie: 0 3 * * 1-5

Notitie

De tijdzone voor cron-schema's is Coordinated Universal Time (UTC), dus in dit voorbeeld verwijst 3:00 uur naar 3:00 uur in UTC. In de praktijk wilt u mogelijk de tijd in uw cron-planning aanpassen ten opzichte van UTC, zodat de pijplijn op het verwachte tijdstip voor u en uw team wordt uitgevoerd.

Als u een geplande trigger wilt instellen in Azure Pipelines, hebt u een schedules sectie in uw YAML-bestand nodig. Hier volgt een voorbeeld:

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

In deze schedules sectie:

cron hiermee geeft u de cron-expressie.
branches geeft aan om alleen te implementeren vanuit de release vertakking.
always geeft aan of de implementatie onvoorwaardelijke () moet worden uitgevoerd oftrue alleen wanneer de release vertakking is gewijzigd sinds de laatste uitvoering (false). Hier geeft u op false , omdat u alleen moet implementeren wanneer de release vertakking is gewijzigd sinds de laatste uitvoering.

De hele pijplijn wordt uitgevoerd wanneer Azure Pipelines een geplande trigger uitvoert. De pijplijn wordt ook uitgevoerd onder andere omstandigheden, bijvoorbeeld wanneer u een wijziging naar GitHub pusht. Als u een fase alleen wilt uitvoeren als reactie op een geplande trigger, kunt u een voorwaarde gebruiken waarmee wordt gecontroleerd of de reden voor de build een geplande uitvoering is.

Hier volgt een voorbeeld:

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

Deze fase, wordt Testalleen uitgevoerd wanneer de vorige fase slaagt en de ingebouwde Build.Reason pijplijnvariabele gelijk is Scheduleaan .

Verderop in deze module ziet u een uitgebreider voorbeeld.

Amita: Ik vind dit leuk. Ik hoef de release niet eens handmatig op te halen en te installeren. Het is klaar voor mij.

Andy: En vergeet niet, als we later meer willen automatiseren, kunnen we dat. Er is niets in steen geschreven. De pijplijn ontwikkelt zich naarmate we verbeteren en leren.

De fase Fasering toevoegen

Tim: Het is mijn beurt. Ik heb een fase nodig om meer stresstests uit te voeren. We hebben ook een fase nodig waarin we het beheer kunnen demo's uitvoeren om hun goedkeuring te krijgen. Voorlopig kunnen we deze twee behoeften combineren tot een fase die we Fasering kunnen aanroepen.

Andy: Nou zei, Tim. Het is belangrijk om een faserings- of preproductieomgeving te hebben. Deze faseringsomgeving is vaak de laatste stop voordat een functie of bugfix onze gebruikers bereikt.

Mara voegt Staging toe aan haar tekening op het whiteboard.

Diagram where the whiteboard is showing the Build, Dev, Test, and Staging stages. The Staging stage deploys the build to Azure App Service.

Amita: We gebruiken een geplande trigger om wijzigingen van de Dev-fase naar de testfase te promoten. Maar hoe promoveren we wijzigingen van Test naar Fasering? Moet die promotie ook volgens een schema plaatsvinden?

Mara: Ik denk dat de beste manier om dit te verwerken een goedkeuring voor de release zou zijn. Met een releasegoedkeuring kunt u handmatig een wijziging van de ene fase naar de volgende fase verhogen.

Amita: Dat klinkt precies wat ik nodig heb! Een releasegoedkeuring geeft me de tijd om de meest recente wijzigingen te testen voordat we de build aan het beheer presenteren. Ik kan de build promoveren als ik klaar ben.

Mara werkt haar tekening bij om aan te geven dat de build alleen van Test naar Fasering wordt verplaatst wanneer Amita deze goedkeurt.

Diagram where the whiteboard shows the Build, Dev, Test, and Staging stages. Changes move from Test to Staging only after approval.

Tim: Ik kan me ook voorstellen dat we releasegoedkeuringen gebruiken om te promoveren van fasering naar productie nadat het management zich heeft afgetekend. Ik kan nooit voorspellen hoe lang dat duurt. Nadat ze zich hebben afgemeld, kan ik de release goedkeuren en deze handmatig naar productie promoveren. Maar hoe werken goedkeuringen voor de release?

Wat zijn goedkeuringen voor de release?

Een releasegoedkeuring is een manier om de pijplijn te onderbreken totdat een fiatteur de release accepteert of weigert. Als u uw releasewerkstroom wilt definiëren, kunt u goedkeuringen, voorwaarden en triggers combineren.

Zoals u weet, hebt u in Een release-pijplijn met Azure Pipelines een omgeving gedefinieerd in uw pijplijnconfiguratie die uw implementatieomgeving vertegenwoordigt. Hier volgt een voorbeeld van uw bestaande pijplijn:

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

Uw omgeving kan specifieke criteria voor uw release bevatten. De criteria kunnen opgeven welke pijplijnen in die omgeving kunnen worden geïmplementeerd en welke menselijke goedkeuringen nodig zijn om de release van de ene fase naar de volgende te bevorderen.

Verderop in deze module definieert u de faseringsomgeving en wijst u uzelf toe als fiatteur om de Space Game-web-app te promoten van de testfase naar fasering.

Automatiseren zo weinig of zoveel als u nodig hebt

Azure Pipelines biedt u de flexibiliteit om bepaalde fasen te automatiseren terwijl u fasen handmatig beheert die niet gereed zijn voor automatisering.

Tim: Ik vind het leuk om de criteria te definiëren waarmee wijzigingen van de ene fase naar de volgende worden bevorderd. Maar we hebben enkele handmatige criteria gedefinieerd in onze pijplijn. Ik dacht dat DevOps over het automatiseren van alles ging.

Mara: Je verhef een goed punt. DevOps gaat echt over het automatiseren van terugkerende en foutgevoelige taken. Soms is menselijke interventie noodzakelijk. We krijgen bijvoorbeeld goedkeuring van beheer voordat we nieuwe functies vrijgeven. Naarmate we meer ervaring krijgen met onze geautomatiseerde implementaties, kunnen we meer van onze handmatige stappen automatiseren om het proces te versnellen. We kunnen bijvoorbeeld meer kwaliteitscontroles automatiseren in de testfase , zodat Amita niet elke build hoeft goed te keuren.

Tim: Klinkt geweldig. Laten we dit plan nu gaan gebruiken en kijken hoe we het systeem later kunnen versnellen.

Amita: Over ons plan gesproken, kunnen we onze volgende stappen samenvatten?

Het plan

Laten we het plan van het Tailspin-team bekijken terwijl ze naar de volgende stappen gaan.

Mara: Dit is de release-pijplijn die we willen bouwen.

Mara wijst naar het whiteboard.

Diagram of the final whiteboard showing the Build, Dev, Test, and Staging stages.

Mara: Om samen te vatten, zijn onze stappen voor het volgende:

Een build-artefact produceren telkens wanneer we een wijziging naar GitHub pushen. Deze stap vindt plaats in de buildfase .
Promoot het buildartefact naar de ontwikkelfase . Deze stap vindt automatisch plaats wanneer de buildfase slaagt en de wijziging zich in de releasebranch bevindt.
Promoot het buildartefact elke ochtend om 3:00 uur naar de testfase . We gebruiken een geplande trigger om het build-artefact automatisch te promoten.
Promoveer het build-artefact naar Fasering na amita-tests en keurt de build goed. We gebruiken een releasegoedkeuring om het build-artefact te promoten.

Nadat het beheer de build goedkeurt, kunnen we het build-artefact implementeren in een productieomgeving.

Amita: Is dit moeilijk te doen? Het lijkt veel werk.

Mara: Ik denk niet dat het jammer is. Elke fase staat los van elke andere fase. Fasen zijn discreet. Elke fase heeft een eigen set taken. Wat er bijvoorbeeld gebeurt in de testfase blijft in de testfase .

Elke implementatiefase in onze pijplijn heeft ook een eigen omgeving. Wanneer we de app bijvoorbeeld implementeren in Dev of Test, is de omgeving een App Service-exemplaar.

Ten slotte testen we slechts één release tegelijk. We veranderen nooit releases in het midden van de pijplijn. We gebruiken dezelfde release in de Dev-fase als in de fase Fasering en elke release heeft een eigen versienummer. Als de release in een van de fasen wordt onderbreekt, lossen we deze op en bouwen we deze opnieuw met een nieuw versienummer. Die nieuwe release gaat vervolgens vanaf het begin door de pijplijn.

Een paar woorden over kwaliteit

U hebt zojuist gezien dat het team een pijplijn ontwerpt waarmee de app helemaal van build naar fasering wordt geleid. Het hele punt van deze pijplijn is niet alleen om hun leven gemakkelijker te maken. Het is om de kwaliteit van de software te garanderen die ze aan hun klanten leveren.

Hoe meet u de kwaliteit van uw releaseproces? De kwaliteit van uw releaseproces kan niet rechtstreeks worden gemeten. Wat u kunt meten is hoe goed uw proces werkt. Als u het proces voortdurend wijzigt, kan het een indicatie zijn dat er iets mis is. Releases die consistent mislukken op een bepaald punt in de pijplijn kunnen ook aangeven dat er een probleem is met het releaseproces.

Mislukken de releases altijd op een bepaalde dag of tijd? Mislukken ze altijd nadat u naar een bepaalde omgeving hebt geïmplementeerd? Zoek naar deze en andere patronen om te zien of sommige aspecten van het releaseproces afhankelijk of gerelateerd zijn.

Een goede manier om de kwaliteit van het releaseproces bij te houden, is door visualisaties te maken van de kwaliteit van de releases. Voeg bijvoorbeeld een dashboardwidget toe die de status van elke release weergeeft.

Wanneer u de kwaliteit van een release zelf wilt meten, kunt u allerlei soorten controles uitvoeren binnen de pijplijn. U kunt bijvoorbeeld verschillende soorten tests uitvoeren, zoals belastingstests en UI-tests tijdens het uitvoeren van uw pijplijn.

Het gebruik van een kwaliteitspoort is ook een uitstekende manier om de kwaliteit van uw release te controleren. Er zijn veel verschillende kwaliteitspoorten. Werkitempoorten kunnen bijvoorbeeld de kwaliteit van uw vereistenproces controleren. U kunt ook meer beveiligings- en nalevingscontroles toevoegen. Voldoet u bijvoorbeeld aan het principe van vier ogen of hebt u de juiste traceerbaarheid?

Tijdens het doorlopen van dit leertraject ziet u veel van deze technieken in de praktijk.

Als u ten slotte een kwaliteitsreleaseproces ontwerpt, moet u nadenken over het soort documentatie of opmerkingen bij de release die u aan de gebruiker moet verstrekken. Het kan lastig zijn om uw documentatie actueel te houden. U kunt overwegen om een hulpprogramma te gebruiken, zoals de Azure DevOps Release Notes Generator. De generator is een functie-app die een door HTTP geactiveerde functie bevat. Met behulp van Azure Blob Storage wordt een Markdown-bestand gemaakt wanneer er een nieuwe release wordt gemaakt in Azure DevOps.

Test uw kennis

Uw pijplijn bevat veel tests en kwaliteitscontroles die enkele minuten duren. Welk type trigger is het beste voor het uitvoeren van tests alleen voor code die is beoordeeld door peers?

Een trigger voor het voltooien van een build

Een CI-trigger of PR-trigger

Een geplande trigger

Wat is de beste manier om de pijplijn te onderbreken totdat een fiatteur zich afmeldt bij een wijziging?

Gebruik een goedkeuring voor de release.

Installeer een Marketplace-extensie die Azure Pipelines-taken biedt waarmee de pijplijn kan worden onderbroken.

Vraag uw fiatteur om de wijziging te bekijken. Vervolgens activeert u de pijplijn handmatig om uit te voeren.

U wilt uw web-app implementeren in de testomgeving telkens wanneer een build is voltooid. Wat is de eenvoudigste manier om het proces in te stellen?

Gebruik een geplande trigger.

Let op e-mailberichten voor buildmeldingen en activeer uw build handmatig wanneer de andere is voltooid.

Gebruik een trigger voor het voltooien van de build.

U moet alle vragen beantwoorden voordat uw werk kan worden gecontroleerd.