BRANCHING STRATEGIE BIJ OUTSOURCING

WAAROM

Bij een outsourcing is het vaak zou dat er minder controle is over de code van de geleverde software. Het is echter van belang dat je als bedrijf zoveel mogelijk deze code toch in beheer te hebben. Eerst en vooral is het van belang om uiteraard een GIT (of voor de oudere bedrijven een SVN) voor te hebben. Eenmaal je dit GIT omgeving hebt is het echter ook van belang om nog te weten wat waar gereleased is. Ideaal gezien is dit ook gekoppeld aan een devops omgeving maar dat is voer voor een ander artikel. Om dit echter zo optimaal mogelijk te voldbrengen is hieronder een model voor ranching voorgesteld

BRANCHING, ENVIROMENT, TAGS, FEATURES AND HOTFIXES

Er zijn verschillende branching strategieën. Voor iedere strategie is er wel iets te zeggen. Maar hieronder is mijn visie op een goede strategie in een bedrijf met IT outsourcing (build) waarbij de code toch centraal beheerd en gedeployed wordt (run). 

Master

Er is altijd een master branch. In het vakjargon is dit "deployment waardige" code. Dit gebruiken als effectieve bron voor productie is mogelijk maar geeft helaas soms een zeker verlies van overzicht. Veelal wordt dit opgelost door tags te gebruiken. Maar in een multi enviroment omgeving geeft dit toch al gauw ene kluwen aan tags. Ook het automatisch builden en deployen op basis van een tag gaat maar geeft meer risico's op het missen van nuances. we gaan er daarom vanuit dat de master wel productie waardig is maar niet productie zelf. Indien de (outsourced) ontwikkelaars niet op de GIT van het bedrijf werken is dit ook de branch waar ze op "inhaken" om hun commits te doen vanuit hun eigen systeem

feature

De feature branches zijn de branches om aan bepaalde aken te werken. In een outsourced omgeving waar men niet op de GIT van het bedrijf zit zijn deze feature branches meestal niet te vinden maar zullen ze eerder bij de outsourcing partner aanwezig zijn. Als een feature afgewerkt is gaat deze naar de master en wordt deze daarna eventueel gesynct met andere repositories (zoals die van het bedrijf zelf.

Enviroments

Het volgende onderdeel is de enviroment (branching). En dit is ook het stuk waar het interessant wordt voor het bedrijf zelf. In regel heeft iedere enviroment zijn eigen branch. Op de tekening onderaan is dit beperkt tot TEST, UAT en PROD ipv de volledige DTAP straat. Dit voor de eenvoud.

TEST

Bevat de branch die op een bepaald moment gereleased is op de TEST omgeving. Deze kan continu aangevuld worden met nieuwe merges vanuit de master branch. Iedere keer er nieuwe code op de TEST branch komt triggert er een deploy timeline is de nodige (unit) tests laat lopen, packges build en deployed en dan de integratie en functionele testen uitvoert. 

UAT

Deze branch bevat de code die op UAT aanwezig is om te testen. Voor de leesbaarheid en zekerheid kan het interessant zijn om op deze branch ook lavast de tagging te doen op release niveau. Dit is niet altijd nodig (bv als er bugfixes doorgevoerd worden voor een release die nog niet naar productie moet) maar het is wela an te raden als er een versie in "finale testing" zit. De UAT branch wordt in regel gevoed vanuit de DEV branch. Iedere nieuwe code leid ideaal gezien terug tot een (semi) automatische deploy van de nieuwe code op de UAT omgeving. Door de aparte branch is dit eenvoudig te monitoren en uit te voeren.

PROD

De PROD branch wordt op zich weer gevoed vanuit de UAT branch. Een nieuwe code hier zou een deploy naar PROD moeten triggeren en deze zou getagged moeten zijn om optimaal op de releases te kunnen inspelen en deze correct bij te houden. Een speciale voeding kan gebeuren vauit hotfixes (zie volgend onderdeel). Ook deze deploys moeten uiteraard gecontroleerd worden met unit en integratietests tijdens het bouwen van de packages.

Hotfix

Een hotfix branch is een ietwat speciaal geval. In outsourced content is deze niet perse aanwezig bij het bedrijf zelf al is dit wel aan te raden. Een hotfix ontstaat door dringende problemen die zich voordoen op PROD. In dit geval wordt vanaf de PROD branch de laatste versie genomen (die momenteel ook effectief draait dus, hence het nut van deze branch). in de hotfix branach wordt er zo snel mogelijk een oplossing gevonden en lokaal getest. Deze oplossing gaat dan zo snel mogelijk verder. Naargelang de risico appetijt van het bedrijf is dit DEV => UAT => PROD, UAT => PROD of direct naar PROD. Over het algemeen is een hotfix direct naar UAT deployen een mooie tussenstap in zo snel mogelijk vooruitgaan met zo weinig mogelijk impact op de lopende ontwikkelingen/testen in TEST/DEV. Vanuit UAt kan er dan snel getest worden en vlot doorgepusht naar PROD. Is de hotfix geaccepteerd is het uiteraard van belang dat deze ook in de MASTER branch gemerged wordt (samen met de nieuwste ontwikkelingen) zodat deze later niet verloren gaat.

DEVOPS

Zoals al in voorgaande tekst aangehaald is dit model vooral handig en sterk indien er een DEVOPS omgeving aanwezig is met (semi) geautomatiseerde deploys. Dit in combinatie met een outsourced BUILD IT departement. De RUN die de devops ondersteunt kan intern zijn maar evengoed outsourced op zichzelf (managed services). Dit neemt echter niet weg dat zelfs bij manuele deploys dit model visibiliteit en zekerheid geeft aan de releases.