Concepten van implementatiepoorten
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Implementatiepoorten in Azure Pipelines worden toegevoegd aan release-pijplijnen om ervoor te zorgen dat implementaties voldoen aan specifieke criteria voordat u doorgaat. Gates zijn essentieel om ervoor te zorgen dat implementaties betrouwbaar en veilig zijn door strenge controles af te dwingen die leiden tot stabielere en veilige softwarereleases.
Poorten worden gedefinieerd in de voorwaarden vóór de implementatie en na de implementatie van een releasefase. Ze bieden een mechanisme voor het automatisch verzamelen van statussignalen van externe services, zoals Azure Function of REST API's, om de promotie van releases op basis van deze signalen te beheren. Gates werkt met goedkeuringen om ervoor te zorgen dat de juiste belanghebbenden de release goedkeuren en de release voldoet aan de noodzakelijke kwaliteits- en nalevingscriteria.
Toepassingsgevallen
Enkele veelvoorkomende gebruiksvoorbeelden voor implementatiepoorten zijn:
- incidentbeheer: zorg ervoor dat aan bepaalde criteria wordt voldaan voordat u doorgaat met de implementatie. Zorg er bijvoorbeeld voor dat de implementatie alleen plaatsvindt als er geen bugs met prioriteit nul bestaan.
- Goedkeuringen zoeken: integreer met Microsoft Teams of Slack om externe gebruikers, zoals auditors, of IT-managers te informeren over een implementatie en te wachten op hun goedkeuringen.
- kwaliteitsvalidatie: metrische gegevens voor querypijplijnen, zoals de wachtwoordfrequentie of codedekking, en deze alleen implementeren als ze zich binnen een vooraf gedefinieerde drempelwaarde bevinden.
- Beveiligingsscan: beveiligingscontroles uitvoeren, zoals het scannen van artefacten, het ondertekenen van programmacode en beleidscontrole. Een implementatiepoort kan de scan initiëren en wachten tot deze is voltooid, of alleen controleren op voltooiing.
- gebruikerservaring ten opzichte van de basislijn: gebruik productgegevensverzameling om ervoor te zorgen dat de gebruikerservaring regressies van de basislijnstatus heeft. De metrische gegevens van de gebruikerservaring voordat de implementatie als basislijn kan worden gebruikt.
- Wijzigingsbeheer: Wacht tot wijzigingsbeheerprocedures in een systeem zoals ServiceNow zijn voltooid voordat u doorgaat met de implementatie.
- infrastructuurstatus: controleer en valideer de infrastructuur op basis van nalevingsregels na de implementatie, of wacht op gezond resourcegebruik en een positief beveiligingsrapport.
De meeste gezondheidsparameters variëren in de loop van de tijd en veranderen hun status regelmatig van gezond naar ongezond en weer gezond. Om rekening te houden met dergelijke variaties, worden alle poorten periodiek opnieuw geëvalueerd totdat ze allemaal op hetzelfde moment succesvol zijn. De uitvoering en implementatie van de release gaan niet verder als alle poorten niet in hetzelfde interval slagen en vóór de geconfigureerde time-out.
Een poort voor een fase definiëren
U kunt poorten inschakelen aan het begin van een fase (voorwaarden vóór de implementatie) of aan het einde van een fase (voorwaarden na implementatie) of voor beide. Zie Poorten instellenvoor meer informatie.
De vertraging vóór evaluatie is een tijdsvertraging aan het begin van het gate-evaluatieproces die de poorten in staat stelt zich te initialiseren en stabiliseren, zodat ze nauwkeurige resultaten kunnen leveren voor de huidige implementatie. Zie Gate-evaluatiestromenvoor meer informatie.
- Voor poorten vóór de implementatie, is de vertraging de tijd die nodig is voor alle bugs die moeten worden vastgelegd voor de artefacten die worden geïmplementeerd.
- Voor poorten na de implementatie, is de vertraging het maximum van de tijd die nodig is voor de geïmplementeerde app om een stabiele operationele status te bereiken, de tijd die nodig is voor de uitvoering van alle vereiste tests in de geïmplementeerde fase en de tijd die nodig is voor het registreren van incidenten na de implementatie.
De volgende poorten zijn standaard beschikbaar:
- Azure-functie aanroepen: de uitvoering van een Azure-functie activeren en ervoor zorgen dat deze is voltooid. Zie Azure-functietaakvoor meer informatie.
- Query uitvoeren op Azure mMnitor-waarschuwingen: bekijk de geconfigureerde Waarschuwingsregels van Azure Monitor voor actieve waarschuwingen. Zie Azure Monitor-taakvoor meer informatie.
- REST API aanroepen: maak een aanroep naar een REST API en ga door als er een geslaagd antwoord wordt geretourneerd. Zie REST API-taak aanroepenvoor meer informatie.
- Querywerkitems: zorg ervoor dat het aantal overeenkomende werkitems dat door een query wordt geretourneerd, binnen een drempelwaarde valt. Zie Taak Werkitems opvragenvoor meer informatie.
- Azure Policy-naleving controleren: Azure Policy-naleving beoordelen op resources binnen het bereik van een bepaald abonnement en een bepaalde resourcegroep, en eventueel op een specifiek resourceniveau. Zie Azure Policy-nalevingstaak controlerenvoor meer informatie.
U kunt ook uw eigen toegangspoorten maken met Marketplace-extensies.
De evaluatieopties die van toepassing zijn op alle poorten zijn:
- Tijd tussen het opnieuw evalueren van poorten. Het tijdsinterval tussen opeenvolgende evaluaties van de poorten. Bij elk steekproefinterval worden nieuwe aanvragen gelijktijdig naar elke poort verzonden en worden de nieuwe resultaten geëvalueerd. De aanbeveling is dat het steekproefinterval groter is dan de langste typische reactietijd van de geconfigureerde poorten, zodat alle reacties kunnen worden ontvangen voor evaluatie.
- Time-out waarna poorten mislukken. De maximale evaluatieperiode voor alle poorten. De inzet wordt afgewezen als de timeout wordt bereikt voordat alle poorten zijn voltooid tijdens hetzelfde steekproefinterval.
- Gates en goedkeuringen. Selecteer de vereiste uitvoeringsvolgorde voor poorten en goedkeuringen als u beide hebt geconfigureerd. Voor implementatievoorwaarden is het de standaardinstelling eerst om handmatige (gebruikers) goedkeuringen te vragen en daarna de poorten te evalueren, zodat het systeem niet de gatefuncties evalueert als de gebruiker de release weigert. Voor voorwaarden na de implementatie is de standaardinstelling om poorten te evalueren en alleen om handmatige goedkeuringen te vragen wanneer alle poorten zijn geslaagd om ervoor te zorgen dat de goedkeurders alle informatie hebben die nodig is om de release goed te keuren.
Zie Logboeken voor goedkeuringen weergeven en Implementaties bewaken en bijhoudenvoor meer informatie over gates analytics.
Voorbeelden van gate-evaluatiestromen
In het volgende diagram ziet u de stroom van de poortevaluatie, waarbij, na de initiële vertragingsperiode en drie steekproefintervallen, de implementatie wordt goedgekeurd.
In het volgende diagram ziet u de stroom van de poortevaluatie, waarbij, na de initiële vertragingsperiode voor stabilisatie, niet alle poorten bij elk steekproefinterval zijn geslaagd. In dit geval wordt de implementatie geweigerd nadat de time-outperiode is verlopen.
