Begrijpen van vertakkingen

Voltooid

Wanneer u Bicep-sjablonen bouwt en in een Git-opslagplaats werkt, worden alle wijzigingen van uw team uiteindelijk samengevoegd in de hoofdbranch van uw opslagplaats. Het is belangrijk om de hoofdbranch te beveiligen, zodat er geen ongewenste wijzigingen worden geïmplementeerd in uw productieomgeving. U wilt echter ook dat uw inzenders flexibel kunnen werken, samenwerken met uw team en ideeën eenvoudig kunnen uitproberen.

In deze les leert u over vertakkingsstrategieën en hoe u de hoofdvertakking beveiligt. Je leert ook hoe je een beoordelingsproces voor je branches instelt.

Waarom wilt u de hoofdbranch beveiligen?

De hoofdbranch is de bron van waarheid voor wat wordt geïmplementeerd in uw Azure-omgevingen. Voor veel oplossingen hebt u meerdere omgevingen, zoals ontwikkeling, qa-(quality assurance) en productie. In andere scenario's hebt u mogelijk alleen een productieomgeving. Ongeacht het aantal omgevingen dat je gebruikt, is de hoofdtak de tak waaraan jouw teamleden bijdragen. Hun veranderingen landen uiteindelijk op de hoofdtak.

Een typisch proces kan het volgende zijn:

1. Een teamlid kloont uw gedeelde opslagplaats.
2. Ze brengen lokale wijzigingen aan in een vertakking in hun eigen lokale kopie van de opslagplaats.
3. Wanneer ze klaar zijn met hun wijzigingen, voegen ze deze samen in de hoofdvertakking van hun lokale repository.
4. Ze pushen deze wijzigingen naar de hoofdbranch van de externe opslagplaats.
5. In sommige scenario's activeert de push van de externe opslagplaats een geautomatiseerde pijplijn om de code te verifiëren, te testen en te implementeren. Meer informatie over pijplijnen vindt u in andere Microsoft Learn-modules.

In het volgende diagram ziet u dit proces:

Stel dat de wijzigingen van het teamlid een subtiele fout hebben geïntroduceerd. Nadat het volledige proces is uitgevoerd, bevindt de bug zich nu in de hoofdvertakking van het project en wordt deze in productie gezet. Het is mogelijk dat u deze pas ontdekt wanneer u deze probeert te implementeren en een foutmelding krijgt. Of voor andere soorten bugs kan de implementatie slagen, maar later subtiele problemen veroorzaken.

Stel dat een teamlid in een ander scenario aan een functie werkt en de helft van het voltooide werk van de functie naar de hoofdbranch van de gedeelde opslagplaats pusht. U hebt nu wijzigingen in de hoofdbranch die nog niet zijn voltooid of getest. Deze wijzigingen moeten waarschijnlijk niet worden geïmplementeerd in uw productieomgeving. Implementaties naar productie moeten mogelijk worden geblokkeerd totdat de functie is voltooid. Als de nieuwe functies zich in de hoofdbranch bevinden, kunt u deze mogelijk niet implementeren voor uw klanten.

Advies

Deze problemen zijn met name moeilijk voor grote teams, waarbij meerdere mensen bijdragen aan dezelfde code, maar de richtlijnen in deze module zijn waardevol zodra u met meer dan één persoon samenwerkt. De richtlijnen zijn waardevol, zelfs wanneer u alleen aan een project werkt en u tegelijkertijd aan meerdere functies werkt.

Een betere manier van werken is om uw wijzigingen gescheiden te houden terwijl u eraan werkt. Vervolgens kunt u een ander teamlid wijzigingen laten controleren voordat ze worden samengevoegd in de hoofdvertakking van de gedeelde opslagplaats van uw team. Dit proces helpt uw team bij het nemen van een weloverwogen beslissing over een wijziging voordat u het goedkeurt om te worden samengevoegd.

Functietakken

Een functievertakking geeft een nieuw werk aan dat u start. Het werk kan een configuratiewijziging zijn in een resource die is gedefinieerd in uw Bicep-bestand of een nieuwe set resources die u moet implementeren. Telkens wanneer u een nieuw werkstuk start, maakt u een nieuwe functiebranch.

U maakt een feature branch aan van de main branch. Wanneer u een vertakking maakt, zorgt u ervoor dat u begint met de huidige status van uw Azure-omgeving. Vervolgens breng je alle benodigde wijzigingen aan.

Omdat alle codewijzigingen worden doorgevoerd in de functiebranch, verstoren ze de hoofdbranch van de opslagplaats niet. Als iemand anders in uw team een dringende wijziging moet aanbrengen in de hoofdbranch, kunnen ze dat doen op een andere functiebranch die onafhankelijk is van u.

U kunt ook samenwerken aan functiebranches. Door uw featurebranch te publiceren en naar de gedeelde repository te pushen, kunnen u en uw teamleden samenwerken aan een wijziging. U kunt ook een functie aan iemand anders overdragen om te voltooien wanneer u op vakantie gaat.

Uw functiebranches bijwerken

Terwijl je featurebranch in ontwikkeling is, kunnen andere features worden samengevoegd in de hoofdbranch van je repository. Het resultaat is dat uw functievertakking en de hoofdvertakking van uw project uit elkaar gaan. Hoe verder ze zich uit elkaar bewegen, hoe moeilijker het wordt om de twee vertakkingen opnieuw samen te voegen op een later moment en hoe meer samenvoegingsconflicten u kunt tegenkomen.

U moet uw functiebranch regelmatig bijwerken, zodat u wijzigingen opneemt die zijn aangebracht in de hoofdbranch van de opslagplaats. Het is ook een goed idee om uw functiebranch bij te werken voordat u de functiebranch weer samenvoegt in de hoofdbranch. Op deze manier zorgt u ervoor dat uw nieuwe wijzigingen eenvoudig kunnen worden samengevoegd in de hoofdbranch.

Tip

Voeg de hoofdbranch vaak samen met je featurebranch.

Gebruik kleine, kortstondige vertakkingen

Doel voor kortdurende functievertakkingen. Deze aanpak helpt u samenvoegingsconflicten te voorkomen door de tijd te verminderen dat uw vertakkingen uit sync kunnen raken. Deze aanpak maakt het ook eenvoudiger voor uw collega's om de wijzigingen die u hebt aangebracht te begrijpen. Dit is handig wanneer u iemand nodig hebt om uw wijzigingen te beoordelen.

Splits grote stukken werk op in kleinere taken en maak een featurebranch voor elke taak. Hoe groter de functionaliteit, hoe langer iemand eraan moet werken en hoe langer de featurebranch zal bestaan. U kunt de kleinere wijzigingen in productie implementeren terwijl u elke functiebranch samenvoegt en geleidelijk het bredere werk opbouwt.

Stel je voor dat je enkele wijzigingen aanbrengt in een set Bicep-code. U verplaatst enkele resourcedefinities naar modules. U moet ook enkele nieuwe resources toevoegen aan uw Bicep-bestanden. Het is misschien een goed idee om al uw modules eerst op een aparte tak te herstructureren. Nadat de modules zijn samengevoegd, kunt u beginnen met het toevoegen van uw Bicep-bestanden. Door uw wijzigingen te scheiden, houdt u elke wijziging en de bijbehorende vertakking klein en gemakkelijk te begrijpen.

Wanneer u op deze manier werkt, kan het handig zijn om het trefwoord if te gebruiken om het implementeren van resources uit te schakelen totdat ze klaar zijn. In de volgende voorbeeldcode ziet u hoe u het trefwoord if gebruikt om een Bicep-bestand te maken dat een opslagaccount definieert, maar de implementatie van het opslagaccount uitschakelt totdat u klaar bent met alle wijzigingen.

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

U kunt parameters gebruiken om verschillende waarden op te geven voor de storageAccountReady variabele in verschillende omgevingen. U kunt bijvoorbeeld de parameterwaarde instellen op true voor uw testomgeving en false voor uw productieomgeving. Op die manier kunt u het nieuwe opslagaccount uitproberen in uw testomgeving.

Notitie

Wanneer het tijd is om de functie in productie in te schakelen, moet u de volgende stappen uitvoeren om de wijziging van kracht te laten worden:

1. Wijzig de parameterwaarde.
2. Implementeer uw Bicep-bestand opnieuw.

Functietakken samenvoegen

Wanneer u klaar bent met het werken aan een functiebranch, moet u deze samenvoegen in de hoofdbranch van uw opslagplaats. Het is een goed idee om de wijzigingen te bekijken die zijn aangebracht in de functiebranch voordat u samenvoegt. Met pull-aanvragen kunt u uw code controleren. Verderop in deze module vindt u meer informatie over pull-aanvragen.

Bescherming van vertakkingen

In GitHub kunt u vertakkingsbeveiligingen configureren voor de hoofdbranch van de gedeelde opslagplaats. Vertakkingsbeveiliging handhaaft regels zoals:

• Er kan geen wijziging worden samengevoegd in de hoofdbranch, behalve via een pull-aanvraag.
• Wijzigingen moeten door ten minste twee andere personen worden gecontroleerd.

Als iemand probeert een commit rechtstreeks naar een beveiligde vertakking door te voeren, mislukt de poging. In de volgende les leert u hoe u vertakkingsbeveiligingen toepast.

Beleid voor vertakkingen

In Azure DevOps kunt u vertakkingsbeleid configureren voor de hoofdbranch van de gedeelde opslagplaats. Beleidsregels dwingen regels af, zoals:

• Er kan geen wijziging worden samengevoegd in de hoofdbranch, behalve via een pull-aanvraag.
• Wijzigingen moeten door ten minste twee andere personen worden gecontroleerd.

Als iemand probeert een commit rechtstreeks naar een beveiligde vertakking in te sturen, mislukt de push. In de volgende les leert u hoe u vertakkingsbeleid toepast.

Andere vertakkingsstrategieën

Wanneer u samenwerkt aan uw Bicep-code, kunt u verschillende vertakkingsstrategieën gebruiken. Elke vertakkingsstrategie heeft voordelen en nadelen.

Het proces dat u tot nu toe hebt geleerd, is een versie van de trunk-gebaseerde ontwikkeling strategie. In deze vertakkingsstrategie wordt werk uitgevoerd op kortdurende functievertakkingen en vervolgens samengevoegd in één hoofdvertakking. U kunt de inhoud van de hoofdbranch van de gedeelde opslagplaats automatisch implementeren naar productie telkens wanneer een wijziging wordt samengevoegd, of u kunt wijzigingen batcheren en vrijgeven volgens een schema, zoals elke week. Ontwikkeling op basis van trunk is eenvoudig te begrijpen en maakt samenwerking mogelijk zonder veel overhead.

Sommige teams scheiden het werk dat ze hebben voltooid van het werk dat ze in productie hebben geïmplementeerd. Ze gebruiken een langlevende ontwikkelingsbranch als doelwit voor het mergen van hun functievertakkingen. Ze voegen de ontwikkelingsbranch samen in hun hoofdbranch wanneer ze wijzigingen vrijgeven naar productie.

Voor sommige andere vertakkingsstrategieën moet u release-takken maken. Wanneer u een set wijzigingen hebt die klaar is voor implementatie in productie, maakt u een releasebranch met de wijzigingen die u wilt implementeren. Deze strategieën kunnen zinvol zijn wanneer u uw Azure-infrastructuur regelmatig implementeert of wanneer u uw wijzigingen integreert met veel andere teams.

Andere vertakkingsstrategieën zijn Gitflow, GitHub Flow en GitLab Flow. Sommige teams gebruiken GitHub Flow of GitLab Flow omdat hiermee werk van verschillende teams kan worden gescheiden, samen met het scheiden van urgente bugfixes van andere wijzigingen. Met deze processen kunt u uw commits ook scheiden in verschillende releases van uw oplossing, wat cherry pickingwordt genoemd. Ze vereisen echter meer beheer om ervoor te zorgen dat uw wijzigingen compatibel zijn met elkaar. De sectie Samenvatting van deze module bevat koppelingen naar meer informatie over deze vertakkingsstrategieën.

De vertakkingsstrategie die geschikt is voor uw team, is afhankelijk van de manier waarop uw team werkt, samenwerkt en de wijzigingen publiceert. Het is een goed idee om te beginnen met een eenvoudig proces, zoals trunk-based development. Als u merkt dat uw team niet effectief kan werken met behulp van dit proces, introduceert u geleidelijk andere lagen van vertakkingen of neemt u een vertakkingsstrategie aan; Maar houd er rekening mee dat wanneer u meer vertakkingen toevoegt, het beheren van uw opslagplaats complexer wordt.

Tip

Ongeacht de vertakkingsstrategie die u gebruikt, is het goed om vertakkingsbeleid te gebruiken om de hoofdvertakking te beveiligen en pull-aanvragen te gebruiken om uw wijzigingen te controleren. Andere vertakkingsstrategieën introduceren ook belangrijke vertakkingen die u moet beveiligen.

In deze module gebruiken we trunk-gebaseerde ontwikkeling met functievertakkingen, omdat het eenvoudig te gebruiken is.