Voor agile en DevOps-softwareontwikkelingsteams is Git het de facto versiebeheersysteem en een essentieel onderdeel van een DevOps-toolchain. Dit goed ondersteunde opensourceproject is flexibel genoeg om een reeks workflows te steunen die passen bij de behoeften van een bepaald softwareteam. Het verdeelde, in plaats van gecentraliseerde, karakter geeft het superieure prestatiekenmerken en geeft ontwikkelaars de vrijheid om lokaal te experimenteren en hun wijzigingen alleen te publiceren wanneer ze klaar zijn voor distributie naar het team.
Naast de voordelen van flexibiliteit en distributie zijn er belangrijke functies van Git die agile en DevOps-ontwikkelingsteams steunen en verbeteren. Zie Git als een component van agile en DevOps-ontwikkeling: veranderingen kunnen sneller door de implementatiepijplijn worden geduwd dan door te werken met monolithische releases en gecentraliseerde versiebeheersystemen. Git werkt zoals je agile en DevOps-teams werken (en ernaar streven om te werken).
Tip 1: Begin na te denken over taken zoals Git-branches
Git wordt aan het werk gezet nadat functies zijn uitgewerkt en zijn toegevoegd aan een productroadmap, en wanneer het ontwikkelingsteam klaar is. Maar om even een stap terug te doen: hier vind je een snelle spoedcursus agile functieontwikkeling: product, ontwerp, quality assurance (QA) en engineering houden een kennismakingssessie voor functies om een gedeeld begrip te krijgen van wat een functie gaat inhouden (denk aan vereisten), de scope van het project en in welke taken de functie opgesplitst moet worden om deze te voltooien. Deze taken, ook wel userstory's genoemd, worden vervolgens toegewezen aan individuele ontwikkelaars.
Git begint op dit moment in je agile workflow te passen. Bij Atlassian creëren we een nieuwe branch voor elk afzonderlijke issue. Of het nu gaat om een nieuwe functie, een bugfix of een kleine verbetering ten opzichte van een bestaande code, elke codewijziging krijgt zijn eigen branch.
Branching is eenvoudig en stelt teams in staat om eenvoudig samen te werken binnen één centrale codebase. Wanneer een ontwikkelaar een branch maakt, heeft diegene in feite een eigen geïsoleerde versie van de codebase om wijzigingen aan te brengen. Voor een agile team betekent dit dat het ontwikkelingsteam de mogelijkheid heeft om taken individueel aan te pakken en efficiënter aan dezelfde code te werken maar in verschillende repository's door functies op te splitsen in userstory's en vervolgens in branches. Er is geen verdubbeling van het werk en omdat mensen zich kunnen concentreren op kleine stukjes werk in repository's die los staan van de hoofdrepository, zijn er niet zoveel afhankelijkheden die het ontwikkelingsproces vertragen.
Er zijn andere soorten Git-branches naast taakbranches en deze sluiten elkaar niet uit. Je kunt bijvoorbeeld branches aanmaken voor een release. Hierdoor kunnen ontwikkelaars het werk dat gepland is voor een bepaalde release stabiliseren en verharden, zonder andere ontwikkelaars die aan toekomstige releases werken tegen te houden.
Zodra je een releasebranch hebt gemaakt, moet je deze regelmatig samenvoegen in je main branch om ervoor te zorgen dat je functie werkt in toekomstige releases. Om overhead te minimaliseren, is het het beste om de releasebranch zo dicht mogelijk bij de geplande releasedatum te maken.
Tip 2: Meerdere branches zijn individueel testbaar, dus profiteer hiervan
Zodra branches als gereed worden beschouwd en klaar zijn voor codebeoordelingen, speelt Git een andere belangrijke rol in een agile ontwikkelingsworkflow: testen. Succesvolle agile en DevOps-teams maken gebruik van codebeoordelingen en stellen geautomatiseerde tests in (continue integratie of continue levering). Om te helpen bij code beoordelen en testen kunnen ontwikkelaars de rest van hun team eenvoudig op de hoogte stellen dat het werk aan de branch klaar is voor beoordeling en dat het moet worden beoordeeld via een pull request. Een pull request is een manier om een andere ontwikkelaar te vragen om een van je branches samen te voegen in de main branch en dat deze klaar is om te testen.
Met de juiste tools kun je continue integratieserver je pull requests bouwen en testen voordat je ze samenvoegt. Dit geeft je het vertrouwen dat je samenvoeging geen problemen veroorzaakt. Met dit vertrouwen is het eenvoudiger om je opnieuw te richten op bugfixes en conflicten in het algemeen, omdat Git het verschil kent tussen de branch en de hoofdcodebase omdat de branches uiteenlopen.
Een langlopende functiebranch die niet is samengevoegd met de main branch kan je vermogen om wendbaar en iteratief te zijn schaden. Als je een langlopende functiebranch hebt, onthoud dan dat je in feite twee verschillende versies van je codebase hebt, wat meer bugfixes en conflicten tot gevolg heeft. Maar de beste oplossing is om kortstondige functiebranches te hebben. Dit kan bereikt worden door userstory's op te splitsen in kleinere taken, zorgvuldige sprintplanning, en vroegtijdig code samen te voegen om als dark feature te verzenden.
Tip 3: Git biedt transparantie en kwaliteit voor agile ontwikkeling
Het verhaal van Git/agile gaat over efficiëntie, testen, automatisering en algehele agility. Zodra je een branch hebt samengevoegd met de hoofdbranch, is je agile workflow klaar. Evenzo betekent het samenvoegen van code via pull requests dat wanneer de code klaar is, je over de documentatie beschikt om zeker te weten dat je werk groen is, dat andere teamleden de code hebben ondertekend en dat deze klaar is om gereleased te worden. Dit zorgt ervoor dat agile teams snel en met vertrouwen in beweging blijven om vaak te releasen: een teken van een geweldig agile team.
Een regelmatige releasecadans gebruiken is de sleutel tot agile ontwikkeling. Om Git te laten werken voor je agile workflow, moet je ervoor zorgen dat je main altijd groen is. Dit betekent dat je moet wachten op de volgende release als een functie nog niet klaar is. Als je kortere releasecycli beoefent, zou en zal dit geen probleem zijn.
