Git of SVN? Hoe koos Nuance Healthcare voor een Git-branching-model?

We ondersteunen ongeveer tien afzonderlijke producten, verdeeld over vier productfamilies, en de eigenaren van deze producten strijden altijd om prioriteit en timing. Het is fijn dat er veel vraag is naar ons werk, en dit is zeker geen klacht, maar het vraagt ook dat er met een vreemd tempo wordt gesneden in releases en dat we midden in een sprint van richting moeten veranderen[3].

Ons ontwikkelingsproces voelde soms echt belemmerend aan. Mijn team had regelmatig een gesprek dat ongeveer zo verliep:

Ik: We moeten nu 1.8.0 beschikbaar stellen voor QA voor regressietests, zodat Customer foo volgende week naar de bètaversie kan gaan. Dev: Ik werk nog steeds aan de ABC-123, die in de trunk zit. Die is nog niet klaar. Ik: Foo heeft ABC-123 niet nodig. We zouden het in de volgende release kunnen opnemen. Dev: Maar ik ben er al weken mee bezig. Er is geen duidelijke plek om de branch naartoe te leiden voor release. Ik: Nou, je moet al je wijzigingen maar handmatig pullen. Je hebt ongeveer twee uur de tijd, anders kan QA niet op tijd klaar zijn.

Ik weet het, ik klink als een eikel! Dat was niet mijn bedoeling, en natuurlijk overdrijf ik een beetje om iets duidelijk te maken, maar we moesten echt uitzoeken hoe we de code die op één plek stond tijdelijk eruit konden krijgen, zodat we een release konden stopzetten en die dan terug konden zetten voor de volgende release[4]. En dit gebeurde de hele tijd.

Ik weet dat sommigen van jullie denken 'Subversion ondersteunt ook branches, Matt ...' Dat is absoluut waar, en we hebben ze af en toe gebruikt met SVN 1.4 en 1.5. Vertakking is een prima handeling bij SVN; samenvoegen kan echter lastig zijn. Nu SVN volwassen is geworden, is het zeker beter geworden. Maar we wisten dat er betere opties waren voor ons, dus toen de vraag over SVN of Git opkwam, stapten we over op Git.

Even een kanttekening: we hebben kort gekeken naar de meest recente SVN (destijds 1.8) om te zien of deze sterk genoeg was om onze problemen op te lossen, maar we waren niet helemaal tevreden. Een van onze peergroups heeft een grote Perforce-configuratie en daarin stond veel van wat we nodig hadden, maar ik kon de licentiekosten gewoon niet aan. We hebben ook even naar Mercurial gekeken, maar uiteindelijk was de blootstelling van het bestaande team aan Git voldoende om ons te vertellen dat dat de juiste richting was.

Ik zal er niet omheen draaien: de tools van Atlassian zijn echt geschikt voor teams die Git gebruiken. Andere SCM's werken ook prima. Onze SVN-integratie was voldoende omdat deze ons doorstuurde naar de plaats waar de wijzigingen in een bepaalde userstory zijn aangebracht. De integratiemogelijkheden voor teams die in plaats daarvan Bitbucket[5] gebruiken, zijn zowel sterker als natuurlijker in de interface en ontwikkelervaring van Jira Software, idem met Bamboo.

Nu ik dit weet en nadat ik op Summit 2013 een aantal fantastische demo's had gezien, heb ik het team sterk aangemoedigd om ervoor te gaan. Niemand maakte bezwaar en we hadden al licenties om wijzigingen aan te brengen.

Nadat we besloten hadden om deze wijziging door te voeren, was de eerste uitdaging die we hadden om te beslissen welk Git-vertakkingsmodel we voor ons team moesten implementeren. Op de Git-microsite van Atlassian en in deze geweldige presentatie van Summit 2013 wordt gedetailleerder uitgelegd wat een vertakkingsmodel is. In het kort gaat het over hoe je branches in Git kunt gebruiken om je ontwikkelingsworkflow te versterken.

In SVN hadden we een vertakkingsmodel. die ik 'maak er een aan wanneer je er ineens achterkomt dat je er een nodig hebt' noem:

• De nieuwste code zit in de trunk. Releases uit de trunk krijgen het nummer A.B.0-{build}.
• Als er een oplossing nodig is voor een release op basis van een trunk (bijv. er is een bug in 1.2.0-64), er wordt een branch aangemaakt en van daaruit brengen we A.B.C-{build} releases uit, waarbij C wordt verhoogd na elke release die de deur uitgaat. Deze branches bestaan voor een bepaalde A.B misschien wel nooit en we zouden er zelfs meer dan één aan kunnen maken.
• We taggen ook elke release in een directory met tags.

Ik heb eerder een probleem genoemd waarbij we aan een release werkten (laten we zeggen 1.2.0) en we zouden een functie hebben die nog in uitvoering was toen we bijna tegen de releasedatum aanzaten. We zouden die code eruit moeten pullen, onze release moeten knippen, naar branches/1.2.1 moeten vertakken en die code dan weer moeten samenvoegen, in de hoop dat in de tussentijd niemand een harde schijf zou laten crashen[6].

Het is lastig om op zichzelf een hele functie uit een gedeelde trunk te verwijderen. Niemand was er blij mee wanneer ze dat moesten doen. svn blame kan nuttig zijn, net als een sterke diff-tool, maar het blijft vervelend om mee te werken. Ik nam het vaak persoonlijk op, omdat ik het gevoel had dat mijn slechte planning ertoe had geleid dat we niet alles goed voor elkaar hadden voordat we klaar waren met een release[7]. Mijn team heeft hier lang genoeg mee te maken gehad.

Soms corrigeerden we te veel om problemen uit de weg te gaan en vroegen we ontwikkelaars om een paar dagen niets te doen (een virtuele codebevriezing, zeg maar), zodat we de trunk niet vervuilden voor een release.

Dus we wisten dat we in ieder geval functie-branches nodig hadden. Er is een eenvoudig Git-vertakkingsmodel dat van toepassing is: een main-branch voor wat er in prod staat, en het gebruik van functie-branches voor elke functie, bug, enz. Het team moet de samenvoegingsvolgorde beheren om ervoor te zorgen dat wat er naar de main wordt verzonden klaar is voor release. Dit is in wezen hetzelfde als voorheen, met een aantal betere isolatiemogelijkheden, maar we wilden die vrijheid met onze macht kunnen benutten.

In onze omgeving moeten we vaak een paar versies in productie houden en moeten we mogelijk defecten herstellen in een release die 2 tot 3 kleine revisies ouder is dan waar we op dit moment aan werken. Dus naast functie-branches hadden we ook een soort releasebranch of iets dergelijks nodig waarmee we problemen uit eerdere releases konden oplossen. Ze voeren oplossingen aan in langlopende supportbranches en voegen ze vervolgens samen in de branchstroom, zodat een oplossing in alle supportstromen terechtkomt.

Hun model zag er echt goed uit, en we hebben een aantal interacties uitgevoerd met dit model om te zien of het aan onze behoeften zou voldoen. De 'beste app' voor hen is hun doorlopende samenvoeging van een oplossing voor hun ontwikkelafdeling. Hoewel we dit concept goed vonden, stuitten we elke keer dat we het probeerden op een of andere issue met onze Maven-afhankelijkheden. Bovendien konden we in de regel niet garanderen dat we een directe samenvoeging van het werk van de ene versie in de andere wilden. In sommige gevallen moesten we dezelfde oplossing op enigszins verschillende manieren implementeren tussen versies, dus een directe samenvoeging was niet mogelijk.

Een paar leden van het team waren sterk voorstander van een variant van dit model, bekend als 'git-flow'. Git-flow is een verzameling naamgevingsconventies en richtlijnen voor samenvoegingen van branches, geschreven door Vincent Driessen. Dit voelde heel natuurlijk aan voor het team, en we vonden de structuur goed omdat daardoor veel vragen verdwenen waren zoals 'wat moet ik doen als we x moeten doen?'. De antwoorden waren over het algemeen heel voor de hand liggend. In plaats van uit te leggen wat git-flow is, kun je er meer over lezen in de tutorial van Atlassian.

De enige kloof die voor ons overbleef met git-flow was dat we iets moesten doen met die langlopende releases in de productie. Aangezien main zich steeds verder ontwikkelt, konden we de git-flow hotfix-workflow niet gebruiken voor een bugfix uit een vorige release. Aan de andere kant wilden we niet altijd een supportbranch hebben.

Meestal zou een hotfix, waarbij alleen de laatste release in productie wordt gepatcht, voldoende moeten zijn. Support is er alleen als we een stap verder moeten, of als we om een of andere reden de compatibiliteit moeten behouden. Die laatste usecase hebben we verder besproken en criteria bedacht om te kiezen voor een supportbranch in plaats van een hotfix en een kleinere versie-upgrade:

1. Deze code kan niet zomaar worden samengevoegd bij ontwikkeling.

2. De partner/klant kan een wijziging van de interface niet aan die bij de nieuwste release hoort.

3. Er is een interne afhankelijkheid die niet kan worden gewijzigd.[8]

Beide git-flow-uitbreidingspakketten[9] bieden support voor het concept van de support branch dat geen deel uitmaakt van de oorspronkelijke versie van git-flow, maar populair genoeg is geworden om toevoeging te rechtvaardigen.

Git-flow bood een workflow waar we wel mee konden werken, met de toolsupport die we nodig hadden. In het volgende bericht zal ik ingaan op wat er gebeurde toen we het daadwerkelijk probeerden te gebruiken in een POC-project dat we gebruikten om ons ontwikkelingsproces weer te geven. Het was ... iets om van te leren!

[1]: Natuurlijke taalverwerking. WE KUNNEN JE GEDACHTEN LEZEN. (Nee. Niet écht.)

[2]: Er zijn veel dingen aantrekkelijk aan het cloudaanbod van Atlassian, maar we moeten ons voorlopig nog even aan onze servers en data vastklampen. Hoewel we persoonlijk niet veel hoeven te doen met beschermde persoonsgegevens, doet onze software dat wel en het is belangrijk om die zo veilig mogelijk te houden.

[3]: Shhhh ... laat het Ken Schwaber maar niet horen.

[4]: Dat had in ieder geval maar een paar dagen later geweest.

[5]: Voorheen bekend als Stash. Hallo, Atlassian herfst-rebranding!

[6]: Ik weet dat we het altijd uit de vorige commit kunnen pullen. Ik maakte maar een grapje.

[7]: Dat was meestal niet het geval. Over het algemeen was dat omdat het tijdsbestek van iemand anders was verschoven en we snel moesten reageren.

[8]: Dit is een van die dingen waar ik niet op mijn eigen blog op in kan gaan. Vertrouw me maar. Ik heb mijn 'redenen'.

[9]: Het originele pakket van Vincent Driessen wordt niet meer onderhouden. Een nieuwe vertakking wordt echter regelmatig bijgewerkt.