Uw klassieke pijplijn definiëren
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure Pipelines bieden een zeer configureerbare en beheerbare pijplijn voor releases naar meerdere fasen, zoals ontwikkeling, fasering, QA en productie. het biedt ook de mogelijkheid om poorten en goedkeuringen in elke specifieke fase te implementeren.
In deze zelfstudie leert u:
- Triggers voor continue implementatie
- Fasen toevoegen
- Goedkeuringen vóór de implementatie toevoegen
- Releases en bewakingsimplementaties maken
Vereisten
U hebt het volgende nodig:
Een release-pijplijn die ten minste één fase bevat. Als u er nog geen hebt, kunt u deze maken door een van de volgende quickstarts en zelfstudies te volgen:
Twee afzonderlijke doelen waar u de app gaat implementeren. Dit kunnen virtuele machines, webservers, on-premises fysieke implementatiegroepen of andere typen implementatiedoel zijn. In dit voorbeeld gebruiken we Azure-app Service-website-exemplaren. Als u hetzelfde besluit te doen, moet u namen kiezen die uniek zijn, maar het is een goed idee om 'QA' op te nemen in de naam van de ene en 'Productie' in de naam van de andere, zodat u ze gemakkelijk kunt identificeren. Gebruik Azure Portal om een nieuwe web-app te maken.
Triggers voor continue implementatie (CD)
Als u continue implementatietrigger inschakelt, wordt de pijplijn geïnstrueerd om automatisch een nieuwe release te maken telkens wanneer er een nieuwe build beschikbaar is.
Open het tabblad Releases in Azure Pipelines. Selecteer de release-pijplijn bewerken.
Selecteer het pictogram Continue implementatietrigger in de sectie Artefacten om het triggervenster te openen. Zorg ervoor dat dit is ingeschakeld, zodat er een nieuwe release wordt gemaakt nadat elke nieuwe geslaagde build is voltooid.
Selecteer het pictogram Voorwaarden vóór de implementatie in de sectie Fasen om het deelvenster Voorwaarden te openen. Zorg ervoor dat de trigger voor implementatie in deze fase is ingesteld op Na release. Dit betekent dat een implementatie automatisch wordt gestart wanneer er een nieuwe release wordt gemaakt op basis van deze release-pijplijn.
U kunt ook releasetriggers, fasetriggers of planningsimplementaties instellen.
Fasen toevoegen
In deze sectie voegen we twee nieuwe fasen toe aan onze release-pijplijn: QA en productie (twee Azure-app Services-websites in dit voorbeeld). Dit is een typisch scenario waarin u in eerste instantie zou implementeren op een test- of faseringsserver en vervolgens op een live- of productieserver. Elke fase vertegenwoordigt één implementatiedoel.
Selecteer het tabblad Pijplijn in uw release-pijplijn en selecteer de bestaande fase. Wijzig de naam van uw fase in Productie.
Selecteer de vervolgkeuzelijst + Toevoegen en kies Fase Klonen (de kloonoptie is alleen beschikbaar wanneer een bestaande fase is geselecteerd).
Normaal gesproken wilt u dezelfde implementatiemethoden gebruiken met een test en een productiefase, zodat u zeker weet dat uw geïmplementeerde apps zich op dezelfde manier gedragen. Het klonen van een bestaande fase is een goede manier om ervoor te zorgen dat u dezelfde instellingen voor beide hebt. Vervolgens hoeft u alleen de implementatiedoelen te wijzigen.
De gekloonde fase heeft de naam Copy of Production. Selecteer deze en wijzig de naam in QA.
Als u de fasen in de pijplijn opnieuw wilt organiseren, selecteert u het pictogram voorwaarden vóór de implementatie in uw QA-fase en stelt u de trigger in op Na release. In het pijplijndiagram worden vervolgens de twee fasen parallel weergegeven.
Selecteer het pictogram Voorwaarden vóór de implementatie in de productiefase en stel de trigger in op Na fase en selecteer vervolgens QA in de vervolgkeuzelijst Fasen . Het pijplijndiagram geeft nu aan dat de twee fasen in de juiste volgorde worden uitgevoerd.
Notitie
U kunt uw implementatie zo instellen dat deze begint wanneer een implementatie naar de vorige fase gedeeltelijk is geslaagd. Dit betekent dat de implementatie wordt voortgezet, zelfs als een specifieke niet-kritieke taak is mislukt. Dit wordt meestal gebruikt in een fork en join-implementaties die parallel in verschillende fasen worden geïmplementeerd.
Selecteer de vervolgkeuzelijst Taken en selecteer de QA-fase .
Afhankelijk van de taken die u gebruikt, wijzigt u de instellingen, zodat deze fase wordt geïmplementeerd in uw 'QA'-doel. In ons voorbeeld gebruiken we Deploy Azure-app Service-taak, zoals hieronder wordt weergegeven.
Goedkeuringen vóór implementatie toevoegen
De release-pijplijn die we eerder hebben gewijzigd, wordt geïmplementeerd in QA en productie. Als de implementatie naar QA mislukt, wordt de implementatie naar productie niet geactiveerd. Het wordt aanbevolen om altijd te controleren of uw app goed werkt in de QA- of testfase voordat deze in productie wordt geïmplementeerd. Door goedkeuringen toe te voegen, wordt aan alle criteria voldaan voordat aan de volgende fase wordt geïmplementeerd. Volg de onderstaande stappen om goedkeuringen toe te voegen aan uw pijplijn:
Selecteer het tabblad Pijplijn , het pictogram Voorwaarden vóór de implementatie en vervolgens goedkeurders voor pre-implementatie.
Voer in het tekstvak Goedkeurders de gebruikers in die verantwoordelijk zijn voor het goedkeuren van de implementatie. Het wordt ook aanbevolen om het selectievakje De gebruiker die een release of implementatie aanvraagt, uit te schakelen, mag het selectievakje niet goedkeuren.
U kunt zoveel goedkeurders toevoegen als u nodig hebt, zowel individuele gebruikers als organisatiegroepen. Het is ook mogelijk om goedkeuringen na de implementatie in te stellen door het pictogram Gebruiker aan de rechterkant van de fase in het pijplijndiagram te selecteren. Zie Releases gates en goedkeuringen voor meer informatie.
Selecteer Opslaan.
Een release maken
Nu de installatie van de release-pijplijn is voltooid, is het tijd om de implementatie te starten. Hiervoor maken we handmatig een nieuwe release. Normaal gesproken wordt automatisch een release gemaakt wanneer er een nieuw build-artefact beschikbaar is. In dit scenario maken we dit echter handmatig.
Selecteer de vervolgkeuzelijst Release en kies Release maken.
Voer een beschrijving in voor uw release, controleer of de juiste artefacten zijn geselecteerd en selecteer vervolgens Maken.
Er wordt een banner weergegeven die aangeeft dat er een nieuwe release is gemaakt. Selecteer de releasekoppeling voor meer informatie.
Op de overzichtspagina van de release wordt de status van de implementatie in elke fase weergegeven.
Andere weergaven, zoals de lijst met releases, geven ook een pictogram weer dat aangeeft dat goedkeuring in behandeling is. Het pictogram toont een pop-up met de fasenaam en meer details wanneer u ernaar wijst. Dit maakt het voor een beheerder gemakkelijk om te zien welke releases wachten op goedkeuring, evenals de algehele voortgang van alle releases.
Selecteer het pictogram pending_approval om het goedkeuringsvenster te openen. Voer een korte opmerking in en selecteer Goedkeuren.
Notitie
U kunt de implementatie plannen op een latere datum, bijvoorbeeld tijdens niet-piekuren. U kunt goedkeuring ook opnieuw toewijzen aan een andere gebruiker. Releasebeheerders kunnen alle goedkeuringsbeslissingen openen en negeren.
Implementaties bewaken en bijhouden
Implementatielogboeken helpen u bij het bewaken en opsporen van fouten in de release van uw toepassing. Volg de onderstaande stappen om de logboeken van onze implementatie te controleren:
Beweeg in het releaseoverzicht de muisaanwijzer over een fase en selecteer Logboeken.
Tijdens de implementatie hebt u nog steeds toegang tot de logboekpagina om de livelogboeken van elke taak te bekijken.
Selecteer een taak om de logboeken voor die specifieke taak weer te geven. Dit maakt het gemakkelijker om implementatieproblemen te traceren en op te sporen. U kunt ook afzonderlijke taaklogboeken of een zip van alle logboekbestanden downloaden.
Als u aanvullende informatie nodig hebt om fouten in uw implementatie op te sporen, kunt u de release uitvoeren in de foutopsporingsmodus.
Volgende stap
Feedback
Binnenkort beschikbaar: in de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie https://aka.ms/ContentUserFeedback voor meer informatie.
Feedback verzenden en weergeven voor