09 aug DevOps best practice: branch policies en build validation
De tijd dat een ontwikkelaar individueel werkt aan een applicatie is in de meeste gevallen geschiedenis. Als ontwikkelaar kom je gewoonlijk terecht in een team met meerdere ontwikkelaars, analisten en projectmanagers die verantwoordelijk zijn voor één of meerdere applicaties.
In zo’n teams worden taken toegewezen aan ontwikkelaars die deze taken uitvoeren op een versie van een gemeenschappelijke codebase, beter gekend als een “branch”. Wanneer de ontwikkeling voor de toegewezen taak klaar is, moet deze branch terug samengevoegd worden met de gemeenschappelijke branch. In dit artikel wordt besproken hoe de kwaliteit van deze merge kan gevalideerd worden met enkele “devops best-practices”. Dit artikel wordt ondersteund door praktische voorbeelden met behulp van Azure DevOps, het projectmanagement en versiebeheer platform van Microsoft.
Branch Policies
Om ervoor te zorgen dat er geen niet-gevalideerde wijzigingen kunnen gebeuren aan onze gemeenschappelijke branch moet er een set van regels of policies gedefinieerd worden die ervoor zal zorgen dat elke aanpassing via een pull request moet worden doorgevoerd. Als voorbeeld voor dit artikel is er een demoproject opgezet met het default .NET 5 ASP.NET WebApi template. Naast de standaard main-branch is er een develop-branch aangemaakt waar de code van de verschillende ontwikkelaars op zal samenkomen. Deze develop-branch is eveneens ingesteld als compare en default branch. De main-branch zou kunnen gebruikt worden als productie branch maar valt buiten de scope van dit artikel. Voor de develop-branch, de gemeenschappelijke branch dus, kunnen nu verschillende branch policies ingesteld worden via het menu onderaan. Deze policies zullen ervoor zorgen dat er aan een lijst van voorwaarden voldaan moet worden voordat er een wijziging mag uitgevoerd worden op deze branch.
Azure Devops heeft enkele ingebouwde voorwaarden om onze policies te definiëren. Een logische set van voorwaarden waar een pull request aan zou moeten voldoen zijn bijvoorbeeld:
- Er moet minstens één iemand de wijzigingen nakijken en goedkeuren en deze persoon mag niet de uitvoerende ontwikkelaar zelf zijn.
- Er moet een work item, een taak in het Board, de projectmanagement tool van Azure DevOps, gelinkt zijn aan een pull request. Dit kan later handig zijn om de code die bij een taak hoort terug te vinden.
- Wanneer iemand een opmerking geeft op een pull request, moet deze opmerking eerst opgelost worden voor de pull request goedgekeurd en samengevoegd mag worden.
Als bovenstaande set van voorwaarden ingesteld zijn in het portaal ziet dat er als volgt uit:
De Pull Request
Nu bovenstaande voorwaarden zijn gedefinieerd kan er een pull request aangemaakt worden voor een afgewerkte taak. Zoals gedefinieerd in de policy moet iedere pull request gekoppeld zijn met een work item. Om de koppeling te maken is er als voorbeeld een taak gecreëerd vanuit Azure DevOps Boards.
Nadat de aanpassingen zijn gemaakt op de branch kan de pull request aangemaakt worden in het pull request menu. Een pull request geeft de mogelijkheid aan de mede-ontwikkelaars om de code na te lezen en waar nodig opmerkingen toe te voegen. Hiervoor is het aangeraden het aantal wijzigingen in een pull requests zo klein mogelijk te houden. Een mede-ontwikkelaar kan een beknopte pull request veel eenvoudiger en correcter valideren in vergelijking met een pull request die een groot aantal wijzigingen bevat . Wanneer er aan iedere voorwaarde voldaan is, zal de pull request kunnen goedgekeurd worden en worden samengevoegd of gemerged met de develop-branch.
Build Validation
Zonet stond er beschreven hoe branch policies kunnen worden gedefinieerd en hoe de code handmatig nagekeken kan worden door een collega-ontwikkelaar. Dit zal ervoor zorgen dat er, wanneer dit goed en zorgvuldig uitgevoerd wordt, een kwaliteitscontrole zit op de nieuwe code. Naast deze handmatige controle is het aangeraden om een geautomatiseerd proces op te zetten dat testen uitvoert. Deze testen zijn meestal door de ontwikkelaar gedefinieerde testen zoals unittesten en integratietesten. De tool die voor dit automatisatie proces gebruikt kan worden is ingebouwd in Azure DevOps in het “Pipelines” menu. Deze pipelines definiëren een stappenplan die de applicatie moet doorlopen. Een pipeline kan gecombineerd gebruikt worden als Build validation en continuous integration-pipeline waarmee artifacts gebouwd worden die later kunnen gebruikt worden in een release pipeline of gehost kunnen worden als herbruikbare packages. Echter wordt in dit artikel enkel de focus gelegd op de mogelijkheden van build validation.
Een build-validation pipeline voert dus automatisch enkele stappen uit die een applicatie kan testen op bepaalde zaken. In dit voorbeeld worden er twee basiszaken uitgevoerd, al zou dit in de praktijk veel uitgebreider kunnen zijn:
- Kan de applicatie gecompileerd worden zonder fouten?
- Slagen alle automatische testen zoals unittesten en integratietesten?
In het pipeline-menu kan je een nieuwe pipeline aanmaken:
Selecteer vervolgens de bron van de code, in dit geval Azure Repos Git, en vul de andere nodige parameters in:
Hierna moet de pipeline gedefinieerd worden in YAML formaat. Hoe een pipeline wordt gebouwd kan je vinden via de Microsoft documentatie.
Wanneer de pipeline geconfigureerd is, kan deze worden toegevoegd aan de branch policies:
Als bovenstaande stappen juist zijn doorgevoerd is de minimum kwaliteitscontrole voorzien, en kunnen alle toekomstige codeaanpassingen gevalideerd, goedgekeurd en samengevoegd worden.