Source control met meerdere release channels

[NickThissen]

Ik werk in een klein "team" (3 mensen waarvan 2 hoofdzakelijk programmeren) aan een applicatie. De applicatie is al een tijdje uitgebracht maar we brengen zo vaak mogelijk nieuwe updates uit met nieuwe features / bug fixes.

De laatste tijd wordt development ingewikkeld genoeg dat we vaak tegen problemen aanlopen die niet voorzien waren, bijvoorbeeld een nieuwe feature die toch niet helemaal werkt als gepland, of een bug fix die neven effecten heeft waardoor andere dingen ineens niet meer werken.

We willen graag overstappen op een systeem met meerdere release channels, namelijk "stable", "beta" en "alpha", zodat gebruikers kunnen kiezen of ze een stabiele versie met weinig updates willen (stable), of juist meteen de nieuwste updates met een kans dat het niet goed werkt (alpha).

Dit is inmiddels alleen werkend, maar we lopen nu tegen problemen in onze source control (git). Hoe verwerken we development in drie release channels tegelijk?


Momenteel is onze setup redelijk standaard:
- "master" branch: gelijk aan de huidige release versie. Wordt nooit direct in gewerkt, altijd alleen complete releases.
- "dev" branch: bevat alle veranderingen voor de komende geplande update. Meestal aangepast door merges met feature branches, maar soms ook direct voor kleinere features of bug fixes.
- "xyz" feature branches: grotere nieuwe features of bug fixes die niet in een keer in de dev branch gecommit kunnen worden gaan in een aparte branch tot ze klaar zijn en terug naar dev gemerged worden.


Dit gaat niet meer werken als we meerdere channels willen ondersteunen. Stel dat ik aan een nieuwe feature heb gewerkt en deze in de alpha channel wil releasen. Dan moet ik de dev branch dus aanpassen en releasen. Als iemand daarna een kleine bug fix in de stable branch wil doen, dan kan dat niet zonder dat mijn alpha feature mee komt.


Nu is het eerste idee natuurlijk om voor master en dev branches 3 copies te hebben; master_stable, master_beta, master_alpha, en dev_stable, dev_beta, dev_alpha.

Als ik nu een nieuwe feature in alpha wil releasen kan dat los van eventuele veranderingen aan stable.

Nu loop ik echter tegen mogelijke problemen. Stel het volgende scenario:

- Momenteel is versie "1.0" released.
- Ik begin aan een nieuwe feature. Ik maak een branch vanuit stable en noem deze "feature/x".
- Ondertussen begint iemand anders aan een bug fix in de dev_stable branch.
- De bug fix was klein en werkt goed, dus een nieuwe release "stable 1.1".
- Mijn feature x lijkt te werken maar ik wil hem als alpha releasen omdat er nog niet veel getest is.
- Ik merge "feature/x" naar "dev_alpha". Merge dev_alpha naar master_alpha.
- Ik release versie 1.2 (want 1.1 was al uit) als alpha.

Versie 1.2 (alpha) heeft nu niet de bug fix die versie 1.1 (stable) wel had.

De enige oplossing die ik kan bedenken is dat ik voor mijn alpha release altijd de dev_alpha branch update met de dev_stable branch (stable naar alpha mergen). Hetzelfde voor beta channel. Dan heb ik in ieder geval alle updates.

Maar dit geeft weer problemen:
1. Misschien is er nog iemand bezig in dev_stable en is deze nog niet klaar voor release?
2. Misschien bijten de veranderingen in dev_stable met mijn update in dev_alpha. Als de alpha release straks dus getest is, moet hij eigenlijk opnieuw getest worden met de veranderingen van de stable channel die er nu nog niet in zaten. Zo kan ik wel bezig blijven en kunnen we dus nooit een stable release uitbrengen.


Hier moet toch wel een systeem voor zijn wat standaard is? Ik heb te weinig ervaring met git en relatief grotere projecten en ik zie geen oplossing

Hoe zorg ik er voor dat we altijd een release kunnen maken in elke channel, zonder dat we tegen problemen lopen zoals releases die vorige updates weer ongedaan maken, of features die niet samen getest zijn, of...

[ThomasG]

Wat je zou kunnen doen is bijvoorbeeld 's nachts via een automatisch taak een build tool draaien, bijvoorbeeld maven of gradle (bij een java project). Wanneer dit succesvol compiled en de alle unit tests voldaan zijn, zou je het automatisch kunnen pushen naar bijvoorbeeld een nightly branch.

Verder zou ik persoonlijk niet direct op de develop branch werken, ook niet voor bug fixes. Maar daar eigen branches voor maken.

[Exterazzo]

Dit is wel een interessant artikel over branching in Git: http://nvie.com/posts/a-successful-git-branching-model/

Als je gebruikt maakt van release branches, kun je ook het volgende hanteren:

master --> stable (ten minste het zou altijd stable moeten zijn)
release --> beta
develop --> alpha (unstable)

SemVer werkt ook volgens dat stramien: http://semver.org/ En GitVersion is een tool die semantisch versioneert op basis van je git repository: https://github.com/GitTools/GitVersion

Als je een bugfix hebt op master, maak je daarvan (in Gitflow) een hotfix aan. Die moet je dan daarna terug mergen naar master, de release branch en develop.

Om ervoor te zorgen dat je develop branch altijd build, kun je afdwingen dat iedereen op een feature branch werkt en pas als dat werk klaar is, wordt die gemerged naar master.

[NickThissen]

Exterazzo schreef op maandag 11 september 2017 @ 20:22:
Dit is wel een interessant artikel over branching in Git: http://nvie.com/posts/a-successful-git-branching-model/

Als je gebruikt maakt van release branches, kun je ook het volgende hanteren:

master --> stable (ten minste het zou altijd stable moeten zijn)
release --> beta
develop --> alpha (unstable)

SemVer werkt ook volgens dat stramien: http://semver.org/ En GitVersion is een tool die semantisch versioneert op basis van je git repository: https://github.com/GitTools/GitVersion

Als je een bugfix hebt op master, maak je daarvan (in Gitflow) een hotfix aan. Die moet je dan daarna terug mergen naar master, de release branch en develop.

Om ervoor te zorgen dat je develop branch altijd build, kun je afdwingen dat iedereen op een feature branch werkt en pas als dat werk klaar is, wordt die gemerged naar master.

Bedankt, dat artikel lijkt wel nuttig.

Wat ik nog een beetje mis is de "release --> beta" stap. Wat is release in dit geval precies en hoe is het anders dan master?

Waar ik wel al achter ben, denk ik, is dat het niet zinnig is om een aparte "schone" branch aan te houden voor alpha. Alpha is nou eenmaal een work in progress build, dat zou eigenlijk gewoon een rechtstreekse build vanuit de development moeten zijn. Als die niet werkt, nou ja, dat is te verwachten voor alpha. Als het moet werken moet ik er een beta van maken. Is dit logisch?

[NickThissen]

Ok, ik snap het nu iets beter.

Waar ik nog tegenaan loop is het volgende scenario:

Stel ik wil een nieuwe feature testen die misschien helemaal niet gaat werken (want bugs, of zelfs omdat het gewoon niet nuttig blijkt te zijn). Dat zou voor mij prima in een alpha build passen. Dus ik maak een nieuwe feature branch, maak de feature, merge naar develop, en release dan de develop branch als een alpha build.

Nu komt mijn collega die een beta build wil maken van de volgende release die bijna klaar is. Dit kan nu niet meer want ik heb net een nieuwe incomplete feature in develop gemerged. De beta build moet dus wachten tot de alpha feature klaar is (ofwel gefixed, ofwel weer eruit gesloopt).

Dit gaat dus een beetje tegen het hele principe in; ik wil juist onafhankelijke channels hebben zodat ik een alpha build kan releasen met incomplete features, terwijl tegelijkertijd een beta of stable build gemaakt kan worden van eerder gemaakte features die wel al beter werken. Zodra ik mijn alpha build naar develop ga mergen (wat wel nodig is als ik meerdere features wil combineren) dan hangt iedereen daar op te wachten met eventuele volgende releases.

Wat mis ik nu?


Om iets meer uit te leggen, in mijn gedachten is de bedoeling van de channels als volgt:
- alpha: nieuwe features, zodra we ze bedenken, incompleet of met bugs als dat niet al te onvermijdelijk is.
- beta: in principe een compleet werkende build met volledige features en voor zover bekend geen bugs. Maar nog niet "in het wild" getest, enkel door devs.
- stable: eigenlijk hetzelfde als beta, maar dan inclusief bug fixes die nog nodig waren die door beta aan het licht kwamen.

Van beta-->stable komen dus geen nieuwe features; zodra een beta build uit is moeten nieuwe features wachten tot de volgende build. Enkel bug fixes die bekend worden tijdens de beta build worden in stable meegenomen.

Problemen in de stable build (hopelijk niet, maar komt vast voor) zijn dan op te lossen met een hotfix, zoals beschreven in bovenstaand artikel.


Maar dit geeft me dus niet de gescheiden channels die ik wil. Ik kan niet een alpha build maken om een nieuwe feature aan het publiek te laten zien of testen, want zodra ik die build wil maken moet het naar develop en dan kan er geen nieuwe beta meer gemaakt worden.

De enige oplossing die ik zie is om direct uit een feature branch te gaan releasen (enkel alpha uiteraard). Dat zou werken denk ik, maar dan kun je dus weer niet meerdere features tegelijk releasen in een alpha.

[ Voor 36% gewijzigd door NickThissen op 11-09-2017 23:29 ]

[momania]

Klinkt misschien een beetje bot, maar als je met een team van 3 denkt aan alpha, beta, etc. releases is er iets gruwelijk mis met de kwaliteit die jullie leveren. Dat zijn release labels voor grote projecten waar tientallen developers aan werken die vooral ook over de hele wereld verspreid zijn en waarbij er misschien zelfs ook klant specifieke releases gemaakt moeten worden.
Met 3 man wil je niet meer dan een master branch en release tags. Alles gaat naar master met een centrale build (incl. wat component en integration tests), breek je de build, dan fix je het en zo weer verder. Als je nu al met statements komt als "want bugs, of zelfs omdat het gewoon niet nuttig blijkt te zijn" in een team van 3, ben je je eigen graf aan het graven..

[NickThissen]

momania schreef op maandag 11 september 2017 @ 23:33:
Klinkt misschien een beetje bot, maar als je met een team van 3 denkt aan alpha, beta, etc. releases is er iets gruwelijk mis met de kwaliteit die jullie leveren. Dat zijn release labels voor grote projecten waar tientallen developers aan werken die vooral ook over de hele wereld verspreid zijn en waarbij er misschien zelfs ook klant specifieke releases gemaakt moeten worden.
Met 3 man wil je niet meer dan een master branch en release tags. Alles gaat naar master met een centrale build (incl. wat component en integration tests), breek je de build, dan fix je het en zo weer verder. Als je nu al met statements komt als "want bugs, of zelfs omdat het gewoon niet nuttig blijkt te zijn" in een team van 3, ben je je eigen graf aan het graven..

Ik snap wat je bedoelt, maar ik ben het er niet helemaal mee eens. Het project is inmiddels best wel groot, en we zijn momenteel bezig aan een hele grote update die heel veel dingen gaat veranderen, zowel voor de user experience als op de back-end. Dit willen we niet meteen als een stable release uitbrengen, want er zitten zoveel veranderingen in dat het ten eerste vast niet voor iedereen goed werkt, en ten tweede zullen er vast mensen zijn die dingen graag net anders hadden gezien. We kunnen nu eenmaal niet de mening van elke gebruiker gokken.

Veel gebruikers gebruiken de applicatie vaak en het is belangrijk dat hij niet ineens door een update niet meer werkt. Sure, ze kunnen terugdraaien naar de vorige versie, maar dat is ook niet de bedoeling. Liever dat we een specifieke beta of alpha build uitbrengen die mensen kunnen proberen als ze daar zin in hebben, en andere mensen kunnen negeren als ze nu behoefte hebben aan het oude vertrouwde wat nog werkt.

Zowel alpha als beta is misschien wat overdreven, ik denk dat enkel beta/stable genoeg is, maar dat kan later nog altijd beslist worden (probleem blijft hetzelfde).

Lang verhaal kort, we willen gewoon een manier hebben om nieuwe features te testen om te zien of ze in de smaak vallen en om te zien of het allemaal goed draait op verschillende hardware. Hoe stel je voor dit te doen zonder aparte releases?

De nieuwe features die we nu willen uitbrengen zijn al heel lang in ontwikkeling. We doen dit als hobby voor erbij en kunnen er helaas niet 8u per dag aan werken dus soms duurt het lang. In al die tijd willen we niet dat de 'stable' branch stil ligt en geen updates meer krijgt.


Juist omdat we maar met 3 mensen zijn lopen we wat vaker tegen bugs aan die we niet zelf hadden gevonden. De applicatie is ingewikkeld genoeg dat de gebruikers soms dingen verzinnen die we zelf nooit hadden bedacht. We hebben een paar mensen die graag voor ons testen, en momenteel stuur ik die mensen soms een handmatige build wanneer ik echt bang ben dat het mis zal gaan, maar dat werkt natuurlijk ook niet lekker.

Ik zou graag met een serieuze groep testers gaan werken, maar dan juist heb ik toch alpha/beta releases nodig?

[ Voor 9% gewijzigd door NickThissen op 11-09-2017 23:46 ]

[Exterazzo]

Bij ons is het zo ingericht dat onze buildserver elke branch (master, develop, maar ook feature branches, hotfixes etc) oppikt en hiervoor unit tests (etc) gaat draaien.

Release packages maken we echter alleen maar van de 3 boven genoemde branches. Maar niks houdt ons tegen om een release package te maken van een feature build.

Dus, er vanuit gaande dat je een buildserver hebt, zou je deze zo kunnen inregelen dat elke commit automatisch een nieuwe release package oplevert. Of je dat zou moeten willen, is een tweede. Maar het kan wel.

[johnkeates]

Een van de problemen veroorzaak je zelf: als je een brakke commit pusht maak je dus een branch stuk. Je kan prima als regel instellen dat je geen onzin gaat pushen tot dat het gecontroleerd is.

https://www.atlassian.com...orkflows/gitflow-workflow

Je hebt niet een magische branch nodig voor releases o.i.d., uiteindelijk is alles slechts een commit hash, verder niks. Als je zorgt dat je met compacte units of work werkt en redelijke engineering handhaaft m.b.t. cohesie en koppeling kan je voor productie builds (releases) altijd een werkende versie opleveren.

[P_Tingen]

Je kunt build servers ook zo inrichten dat ze gaan deployen op basis van een tag. Dus als jij een tag 'beta' aan een commit geeft, zou je buildserver los kunnen gaan. Als je zou willen.

Vwb aantal branches: ik heb zelf een hobbyproject waarbij ik een stable en een betaversie heb. Alles gaat via GitHub en als ik denk dat iets stabiel genoeg is, maak ik er een nieuwe release van en markeer die als pre-release:

Ondertussen werk ik weer verder. Nieuwe dingen doe ik vanaf dat moment in feature branches die pas gemerged worden als ze rijp zijn voor de beta. Bugfixes op nieuwe dingen in de beta gaan direct op de beta branch zelf. Dit werkt voor mij erg prettig omdat ik uiteindelijk maar 1 hoofdbranch heb (master) en daarnaast 1 feature branch. En omdat ik de enige ontwikkelaar ben, heb ik 1 feature branch met de naam develop.

[ThomasG]

P_Tingen schreef op dinsdag 12 september 2017 @ 13:03:
En omdat ik de enige ontwikkelaar ben, heb ik 1 feature branch met de naam develop.

Zelfs als je de enige ontwikkelaar bent kun je meerdere feature branches hebben. Je kunt namelijk meerdere nieuwe features plannen/hebben, waarbij sommige langer duren dan de andere. Ik heb geregeld meerdere feature branches die ik nog niet kan mergen in develop, maar wel aan verder werk.

[P_Tingen]

ThomasG schreef op dinsdag 12 september 2017 @ 13:33:
[...]
Zelfs als je de enige ontwikkelaar bent kun je meerdere feature branches hebben. Je kunt namelijk meerdere nieuwe features plannen/hebben, waarbij sommige langer duren dan de andere. Ik heb geregeld meerdere feature branches die ik nog niet kan mergen in develop, maar wel aan verder werk.

Klopt, ik heb dat ook wel een tijdje gehad, maar het risico daarvan is dat ik helemaal los ga en vervolgens met tien branches zit. Op zich niet zo erg, maar als die maar lang genoeg bestaan, wordt rebasen steeds lastiger.

Dat wordt ook nog eens bemoeilijkt omdat mijn ontwikkelomgeving een deel van de code genereert en dit deel lijkt zo ongeveer bij elke verschillende versie van mijn omgeven nét weer iets anders. Daarom ben ik maar weer teruggegaan naar 1 ontwikkelbranch. Dit dwingt mijzelf ook om een beetje structuur aan te houden en dingen ook echt af te maken voor ik weer met wat anders begin.

[Cronax]

Volgens mij hangt de 'beste' strategie voor de situatie een beetje af van wat de exacte situatie is. Waarschijnlijk is de oplossing om te gaan werken volgens gitflow (zoals eerder genoemd en gelinkt) en te bepalen wat er nou precies met iedere versie moet gebeuren.

Eerst de grote hamvraag: hoe testen jullie?

Als je alleen zelf test voor je een release in productie gooit, is de kans vrij groot dat je in productie tegen problemen aan gaat lopen, hoe goed je unittesten ook zijn (je doet toch hopelijk aan unittesten?)

Als je een tester hebt die het geheel bekijkt vóór het in productie gaat, wordt de kans op problemen al een stuk kleiner, afhankelijk van hoe veel tijd de tester krijgt om alles door te testen en de kwaliteit van je (al dan niet geautomatiseerde) regressietesten.

Als je naast de tester ook acceptatietesten doet, haal je nóg meer problemen uit je product voor de livegang.

Hoe dan ook zou ik altijd volgens gitflow werken:
Je hebt een Master branch waar niet direct naar gecommit wordt, die altijd getest moet zijn en klaar moet zijn om direct live te gaan.

Daarnaast heb je de development branch, die hoeft niet 100% getest te zijn maar alles wat hier terecht komt moet in een testbare staat zijn, dus je moet er zelf al even naar gekeken hebben om te zien of het werkt.

Het daadwerkelijke werk doe je in zogeheten feature-branches (soms onterecht 'future branches' genoemd...). Een feature branch beperkt zich tot een feature (vandaar de naam) en bevat dus ook alleen de code die voor die feature nodig is. Hotfixes en bugfixes horen daar dus niet bij, die krijgen ofwel aparte branches (voor grote fixes) ofwel worden op de development branch gemaakt (voor hele kleine fixes). Als een feature klaar is en op je eigen machine goed lijkt te werken, kan je hem mergen naar development (liefst wordt de merge gedaan door een collega developer die gelijk even kijkt of je geen spaghetti bolognese code hebt geschreven, maar vooruit).

Wanneer het dan tijd is om een release te gaan maken, maak je vanaf development weer een aparte branch aan: een release branch. Dit is de build die uitgebreid getest wordt en als deze goed bevonden wordt, wordt hij gemerged naar de Master branch. De master branch wordt getagged met het nieuwe versienummertje en vervolgens wordt daar vandaan de build gemaakt die in productie gaat.

Als je reactie nu iets is van "ja maar daar heb ik toch heul geen tijd voor, dat is toch zware overkill!?!", dan heb ik mijn antwoord al klaar:
Ten eerste kost dit helemaal niet zo veel tijd als je er eenmaal aan gewend bent met zijn allen en een zekere maat van discipline hebt ontwikkeld om altijd even te checken op welke branch je zit voor je commit, etc. Ten tweede wordt die tijd ruimschoots gecompenseerd door het feit dat je een stuk minder 'oops' momentjes hebt en ook niet hoeft te wachten tot de branch weer stabiel is voor je kan gaan testen.

[Cronax]

P_Tingen schreef op dinsdag 12 september 2017 @ 15:00:
[...]

Klopt, ik heb dat ook wel een tijdje gehad, maar het risico daarvan is dat ik helemaal los ga en vervolgens met tien branches zit. Op zich niet zo erg, maar als die maar lang genoeg bestaan, wordt rebasen steeds lastiger.

Dat wordt ook nog eens bemoeilijkt omdat mijn ontwikkelomgeving een deel van de code genereert en dit deel lijkt zo ongeveer bij elke verschillende versie van mijn omgeven nét weer iets anders. Daarom ben ik maar weer teruggegaan naar 1 ontwikkelbranch. Dit dwingt mijzelf ook om een beetje structuur aan te houden en dingen ook echt af te maken voor ik weer met wat anders begin.

Hoezo wordt rebasen lastiger dan? Als code af genoeg is om ergens anders te gebruiken, zit die als het goed is in development gemerged en kan je dus gewoon vanaf development mergen. Als de code nog in een feature branch leeft, moet je misschien eerst die feature ff afmaken voor je er iets op gaat bouwen, maar als je iets specifieks nodig hebt kan je toch cherry-picken?

[NickThissen]

Een hoop informatie, bedankt allemaal. Maar ik mis nog steeds een beetje de hamvraag waar ik naar op zoek ben, namelijk hoe ga ik nu om met releases in verschillende channels (alpha, beta, stable)?

Laten we voor de eenvoudigheid even alpha weg denken. Ik wil in ieder geval een stable channel en een beta channel waarop nieuwere features komen die wellicht nog niet genoeg getest zijn.

Om een vraag te beantwoorden "hoe testen jullie": momenteel testen we voornamelijk zelf, en dat is precies het pijnpunt. We lopen inderdaad tegen problemen die we niet verwacht hadden in "productie". Dat zet ik even tussen haakjes want het gaat hier niet om een duur product dat klanten kopen ofzo, tot nu toe geven we alles gratis weg (wel plannen om met subscriptions te gaan werken in de toekomst).

In principe hebben we de software tot nu toe altijd een beta genoemd; het is namelijk nog volop in ontwikkeling. Maar mensen gaan er meer en meer van gebruik maken en het wordt nu tijd om na te gaan denken over stabiele versies. Vooral als we straks geld gaan vragen, dan mag het niet meer zomaar mis gaan in productie.

Dus we willen inderdaad testers gaan gebruiken. Maar hoe regelen we dat? De makkelijkste manier is hoe we het nu doen: gewoon alle geplande nieuwe features die klaar zijn in de master branch, een nieuwe release uitbrengen, en doorsturen naar de testers. Lopen die nog tegen iets aan, dan passen we het aan en komt er weer een nieuwe release, etc. Tot die tijd ligt de ontwikkeling voor de rest van de mensen dus eigenlijk stil. We kunnen geen bug fix doorvoeren zonder meteen de hele sloot aan nieuwe features mee te geven, die wellicht nog niet werken.

Vandaar dat ik graag op z'n minst een apart channel heb waarop we de testers kunnen laten werken. En dit channel wil ik ook graag publiek maken voor mensen die gewoon interesse hebben om te helpen, of gewoon willen zien wat er gaat komen.

De hele flow met github van dev branch naar release branch naar master branch en feature branches gebruiken we nu in principe ook al (in iets mindere mate, we gaan meteen van dev naar master), maar daarmee hebben we dus niet genoeg flexibiliteit om meerdere channels apart te ondersteunen.

Heel simpel gezegd wil ik aan een grote nieuwe feature kunnen werken die maanden gaat kosten. Die wil ik af en toe (om de paar weken?) uitbrengen in een beta channel zodat mensen hem eens kunnen proberen. Bevalt het, werkt het, missen er nog features, etc. Tegelijkertijd wil ik de huidige versie van de software wel blijven ondersteunen, voornamelijk met bugfixes maar ook simpele nieuwe features. Dit kan momenteel dus niet tegelijk.

Helaas heb ik nog steeds geen oplossing voor ogen die in alle gevallen werkt


Mijn oplossing zou zijn om het eerder genoemde model te gebruiken:
http://nvie.com/posts/a-successful-git-branching-model/

In dat geval zou ik de master en release branches als stable benoemen. Als ik een beta build wil uitbrengen, dan maak ik een build rechtstreeks van de develop branch. Daar zitten dus misschien features in die net gemerged zijn en nog niet getest, maar dat is het hele idee van beta dus geen probleem.
Wil ik een alpha build maken, dan kan ik dat rechtstreeks uit een feature branch doen. Grote kans dus dat deze niet goed werkt, maar dat is ook te verwachten voor een alpha.

[ Voor 10% gewijzigd door NickThissen op 13-09-2017 14:19 ]

[Cronax]

Met mijn hele verhaal doelde ik inderdaad op gitflow (zoals beschreven in de link die je noemt), ik probeerde het alleen wat tastbaarder te maken door wat praktijkvoorbeelden.

Hoe je het praktisch inricht is voor mij vooral afhankelijk van hoeveel testomgevingen je hebt.

In de ideale situatie heb je een 'hardware pool' waar je naar wens testomgevingen in kan aanmaken, met een mooie volledig geautomatiseerde buildstraat die triggert wanneer er gecommit wordt naar een bepaalde branch, die code gaat bouwen en op een virtual machine/docker zet, die virtual machine/docker in de hardware pool plaatst en aanzet, de unittesten en geautomatiseerde regressietesten uitvoert en als die succesvol zijn tot slot een mailtje stuurt naar de tester met daarin de link naar de testomgeving en de inhoud van de commit (aka 'wat er handmatig getest kan worden'). Op deze manier kan je gewoon lekker blijven doorontwikkelen met zijn allen en kan de tester ook fatsoenlijk zijn werk doen.

In de praktijk zal je in het begin één of twee testomgevingen hebben, zal je geen geautomatiseerde buildstraat hebben en zal er iedere sprint relatief veel tijd gaan zitten in het maken van builds en het bijwerken en onderhouden van die testomgeving(en).

Hopelijk merkt je team en het management dan vrij snel op dat daar best veel tijd in gaat zitten en wordt er tijd/geld geregeld voor extra hardware en het configureren van een degelijke buildstraat met depolyment naar de testomgevingen na een druk op de knop. Helaas zien veel mensen (met name managers...) dit als 'overbodig' en 'overdreven' want alle tijd die gestoken wordt in het opzetten van dit alles had ook gespendeerd worden aan code kloppen. Dat het doorgaans minder tijd kost om het één keer te automatiseren dan dat het kost om iedere keer weer handmatig het hele riedeltje af te gaan wordt voor het gemak maar even vergeten .