Delen via

Goedkeuringen en controles definiëren

  • Artikel

Azure DevOps Services

Een pijplijn bestaat uit fasen. Een auteur van een pijplijn kan bepalen of een fase moet worden uitgevoerd door voorwaarden voor de fase te definiëren. Een andere manier om te bepalen of en wanneer een fase moet worden uitgevoerd, is via goedkeuringen en controles.

Goedkeuringen en andere controles worden niet gedefinieerd in het yaml-bestand. Gebruikers die het yaml-bestand voor de pijplijn wijzigen, kunnen de controles die vóór het begin van een fase worden uitgevoerd, niet wijzigen. Beheerders van resources beheren controles met behulp van de webinterface van Azure Pipelines.

Pijplijnen zijn afhankelijk van resources zoals omgevingen, serviceverbindingen, agentgroepen, variabele groepen en beveiligde bestanden. Met controles kan de eigenaar van de resource bepalen of en wanneer een fase in een pijplijn een resource kan verbruiken. Als eigenaar van een resource kunt u controles definiëren waaraan moet worden voldaan voordat een fase die die resource verbruikt, kan worden gestart. Een handmatige goedkeuringscontrole in een omgeving zorgt er bijvoorbeeld voor dat de implementatie naar die omgeving alleen plaatsvindt nadat de aangewezen gebruiker de wijzigingen controleert die worden geïmplementeerd.

Een fase kan bestaan uit veel taken en elke taak kan verschillende resources verbruiken. Voordat de uitvoering van een fase kan beginnen, moeten alle controles op alle resources die in die fase worden gebruikt, worden gecontroleerd. Azure Pipelines onderbreekt de uitvoering van een pijplijn voor elke fase en wacht totdat alle controles in behandeling zijn voltooid.

Er zijn vijf categorieën goedkeuringen en controles en ze worden uitgevoerd in de volgorde waarin ze binnen elke categorie zijn gemaakt. Controles worden opnieuw geëvalueerd op basis van het interval voor opnieuw proberen dat in elke controle is opgegeven. Als alle controles pas zijn geslaagd als de opgegeven time-out is opgegeven, wordt die fase niet uitgevoerd. Als een van de controles terminal mislukt (bijvoorbeeld als u een goedkeuring voor een van de resources weigert), wordt die fase niet uitgevoerd.

U kunt een fase opnieuw proberen wanneer er een time-out optreedt voor goedkeuringen en controles.

Statische controles worden eerst uitgevoerd en vervolgens worden goedkeuringen vooraf gecontroleerd. De categorieën in volgorde zijn:

  1. Statische controles: Vertakkingsbeheer, vereiste sjabloon en artefact evalueren
  2. Goedkeuringen vooraf controleren
  3. Dynamische controles: Goedkeuring, Azure-functie aanroepen, REST API aanroepen, kantooruren, Azure Monitor-waarschuwingen opvragen
  4. Goedkeuringen na controle
  5. Exclusief slot

U kunt ook de uitvoeringsvolgorde zien op het tabblad Goedkeuringen en Controles .

Belangrijk

Controles kunnen worden geconfigureerd voor omgevingen, serviceverbindingen, opslagplaatsen, variabele groepen, beveiligde bestanden en agentpools.

Serviceverbindingen kunnen niet worden opgegeven met een variabele.

Goedkeuringen

U kunt handmatig bepalen wanneer een fase moet worden uitgevoerd met behulp van goedkeuring en controles. Deze controle wordt vaak gebruikt om implementaties naar productieomgevingen te beheren.

  1. Meld u aan bij uw Azure DevOps-organisatie en navigeer vervolgens naar uw project.

  2. Selecteer Pipelines>Environments en selecteer vervolgens uw omgeving.

  3. Selecteer het tabblad Goedkeuringen en controles en selecteer vervolgens het + teken om een nieuwe controle toe te voegen.

    Een schermopname van het toevoegen van goedkeuringen en controles in Azure Pipelines.

  4. Selecteer Goedkeuringen en selecteer vervolgens Volgende.

  5. Voeg gebruikers of groepen toe als uw aangewezen goedkeurders en geef desgewenst instructies voor de goedkeurders. Geef op of u goedkeurders wilt toestaan of beperken dat ze hun eigen uitvoeringen goedkeuren en geef de gewenste time-out op. Als goedkeuringen niet zijn voltooid binnen de opgegeven time-out, wordt de fase gemarkeerd als overgeslagen.

  6. Selecteer Maken wanneer u klaar bent.

    Een schermopname die laat zien hoe u een nieuwe goedkeuring maakt.

  7. Zodra de goedkeuringscontrole is geactiveerd, wordt er een promptvenster weergegeven, zoals in het volgende voorbeeld wordt weergegeven in de gebruikersinterface. Dit venster biedt de mogelijkheid voor goedkeurders om de uitvoering te weigeren of goed te keuren, samen met eventuele bijbehorende instructies.

    Een schermopname van het venster goedkeuringsprompt.

De lijst met gebruikers die een goedkeuring kunnen controleren, is vastgesteld op het moment dat goedkeuringen en controles worden uitgevoerd. Dat wil gezegd: wijzigingen in de lijst met gebruikers en groepen van een goedkeuringscontrole die is uitgevoerd nadat de controles die worden uitgevoerd, niet worden opgehaald.

Notitie

Als een groep is aangewezen als fiatteur, hoeft slechts één gebruiker binnen de groep de uitvoering goed te keuren om door te gaan.

Uitgestelde goedkeuringen

Er zijn situaties waarin het tijdstip waarop een goedkeuring wordt gegeven en de tijd waarop de implementatie moet worden gestart, niet overeenkomt. U kunt bijvoorbeeld wachten om een nieuwe release te implementeren totdat er 's avonds weinig verkeer is.

Om dit scenario aan te pakken, kunt u een goedkeuring uitstellen en de tijd instellen waarop de goedkeuring van kracht wordt.

  1. Selecteer Goedkeuring uitstellen.

    Schermopname van de goedkeuringsoptie uitstellen wanneer u op een goedkeuringsaanvraag reageert.

  2. Stel de goedkeuringstijd in.

    Schermopname van het instellen van de tijd voor een goedkeuring.

U ziet de goedkeuring in het deelvenster Controles als een voorafgaande goedkeuring. De goedkeuring is van kracht op het ingestelde tijdstip.

Vertakkingsbeheer

Met behulp van de controle van het vertakkingsbeheer kunt u ervoor zorgen dat alle resources die zijn gekoppeld aan de pijplijn zijn gebouwd op basis van de toegestane vertakkingen en dat de vertakkingen beveiliging hebben ingeschakeld. Deze controle helpt bij het beheren van de gereedheid en kwaliteit van de release van implementaties. Als er meerdere resources aan de pijplijn zijn gekoppeld, wordt de bron voor alle resources geverifieerd. Als u een andere pijplijn hebt gekoppeld, wordt de vertakking van de specifieke uitvoering die wordt geïmplementeerd, gecontroleerd op beveiliging.

De controle van het vertakkingsbeheer definiëren:

  1. Ga in uw Azure DevOps-project naar de resource (bijvoorbeeld omgeving) die moet worden beveiligd.

  2. Navigeer naar Goedkeuringen en Controles voor de resource.

  3. Kies de controle branch en geef een door komma's gescheiden lijst met toegestane vertakkingen op. U kunt verplicht stellen dat de vertakking beveiliging moet hebben ingeschakeld. U kunt ook het gedrag van de controle definiëren als de beveiligingsstatus voor een van de vertakkingen niet bekend is. Een vertakking wordt als beveiligd beschouwd als er ten minste één beleid is toegepast (inclusief beleidsregels die op het niveau van de opslagplaats worden toegepast).

    Controle van vertakkingsbeheer configureren.

Tijdens runtime valideert de controle vertakkingen voor alle gekoppelde resources in de uitvoering op basis van de toegestane lijst. Als een van de vertakkingen niet aan de criteria voldoet, mislukt de controle en wordt de fase gemarkeerd als mislukt.

Notitie

Voor de controle moeten de namen van de vertakkingen volledig zijn gekwalificeerd. Zorg ervoor dat de indeling voor de naam van de vertakking is refs/heads/<branch name>

Kantooruren

Als u wilt dat alle implementaties in uw omgeving alleen in een bepaald tijdvenster plaatsvinden, is de controle van kantooruren de ideale oplossing. Wanneer u een pijplijn uitvoert, wacht de uitvoering van de fase die gebruikmaakt van de resource tot kantooruren. Als u meerdere uitvoeringen tegelijk uitvoert, wordt elk ervan onafhankelijk gecontroleerd. Aan het begin van de kantooruren wordt de controle gemarkeerd als geslaagd voor alle uitvoeringen.

Controle van kantooruren configureren.

Als de uitvoering van de fase niet is gestart aan het einde van kantooruren (vastgehouden door een andere controle), wordt de goedkeuring van kantooruren automatisch ingetrokken en wordt een herwaardering gepland voor de volgende dag. De controle mislukt als de uitvoering van de fase niet start binnen de time-outperiode die is opgegeven voor de controle en de fase is gemarkeerd als mislukt.

Azure-functie aanroepen

Azure-functies zijn het serverloze rekenplatform dat wordt aangeboden door Azure. Met Azure-functies kunt u kleine stukjes code (ook wel 'functies' genoemd) uitvoeren zonder dat u zich zorgen hoeft te maken over de toepassingsinfrastructuur. Gezien de hoge flexibiliteit bieden Azure-functies een uitstekende manier om uw eigen controles te ontwerpen. U neemt de logica van de check-in Azure-functie op, zodat elke uitvoering wordt geactiveerd op een HTTP-aanvraag, een korte uitvoeringstijd heeft en een antwoord retourneert. Tijdens het definiëren van de controle kunt u de hoofdtekst van het antwoord parseren om af te stellen of de controle is geslaagd. De evaluatie kan periodiek worden herhaald met behulp van de instelling Tijd tussen evaluaties in besturingsopties. Meer informatie

Azure-functiecontrole configureren.

Als uw controle niet lukt binnen de geconfigureerde time-out, wordt de bijbehorende fase overgeslagen. Fasen, afhankelijk van het, worden ook overgeslagen. Zie de azure-functie-app-taak voor meer informatie.

Notitie

Door de gebruiker gedefinieerde pijplijnvariabelen zijn toegankelijk voor de controle vanaf Sprint 215.

Lees meer over de aanbevolen manier om Azure-functiecontroles aan te roepen. Controles moeten specifieke regels volgen, afhankelijk van hun modus en het aantal nieuwe pogingen dat aan het beleid voldoet.

REST-API intrekken

Door REST API-controle aan te roepen, kunt u integreren met een van uw bestaande services. Maak periodiek een aanroep naar een REST API en ga door als er een geslaagd antwoord wordt geretourneerd. Meer informatie

De evaluatie kan periodiek worden herhaald met behulp van de instelling Tijd tussen evaluaties in besturingsopties. Als uw controle niet lukt binnen de geconfigureerde time-out, wordt de bijbehorende fase overgeslagen. Fasen, afhankelijk van het, worden ook overgeslagen. Zie REST API-taak aanroepen voor meer informatie.

Notitie

Door de gebruiker gedefinieerde pijplijnvariabelen zijn toegankelijk voor de controle vanaf Sprint 215.

Lees meer over de aanbevolen manier om REST API-controles aan te roepen.

Query's uitvoeren op Azure Monitor-waarschuwingen

Azure Monitor biedt visualisaties, query's, routering, waarschuwingen, automatisch schalen en automatisering van gegevens uit de Azure-infrastructuur en elke afzonderlijke Azure-resource. Waarschuwingen zijn een standaardmethode om problemen met de status van infrastructuur of toepassing te detecteren en corrigerende acties uit te voeren. Canary-implementaties en gefaseerde implementaties zijn veelgebruikte implementatiestrategieën die worden gebruikt om het risico op regressies voor kritieke toepassingen te verlagen. Na de implementatie in een fase (set klanten) wordt de toepassing gedurende een bepaalde periode waargenomen. Status van de toepassing nadat de implementatie is gebruikt om te bepalen of de update moet worden uitgevoerd in de volgende fase of niet.

Query's uitvoeren op Azure Monitor-waarschuwingen helpt u bij het observeren van Azure Monitor en ervoor te zorgen dat er na een implementatie geen waarschuwingen worden gegenereerd voor de toepassing. De controle slaagt als er geen waarschuwingsregels worden geactiveerd op het moment van evaluatie. Meer informatie

De evaluatie wordt herhaald na de tijd tussen de evaluatie-instelling in besturingsopties. De controles mislukken als de fase de uitvoering niet heeft gestart binnen de opgegeven time-outperiode .

Vereiste sjabloon

Met de vereiste sjablooncontrole kunt u pijplijnen afdwingen om een specifieke YAML-sjabloon te gebruiken. Wanneer deze controle is uitgevoerd, mislukt een pijplijn als deze niet wordt uitgebreid vanuit de sjabloon waarnaar wordt verwezen.

Een vereiste sjabloongoedkeuring definiëren:

  1. Ga in uw Azure DevOps-project naar de serviceverbinding die u wilt beperken.

  2. Open Goedkeuringen en Controles in het menu naast Bewerken.

  3. Selecteer De vereiste sjabloon in het menu Uw eerste controle toevoegen.

  4. Voer details in over het ophalen van het vereiste sjabloonbestand.

    • Type opslagplaats: de locatie van uw opslagplaats (GitHub, Azure of Bitbucket).
    • Opslagplaats: de naam van uw opslagplaats die uw sjabloon bevat.
    • Verw: De vertakking of tag van de vereiste sjabloon.
    • Pad naar de vereiste sjabloon: de naam van de sjabloon.

U kunt meerdere vereiste sjablonen voor dezelfde serviceverbinding hebben. In dit voorbeeld is production_template.yamlde vereiste sjabloon.

Vereiste sjablooncontrole configureren.

Een controle uitschakelen

Wanneer u een controle foutopsporing opspoort, wilt u deze mogelijk tijdelijk uitschakelen en vervolgens weer inschakelen. Een controle uitschakelen of inschakelen:

  1. Ga in uw Azure DevOps-project met een controle naar de resource.

  2. Open het tabblad Goedkeuringen en Controles .

  3. Selecteer In het contextmenu de optie Uitschakelen of Inschakelen.

    Schermopname van het uitschakelen van een selectievakje.

Een controle overslaan

In sommige gevallen, zoals een hotfix-implementatie, moet u mogelijk een controle omzeilen. U kunt alleen een controle overslaan als u de beheerdersmachtiging hebt voor de resource waarin de controle is gedefinieerd.

Als u een goedkeuring, kantooruren wilt overslaan, Een Azure-functie wilt aanroepen of REST API-controle wilt aanroepen, selecteert u Bypass-controle wanneer de resource wacht op beoordeling. Hier volgt een voorbeeld van het omzeilen van de controle van kantooruren.

Schermopname van de controleoptie kantooruren overslaan.

Wanneer u een controle overslaan, ziet u wie de controle heeft overgeslagen in het controlesvenster.

Schermopname van het logboek van een omzeilde controle.

Artefact evalueren

U kunt artefacten evalueren die in een omgeving worden geïmplementeerd op basis van aangepast beleid.

Notitie

Dit werkt momenteel alleen met artefacten voor containerinstallatiekopieën

Volg de onderstaande stappen om een aangepaste beleidsevaluatie voor de artefacten te definiëren.

  1. Navigeer in uw Azure DevOps Services-project naar de omgeving die moet worden beveiligd. Meer informatie over het maken van een omgeving.

    Omgeving weergeven.

  2. Navigeer naar Goedkeuringen en controles voor de omgeving.

    Voeg controles toe aan de omgeving.

  3. Selecteer Artefact evalueren.

    Controle van evaluatieartefact toevoegen.

  4. Plak de beleidsdefinitie en selecteer Opslaan. Meer informatie over het schrijven van beleidsdefinities.

    Beleidsdefinitie toevoegen.

Wanneer u een pijplijn uitvoert, wordt de uitvoering van die uitvoering onderbroken voordat u een fase invoert die gebruikmaakt van de omgeving. Het opgegeven beleid wordt geëvalueerd op basis van de beschikbare metagegevens van de installatiekopieën. De controle wordt doorgegeven wanneer het beleid is geslaagd en mislukt anders. De fase is gemarkeerd als mislukt als de controle mislukt.

Geslaagde controles bekijken.

U kunt ook de volledige logboeken van de beleidscontroles bekijken vanuit de pijplijnweergave.

Geslaagde controlelogboeken weergeven.

Exclusief slot

De exclusieve vergrendelingscontrole staat slechts één uitvoering vanuit de pijplijn toe en kan worden ingesteld op fase- of pijplijnniveau. Alle fasen in alle uitvoeringen van die pijplijn die gebruikmaken van de resource, worden onderbroken. Wanneer de fase met de vergrendeling is voltooid, kan een andere fase doorgaan met het gebruik van de resource. Er mag slechts één fase worden voortgezet.

De lockBehavior eigenschap bepaalt hoe andere fasen vergrendelingen verwerken. Wanneer u de lockBehavior eigenschap voor een fase opgeeft, wordt automatisch een vergrendeling voor die fase gemaakt. Er zijn twee mogelijke lockBehavior waarden:

  • runLatest - Alleen de meest recente uitvoering verkrijgt de vergrendeling voor de resource. runLatest is de standaardwaarde als er geen lockBehavior is opgegeven.
  • sequential - Alle uitvoeringen verkrijgen de vergrendeling op de beveiligde resource sequentieel.

Als u een exclusieve vergrendelingscontrole met sequential implementaties wilt gebruiken, runLatestvoert u de volgende stappen uit:

  1. Schakel de exclusieve vergrendelingscontrole in voor de omgeving (of een andere beveiligde resource). De exclusieve vergrendelingsoptie is een beschikbare controle.

    Schermopname van het tabblad Goedkeuringen van exclusieve vergrendelingsoptie.

  2. Geef in het YAML-bestand voor de pijplijn een eigenschap op met de naam lockBehavior. Dit kan worden opgegeven voor de hele pijplijn of voor een bepaalde fase:

Instellen op een fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Instellen op de pijplijn:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Als u geen en lockBehavior een vergrendeling opgeeft voor een resource, wordt de standaardwaarde gebruikt runLatest .

Met de exclusieve vergrendelingscontrole kan slechts één uitvoering vanuit de pijplijn worden voortgezet. Alle fasen in alle uitvoeringen van die pijplijn die gebruikmaken van de resource, worden onderbroken. Wanneer de fase met de vergrendeling is voltooid, kan een andere fase doorgaan met het gebruik van de resource. Er mag slechts één fase worden voortgezet. Alle andere fasen die proberen de vergrendeling te nemen, worden geannuleerd.

ServiceNow Change Management

Voor deze controles moet de ServiceNow Change Management-extensie worden geïnstalleerd vanuit de marketplace

De controle van servicenow-wijzigingsbeheer maakt een integratie mogelijk van serviceNow-wijzigingsbeheerproces in de pijplijnen. Door de controle toe te voegen, kan er automatisch een nieuwe wijzigingsaanvraag in ServiceNow worden gemaakt aan het begin van de fase. De pijplijn wacht totdat het wijzigingsproces is voltooid voordat de fase wordt gestart. Meer informatie vindt u hier.

Meerdere goedkeuringen en controles

Een fase kan bestaan uit veel taken en elke taak kan verschillende resources verbruiken. Voordat de uitvoering van een fase kan beginnen, moeten alle controles op alle resources die in die fase worden gebruikt, worden gecontroleerd. Azure Pipelines onderbreekt de uitvoering van een pijplijn vóór elke fase en wacht totdat alle controles in behandeling zijn voltooid.

Eén laatste negatieve beslissing zorgt ervoor dat de pijplijn de toegang wordt geweigerd en dat de fase mislukt. De beslissingen van alle goedkeuringen en controles, met uitzondering van het aanroepen van de Azure-functie/REST API en exclusieve vergrendeling , zijn definitief. U kunt de azure-functie/REST API-controles opnieuw uitvoeren.

Wanneer u azure-functie/REST API-controles op de aanbevolen manier gebruikt, zijn hun toegangsbeslissingen ook definitief.

Wanneer u tijd opgeeft tussen evaluaties voor een aanroepende Azure-functie/REST API-controle als niet-nul, is de beslissing van de controle niet definitief. Dit scenario is de moeite waard om te verkennen.

Laten we eens kijken naar een voorbeeld. Stel dat uw YAML-pijplijn een fase heeft die gebruikmaakt van een serviceverbinding. Deze serviceverbinding heeft twee controles geconfigureerd:

  1. Een asynchrone controle, met de naam Externe goedkeuring verleend, die controleert of er een externe goedkeuring wordt gegeven en op de aanbevolen manier wordt geconfigureerd.
  2. Een synchrone controle met de naam Reden van implementatie geldig, waarmee wordt gecontroleerd of de reden van de implementatie geldig is en waarvoor u de tijd tussen evaluaties instelt op 7 minuten.

Een mogelijke uitvoering van controles wordt weergegeven in het volgende diagram. Diagram met de tijdlijn van de uitvoeringen van een asynchrone en een synchrone controle.

In deze uitvoering:

  • Beide controles, externe goedkeuring verleend en implementatiereden geldig, worden tegelijkertijd aangeroepen. De reden van de implementatie is onmiddellijk geldig , maar omdat externe goedkeuring in behandeling is, wordt het opnieuw geprobeerd.
  • Op minuut 7 wordt de reden van de implementatie geldig opnieuw geprobeerd en deze keer wordt deze doorgegeven.
  • Op minuut 15 wordt aanroepen van externe goedkeuring verleend aan Azure Pipelines met een geslaagde beslissing. Beide controles worden nu doorgegeven, dus de pijplijn mag de fase blijven implementeren.

Laten we eens kijken naar een ander voorbeeld, waarbij twee synchrone controles worden uitgevoerd. Stel dat uw YAML-pijplijn een fase heeft die gebruikmaakt van een serviceverbinding. Deze serviceverbinding heeft twee controles geconfigureerd:

  1. Een synchrone controle met de naam Synchronisatiecontrole 1, waarvoor u de tijd tussen evaluaties instelt op 5 minuten.
  2. Een synchrone controle, met de naam Synchronisatiecontrole 2, waarvoor u de tijd tussen evaluaties instelt op 7 minuten.

Een mogelijke uitvoering van controles wordt weergegeven in het volgende diagram. Diagram met de tijdlijn van de uitvoeringen van twee synchrone controles.

In deze uitvoering:

  • Beide controles, Synchronisatiecontrole 1 en Synchronisatiecontrole 2, worden tegelijkertijd aangeroepen. Synchronisatiecontrole 1 wordt doorgegeven, maar het wordt opnieuw geprobeerd, omdat Synchronisatiecontrole 2 mislukt.
  • Op minuut 5 wordt Synchronisatiecontrole 1 opnieuw geprobeerd, maar mislukt, dus het wordt opnieuw geprobeerd.
  • Op minuut 7 wordt Synchronisatiecontrole 2 opnieuw geprobeerd en slaagt. De beslissing over de pas is 7 minuten geldig. Als Synchronisatiecontrole 1 dit tijdsinterval niet doorgeeft, wordt Synchronisatiecontrole 2 opnieuw geprobeerd.
  • Op minuut 10 wordt Synchronisatiecontrole 1 opnieuw geprobeerd, maar mislukt, dus het wordt opnieuw geprobeerd.
  • Op minuut 14 wordt Synchronisatiecontrole 2 opnieuw geprobeerd en slaagt. De beslissing over de pas is 7 minuten geldig. Als Synchronisatiecontrole 1 dit tijdsinterval niet doorgeeft, wordt Synchronisatiecontrole 2 opnieuw geprobeerd.
  • Op minuut 15 wordt Synchronisatiecontrole 1 opnieuw geprobeerd en slaagt. Beide controles worden nu doorgegeven, dus de pijplijn mag de fase blijven implementeren.

Laten we eens kijken naar een voorbeeld van een goedkeuring en een synchrone controle. Stel dat u een synchrone controle en een goedkeuring hebt geconfigureerd voor een serviceverbinding met een tijd tussen evaluaties van 5 minuten. Totdat de goedkeuring is gegeven, wordt uw controle elke 5 minuten uitgevoerd, ongeacht de beslissing.

Veelgestelde vragen

De gedefinieerde controles zijn niet gestart. Wat is er gebeurd?

De evaluatie van controles begint zodra aan de fasevoorwaarden is voldaan. Controleer of de uitvoering van de fase is gestart nadat de controles zijn toegevoegd aan de resource en of de resource in de fase wordt gebruikt.

Hoe kan ik controles gebruiken voor het plannen van een fase?

Met de controle van kantooruren kunt u de tijd voor het starten van de fase-uitvoering bepalen. U kunt hetzelfde gedrag bereiken als een vooraf gedefinieerd schema op een fase in ontwerpreleases.

Hoe kan ik vooraf goedkeuringen nemen voor een fase die in de toekomst moet worden uitgevoerd?

Dit scenario kan worden ingeschakeld.

  1. Met de controle van kantooruren kunnen alle fasen die naar een resource worden geïmplementeerd, worden gepland voor uitvoering tussen het tijdvenster
  2. Wanneer goedkeuringen zijn geconfigureerd voor dezelfde resource, wacht de fase op goedkeuringen voordat deze wordt gestart.
  3. U kunt beide controles op een resource configureren. De fase wacht op goedkeuringen en kantooruren. Deze wordt gestart in het volgende geplande venster nadat de goedkeuringen zijn voltooid.

Kan ik wachten op voltooiing van het scannen van beveiliging op het artefact dat wordt geïmplementeerd?

Als u wilt wachten totdat het scannen op beveiliging op het artefact is geïmplementeerd, moet u een externe scanservice zoals AquaScan gebruiken. Het artefact dat wordt geïmplementeerd, moet worden geüpload op een locatie die toegankelijk is voor de scanservice voordat de controles worden gestart en kan worden geïdentificeerd met behulp van vooraf gedefinieerde variabelen. Met behulp van de controle REST API aanroepen kunt u een controle toevoegen om te wachten op de API in de beveiligingsservice en de artefact-id door te geven als invoer.

Hoe kan ik uitvoervariabelen uit eerdere fasen in een controle gebruiken?

Standaard zijn alleen vooraf gedefinieerde variabelen beschikbaar voor controles. U kunt een gekoppelde variabelengroep gebruiken om toegang te krijgen tot andere variabelen. De uitvoervariabele uit de vorige fase kan worden geschreven naar de variabelegroep en worden geopend in de controle.

Meer informatie