Werkstroomtaken begrijpen

Voltooid

Met werkstromen kunt u de stappen in uw implementatieproces automatiseren. Uw proces kan verschillende logische groepen taken bevatten die u wilt uitvoeren. In deze les leert u meer over werkstroomtaken en hoe u deze gebruikt om kwaliteitsbeheerprocessen toe te voegen aan uw Bicep-implementaties.

Wat zijn werkstroomtaken?

Met taken kunt u uw werkstroom opsplitsen in meerdere logische blokken. Elke taak kan een of meer stappen bevatten.

Diagram met een werkstroom met één taak. De taak bevat vier stappen.

Taken kunnen in uw werkstroom worden gebruikt om een scheiding van problemen te markeren. Wanneer u bijvoorbeeld met Bicep-code werkt, is het valideren van de code een afzonderlijke kwestie van het implementeren van uw Bicep-bestand. Wanneer u een geautomatiseerde werkstroom gebruikt, worden het bouwen en testen van uw code vaak continue integratie (CI) genoemd. Het implementeren van code in een geautomatiseerde werkstroom wordt vaak continue implementatie (CD) genoemd.

In CI-taken controleert u de geldigheid van de wijzigingen die zijn aangebracht in uw code. CI-taken bieden kwaliteitscontrole. Ze kunnen worden uitgevoerd zonder dat dit van invloed is op uw live productieomgeving.

In veel programmeertalen moet code worden gebouwd voordat iemand deze kan uitvoeren. Wanneer een Bicep-bestand wordt geïmplementeerd, wordt het geconverteerd of getranspileerd, van Bicep naar JSON. Met de hulpprogramma's wordt dit proces automatisch uitgevoerd. In de meeste gevallen hoeft u bicep-code niet handmatig te bouwen voor JSON-sjablonen in uw werkstroom. We gebruiken echter nog steeds de term continue integratie als we het hebben over Bicep-code, omdat de andere onderdelen van CI nog steeds van toepassing zijn, zoals het valideren van uw code.

Nadat uw CI-taken zijn uitgevoerd, moet u meer vertrouwen krijgen dat de wijzigingen die u hebt aangebracht, ook worden geïmplementeerd. In CD-taken implementeert u uw code in elk van uw omgevingen. Meestal begint u met testomgevingen en andere niet-productieomgevingen en gaat u vervolgens door naar productieomgevingen. In deze module implementeren we in één omgeving. In een toekomstige module leert u hoe u uw implementatiewerkstroom kunt uitbreiden om te implementeren in meerdere omgevingen, zoals niet-productie- en productieomgevingen.

Taken worden standaard parallel uitgevoerd. U kunt bepalen hoe en wanneer elke taak wordt uitgevoerd. U kunt bijvoorbeeld uw CD-taken zo configureren dat ze alleen worden uitgevoerd nadat uw CI-taken zijn uitgevoerd. Of u hebt mogelijk meerdere CI-taken die op volgorde moeten worden uitgevoerd, zoals het bouwen van uw code en het testen. U kunt ook een terugdraaitaak opnemen die alleen wordt uitgevoerd als eerdere implementatietaken zijn mislukt.

Naar links verschuiven

Door taken te gebruiken, kunt u de kwaliteit van uw code controleren voordat u deze implementeert. Dit proces wordt ook wel verschuiving naar links genoemd.

Houd rekening met een tijdlijn van de activiteiten die u uitvoert wanneer u code schrijft. De tijdlijn begint met de plannings- en ontwerpfasen. Vervolgens gaat het over naar de bouw- en testfasen. Ten slotte implementeert en moet u vervolgens uw oplossing ondersteunen.

Grafiek met een tijdlijn op de horizontale as, kosten op de verticale as en een lijn die laat zien dat de kosten later een fout verhogen.

Het is een goed begrepen regel in softwareontwikkeling die u eerder in het proces hebt gevonden, hoe dichter bij de tijdlijn, hoe eenvoudiger, sneller en goedkoper het is om dit probleem op te lossen. Hoe later in uw proces u een fout onderschept, hoe moeilijker en ingewikkelder het wordt om te herstellen.

Het doel is dus om de detectie van problemen naar de linkerkant van het voorgaande diagram te verplaatsen. In deze module ziet u hoe u tijdens de voortgang meer validatie en tests kunt toevoegen aan uw werkstroom.

U kunt zelfs validatie goed toevoegen voordat de implementatie begint. Wanneer u met hulpprogramma's zoals GitHub werkt, vertegenwoordigen pull-aanvragen doorgaans wijzigingen die iemand in uw team wil aanbrengen in de code in uw hoofdbranch. Het is handig om een andere werkstroom te maken waarmee uw CI-stappen automatisch worden uitgevoerd tijdens het beoordelingsproces voor de pull-aanvraag. Met deze techniek kunt u controleren of de code nog steeds werkt, zelfs met de voorgestelde wijzigingen. Als de validatie slaagt, hebt u er vertrouwen in dat de wijziging geen problemen veroorzaakt wanneer deze wordt samengevoegd met uw hoofdbranch. Als de controle mislukt, weet u dat er meer werk moet worden verricht voordat de pull-aanvraag gereed is om samen te voegen. In een toekomstige module leert u meer over het instellen van een correct releaseproces met behulp van pull-aanvragen en vertakkingsstrategieën.

Belangrijk

Geautomatiseerde validatie en tests zijn alleen zo effectief als de tests die u schrijft. Het is belangrijk om rekening te houden met de dingen die u moet testen en de stappen die u moet uitvoeren om er zeker van te zijn dat uw implementatie in orde is.

Een werkstroomtaak definiëren

Elke werkstroom bevat ten minste één taak en u kunt meer taken definiëren die aan uw vereisten voldoen. Taken worden standaard parallel uitgevoerd. Het type GitHub-account dat u hebt, bepaalt het aantal taken dat u tegelijkertijd kunt uitvoeren wanneer u door GitHub gehoste hardlopers gebruikt.

Stel dat u een Bicep-bestand hebt gemaakt dat u twee keer moet implementeren: eenmaal naar infrastructuur in de Verenigde Staten en eenmaal naar infrastructuur in Europa. U wilt uw Bicep-code ook valideren in uw werkstroom. Hier volgt een afbeelding van een werkstroom met meerdere taken die een vergelijkbaar proces definieert:

Diagram met een werkstroom met een validatietaak, een U S-taak implementeren en een Taak Europa implementeren, die parallel wordt uitgevoerd.

U ziet dat dit voorbeeld drie taken heeft. De validatietaak is vergelijkbaar met een CI-taak. Vervolgens worden de taken Vs implementeren en Europa implementeren uitgevoerd. Elke implementeert de code in een van de omgevingen. Standaard worden de taken parallel uitgevoerd.

De taken worden als volgt gedefinieerd in een YAML-werkstroombestand:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

De volgorde van taken beheren

U kunt afhankelijkheden tussen de taken toevoegen om de volgorde te wijzigen. Als u doorgaat met het vorige voorbeeld, wilt u waarschijnlijk uw code valideren voordat u uw implementatietaken uitvoert, zoals hieronder:

Diagram met een werkstroom met een taak Valideren, een U S-taak implementeren en een Taak Europa implementeren, waarbij de twee implementatietaken parallel worden uitgevoerd.

U kunt de afhankelijkheden tussen taken opgeven met behulp van het needs trefwoord:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Wanneer u het needs trefwoord gebruikt, wacht de werkstroom totdat de afhankelijke taak is voltooid voordat de volgende taak wordt gestart. Als de werkstroom detecteert dat aan alle afhankelijkheden voor meerdere taken is voldaan, kunnen deze taken parallel worden uitgevoerd.

Notitie

In werkelijkheid worden taken alleen parallel uitgevoerd als u voldoende hardlopers hebt om meerdere taken tegelijk uit te voeren. Het aantal door GitHub gehoste hardlopers dat u kunt gebruiken, is afhankelijk van het type GitHub-account dat u hebt. U kunt een ander GitHub-accountabonnement aanschaffen als u meer parallelle taken nodig hebt.

Soms wilt u een taak uitvoeren wanneer een vorige taak mislukt. Hier volgt bijvoorbeeld een andere werkstroom. Als de implementatie mislukt, wordt een taak met de naam rollback direct daarna uitgevoerd:

Diagram waarin een werkstroom met een implementatietaak en een voorwaarde wordt weergegeven, zodat een fout in de implementatietaak resulteert in het uitvoeren van de terugdraaitaak.

U gebruikt het if trefwoord om een voorwaarde op te geven waaraan moet worden voldaan voordat een taak wordt uitgevoerd:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deploy: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy."
  rollback: 
    runs-on: ubuntu-latest
    needs: deploy
    if: ${{ failure() }}
    steps:
      - run: echo "Here is where you'd perform the steps to roll back a failure."

Wanneer alles goed gaat, wordt in het voorgaande voorbeeld eerst de testtaak uitgevoerd en vervolgens wordt de implementatietaak uitgevoerd. Hiermee wordt de terugdraaitaak overgeslagen. Als de test- of implementatietaak echter mislukt, voert de werkstroom de terugdraaitaak uit. Verderop in deze module vindt u meer informatie over terugdraaien.

Bicep-implementatietaken

Een typische Bicep-implementatiewerkstroom bevat verschillende taken. Naarmate de werkstroom door de taken loopt, is het doel om steeds meer vertrouwen te krijgen dat de latere taken slagen. Hier volgen de algemene taken voor een Bicep-implementatiewerkstroom:

Diagram met een Bicep-implementatiewerkstroom met vijf taken: Lint, Valideren, Preview, Implementeren en Betrouwbaarheidstest.

  1. Lint: Gebruik bicep linter om te controleren of het Bicep-bestand goed is gevormd en geen duidelijke fouten bevat.
  2. Valideren: Gebruik het preflightvalidatieproces van Azure Resource Manager om te controleren op problemen die kunnen optreden wanneer u implementeert.
  3. Preview: Gebruik de what-if-opdracht om de lijst met wijzigingen te valideren die worden toegepast op uw Azure-omgeving. Vraag een mens om de wat-als-resultaten handmatig te bekijken en de werkstroom goed te keuren om door te gaan.
  4. Implementeren: Verzend uw implementatie naar Resource Manager en wacht tot deze is voltooid.
  5. Betrouwbaarheidstest: voer eenvoudige controles na de implementatie uit op een aantal belangrijke resources die u hebt geïmplementeerd. Deze controles worden betrouwbaarheidstests van infrastructuur genoemd.

Uw organisatie kan een andere reeks taken hebben of u moet uw Bicep-implementaties integreren in een werkstroom waarmee andere onderdelen worden geïmplementeerd. Nadat u hebt begrepen hoe de taken werken, kunt u een werkstroom ontwerpen die aan uw behoeften voldoet.

Elke taak wordt uitgevoerd op een nieuw runner-exemplaar dat begint vanuit een schone omgeving. In elke taak moet u de broncode dus meestal als eerste stap uitchecken. U moet zich ook aanmelden bij uw Azure-omgeving in elke taak die communiceert met Azure.

In deze module leert u meer over deze taken en bouwt u geleidelijk een werkstroom met elke taak. U leert ook het volgende:

  • Hoe werkstromen het implementatieproces stoppen als er iets onverwachts gebeurt in een van de vorige taken.
  • De werkstroom zo configureren dat deze wordt onderbroken totdat u handmatig controleert wat er in een vorige taak is gebeurd.