Een strategie voor pijplijn en versiebeheer ontwerpen
Wanneer u herbruikbare Bicep-code gaat publiceren, gebruikt u waarschijnlijk een handmatige benadering. U kunt eenvoudig bepalen welk Bicep-bestand u moet publiceren en u hebt waarschijnlijk een handmatig proces voor het verhogen van het versienummer.
Wanneer u het publicatieproces automatiseert, moet u overwegen hoe u deze stappen kunt automatiseren. In deze les leert u hoe u een versiebeheersysteem gebruikt waarmee de wijzigingen die u aanbrengt in uw code worden gecommuniceerd. U leert ook hoe u het bereik van uw pijplijnen kunt instellen om alleen de code te publiceren die u verwacht.
Versienummers
In eerdere Microsoft Learn-trainingsmodules hebt u geleerd over het belang van versiebeheer voor sjabloonspecificaties en Bicep-modules. U kunt kiezen uit veel verschillende versiebeheermethoden. In veel situaties is het een goede gewoonte om een multipart versiebeheersysteem te gebruiken. Een systeem voor meerdere onderdelenversies bestaat uit een primaire versie, secundaire versie en revisienummer, vergelijkbaar met het volgende voorbeeld:
In het voorgaande voorbeeld is de primaire versie 1, de secundaire versie 4 en het revisienummer is 106.
Wijzigingen in verschillende onderdelen van versienummers geven belangrijke informatie over de typen wijzigingen in de code:
Wanneer u een belangrijke wijziging aanbrengt, moet u het primaire versienummer verhogen. Stel dat u een nieuwe verplichte parameter toevoegt of een parameter verwijdert uit uw Bicep-bestand. Dit zijn voorbeelden van ingrijpende wijzigingen, omdat Bicep vereist dat verplichte parameters tijdens de implementatie opgegeven moeten worden en geen waarden mag instellen voor niet-bestaande parameters. U zou dus het primaire versienummer bijwerken.
Wanneer u iets nieuws toevoegt aan de code, maar dit geen belangrijke wijziging is, moet u het secundaire versienummer verhogen. Stel dat u een nieuwe optionele parameter met een standaardwaarde toevoegt. Optionele parameters zijn geen brekende wijzigingen, dus u moet het versienummer bijwerken.
Wanneer u achterwaarts compatibele foutoplossingen of andere wijzigingen aanbrengt die niet van invloed zijn op de werking van de code, moet u het revisienummer verhogen. Stel dat u uw Bicep-code herstructureert om beter gebruik te maken van variabelen en expressies. Als de herstructurering het gedrag van uw Bicep-code helemaal niet wijzigt, werkt u het revisienummer bij.
Uw pijplijn kan ook automatisch het revisienummer instellen. Het buildnummer van de pijplijn kan worden gebruikt als revisienummer. Deze conventie helpt ervoor te zorgen dat uw versienummers altijd uniek zijn, zelfs als u de andere onderdelen van uw versienummers niet bijwerkt.
Stel dat u een eerder gepubliceerde Bicep-module gebruikt met een versienummer van 2.0.496. U ziet dat er een nieuwe versie van de module beschikbaar is met het versienummer 2.1.502. De enige belangrijke wijziging is het versienummer van de kleine release, wat aangeeft dat u geen ingrijpende wijzigingen hoeft te verwachten wanneer u de nieuwe versie gebruikt.
Notitie
Semantische versiebeheer is een geformaliseerde versiestructuur die vergelijkbaar is met versiebeheer met meerdere onderdelen. Semantische versiebeheer bevat extra onderdelen in het versienummer, samen met strikte regels over wanneer u elk onderdeel moet instellen of opnieuw moet instellen. In de samenvatting vindt u een koppeling naar meer informatie over semantische versiebeheer.
Uw team moet bepalen hoe u een belangrijke wijziging definieert voor versiebeheer. Stel dat u een Bicep-module bouwt waarmee een opslagaccount wordt geïmplementeerd. U werkt nu het Bicep-bestand bij om privé-eindpunten in te schakelen in uw opslagaccount. U voegt tegelijkertijd een privé-DNS-zone toe aan uw Bicep-bestand.
In dat voorbeeld kunt u de wijziging mogelijk aanbrengen zonder dat dit van invloed is op de parameters of uitvoer van het Bicep-bestand. Op die manier merkt iedereen die het bestand implementeert mogelijk niet dat er iets anders is. Maar deze wijziging introduceert een aanzienlijk verschil in het gedrag van uw resources, dus u kunt besluiten deze te behandelen als een belangrijke versie-update, ongeacht.
U kunt er ook voor kiezen om een eenvoudigere versiebeheerstrategie te gebruiken, zoals alleen het buildnummer van de pijplijn als uw versienummer. Hoewel deze methode eenvoudiger te implementeren is, betekent dit dat u de verschillen tussen versies niet effectief kunt communiceren met iedereen die uw code gebruikt.
Versies en pijplijnen
Wanneer u uw code interactief publiceert, zoals met behulp van de Azure CLI, moet u waarschijnlijk nadenken over het versienummer dat u aan de sjabloonspecificatie of -module toewijst wanneer u deze publiceert. Maar in een geautomatiseerde implementatiepijplijn moet u uw benadering wijzigen om versienummers toe te wijzen. Uw pijplijn kan brekende wijzigingen niet automatisch detecteren of u adviseren wanneer u uw grote of kleine versienummers zou moeten verhogen. Overweeg versiebeheer zorgvuldig voordat u de sjabloonspecificatie of -module publiceert.
Een benadering is het opslaan van een metagegevensbestand met uw Bicep-code, zoals wordt geïllustreerd in het volgende diagram:
Wanneer u uw Bicep-code bijwerkt, werkt u de versiegegevens bij in het bijbehorende metagegevensbestand. Zorg ervoor dat u brekende en niet-brekende wijzigingen correct identificeert, zodat u de versienummers correct kunt bijwerken.
Tip
Als uw team uw Bicep-code beoordeelt met behulp van pull-aanvragen, vraagt u de revisoren om te controleren of wijzigingen in uw code uw primaire of secundaire versienummers moeten wijzigen.
In de volgende oefening ziet u hoe u een metagegevensbestand kunt gebruiken.
Hoeveel pijplijnen?
Het is gebruikelijk om een verzameling sjabloonspecificaties en modules op te bouwen. Vaak is het zinvol om deze code in dezelfde Git-opslagplaats te bewaren.
Met behulp van padfilters in Azure Pipelines kunt u afzonderlijke pijplijnen maken voor elke module of sjabloonspecificatie in uw opslagplaats. Op deze manier kunt u voorkomen dat u een nieuwe versie van elk Bicep-bestand in de opslagplaats publiceert telkens wanneer u één bestand wijzigt. U kunt pijplijnsjablonen gebruiken om de stappen van uw pijplijn in een gecentraliseerd bestand te definiëren, waardoor de pijplijnspecificatie en sjabloonspecificatie van elke module lichtgewicht blijven.
Stel dat u een bestandsstructuur hebt die vergelijkbaar is met de structuur die u eerder hebt geïllustreerd. U kunt drie afzonderlijke pijplijnen configureren, één voor elk Bicep-bestand. Selecteer elk tabblad om de bijbehorende pijplijndefinitie en het bijbehorende padfilter weer te geven:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Stel dat u alleen het bestand module-2/main.bicep wijzigt. Alleen de pijplijn voor module 2 draait. Maar als u meerdere bestanden in dezelfde doorvoer wijzigt, wordt elk van de relevante pijplijnen geactiveerd.
Notitie
De benadering van het maken van een pijplijn voor elk van uw herbruikbare Bicep-bestanden is eenvoudig en flexibel. Maar het kan lastig worden wanneer u een groot aantal Bicep-bestanden hebt of als u geen afzonderlijke pijplijnen wilt onderhouden voor elke module en sjabloonspecificatie.
U kunt ook scripts in uw pijplijn schrijven om de code te vinden die is gewijzigd en alleen die bestanden te publiceren. Dit is een complexere benadering en dit valt buiten het bereik van deze Microsoft Learn-module.
Omgevingen voor herbruikbare Bicep-code
Wanneer u implementeert in Azure met bicep, is het gebruikelijk om meerdere omgevingen te gebruiken om uw code te valideren en te testen voordat deze wordt gepubliceerd naar een productieomgeving. In eerdere Microsoft Learn-trainingsmodules hebt u geleerd hoe u met meerdere omgevingen kunt werken vanuit een implementatiepijplijn.
Sommige organisaties passen dezelfde principes toe op Bicep-modules en sjabloonspecificaties. U kunt bijvoorbeeld eerst nieuwe versies van uw modules publiceren naar een niet-productieregister, zodat de gebruikers van elke module de nieuwe versies kunnen uitproberen. Nadat ze zich hebben afgemeld bij de wijzigingen, kunt u de modules publiceren in het productieregister van uw organisatie.
Net als bij reguliere implementaties kunt u taken en pijplijnsjablonen gebruiken om de implementatievolgorde in uw omgevingen te definiëren. In deze Microsoft Learn-module publiceren we naar één omgeving om de pijplijn eenvoudig te houden.
Wanneer u modules uit een register gebruikt of een sjabloonspecificatie als Bicep-module gebruikt, kunt u aliassengebruiken. In plaats van de registernaam of de locatie van de sjabloonspecificatie op te geven telkens wanneer u een module definieert, gebruikt u de alias.
Door aliassen te gebruiken, kunt u uw implementatieproces eenvoudig laten werken in meerdere omgevingen. Wanneer u bijvoorbeeld een module definieert, kunt u een alias gebruiken in plaats van een registernaam. Vervolgens kunt u een implementatiepijplijn ontwerpen om de alias te configureren die moet worden toegewezen aan:
- Een ontwikkelingsmoduleregister wanneer u implementeert in een sandbox-omgeving.
- Een productieregister wanneer u implementeert in andere omgevingen.
Notitie
Aliassen zijn niet van toepassing wanneer u publiceert. Ze werken alleen wanneer u sjabloonspecificaties of modules in een Bicep-bestand gebruikt.