OTAP Straat, problemen met diverse commits

[Douweegbertje]

We draaien een tijdje met een OTAP straat en dat gaat eigenlijk best prima.

ticket branche -> PR test -> PR Accept -> Klant akkoord (soms) -> PR production

So far so good, alleen komt het dus voor dat er meerdere tickets zijn (feature/bugfix of w/e) en dat op een gegeven moment alles op accept staat. Uiteindelijk kan het dus voorkomen dat er 9 tickets goed gekeurd zijn maar 1tje niet. Op dat moment hou je het proces eigenlijk tegen dat alles naar production kan.
Nu kan je dan wel 1 commit reverten maar eigenlijk is dat 1 commit vanuit test...

We hebben wat discussies gehad over hoe je hier mee om kunt gaan, maar ik ben eigenlijk benieuwd naar hoe jullie hier mee omgaan.

Overigens is het wel zo dat het echt kleine projectjes zijn, en daar zijn er soms wel 100 verschillende van. 1 iemand die een groot globaal overzicht heeft en dit bewaakt is daarom ook erg lastig.

[NMe]

Nog niet goedgekeurd? De wel goedgekeurde commits in de productiebranch naar binnen mergen en dat releasen terwijl je de feature die nog niet goedgekeurd is doorontwikkelt. Ronduit afgekeurd? Code van die feature branch trashen en verder hetzelfde verhaal.

[Sircuri]

Wij hebben hier (simpel gezegd) 3 branches voor in versiebeheer. DEV, TEST en PROD. Elk ontwikkelde feature gaat van DEV naar test en pas na akkoord naar de PROD branch. Een niet geaccepteerde ticket zit dus niet in de PROD branch. Of snap ik nu niet helemaal wat je bedoelt?

[Douweegbertje]

Nou je gaat van een feature branche naar test. De programmeur test zijn meuk op test en als dat goed gaat dan gaat het door naar accept voor de klant. Uiteindelijk commit je dan vanuit test naar accept. Het kan net zo goed zijn dat er andere mensen ook bezig zijn en dat je uiteindelijk meerdere commits in 1x merged vanuit test naar accept.
Je kan volgens mij dan niet zo heel goed een bepaalde feature uit je accept halen omdat zo iets uit 1 merge is gekomen. Het gaat er uiteindelijk om dat je een soort vervuilde c.q. niet werkbare accept omgeving hebt, omdat het dus goed kan voorkomen dat je niet de release van accept -> prod/master kunt maken omdat er dingen op accept staan die er nog niet horen te staan.

[Ramon]

Om dit mooi op te lossen zou je bwvs automatisch feature branches naar subdomeinen willen deployen.

Stel je bent bezig met een feature 'menu-update', dan zou het mooi zijn als je in je issue management systeem kan aangeven ready for client test, en dat er dan een url bij komt te staan 'http://menu-update.test.sitedomein.nl', klant kan testen, geeft feedback en bij akkoord kan jij de feature branch verder mergen.

[Wiebeltje]

Bij ons maken we vaak een sprint (feature) branch aan waar we alle losse features in mergen. Acceptatie staat dan op deze sprint branch. Als iets op het eind van de sprint nog niet akkoord is kun je wel alle losse features al sluiten (mergen naar develop) die wel akkoord zijn. De sprint branch kun je dan eventueel weg gooien en een nieuwe aanmaken. Verder maken we gebruik van git flow.

Ik ben wel benieuwd hoe andere dit oplossen.

[ Voor 7% gewijzigd door Wiebeltje op 22-08-2016 23:48 ]

[DJMaze]

Douweegbertje schreef op maandag 22 augustus 2016 @ 23:26:
Nou je gaat van een feature branche naar test. De programmeur test zijn meuk op test en als dat goed gaat dan gaat het door naar accept voor de klant. Uiteindelijk commit je dan vanuit test naar accept. Het kan net zo goed zijn dat er andere mensen ook bezig zijn en dat je uiteindelijk meerdere commits in 1x merged vanuit test naar accept.

Daar gaat het dus fout.

Neem bijvoorbeeld ook het volgende probleem: Wat nou als je een security bug of hotfix wil uitrollen naar verschillende releases?

In alle gevallen heb je dus een structuur nodig die werkt.

code:

O  T  A  P
*  |  |  |
|->|  |  |
|---->|  |
|------->|

Dus niet:
O  T  A  P
*  |  |  |
|->|  |  |
|  |->|  |
|  |  |->|

In de eerste structuur merge je * afzonderlijk
In de tweede structuur zit je dus vast

Meer complex met features 1, 2 en 3
1 en 3 staan op Test
Test is compleet en 1 & 3 gaan naar Acceptatie
2 gaat naar Test
Test is compleet en 2 gaat naar Acceptatie
Klant accepteerd 1 & 2 maar keurt 3 af.
1 & 2 kunnen nu naar Productie

code:

O1 O2 O3 T  A  P
*  |  |  |  |  |
|------->|  |  |
|  |  *  |  |  |
|  |  |->|  |  |
|  |  |---->|  |
|---------->|  |
|  *  |  |  |  |
|  |---->|  |  |
|  |------->|  |
|------------->|
|  |---------->|

Nog maar te zwijgen of 1 & 3 nog werken op Test na het mergen van 2

[Hydra]

Wij werken met een microservice architectuur en deployen ook per microservice. Dus als 1 issue een service blokkeert dan is dat 'ff jammer'. Het uit mekaar pulken van code lijkt mij persoonlijk niet wenselijk.

Ik zou zelf eerder kijken naar hoe het komt dat features niet 'af' zijn. Het lijkt erop alsof de eind-users meer betrokken moet worden in het proces en dat features op het moment dat ze 'completed' zijn aangeboden moeten worden op de gebruiker en pas als een eerste akkoord er is deze doorgaan de deployment in.

Hier (ING) moet je van goede huize komen om een feature die op Accept staat niet door te laten gaan naar Prod. Dan hou je gewoon de hele release tegen.

[Creepy]

DJMaze schreef op dinsdag 23 augustus 2016 @ 00:07:
[...]

Daar gaat het dus fout.

Neem bijvoorbeeld ook het volgende probleem: Wat nou als je een security bug of hotfix wil uitrollen naar verschillende releases?

In alle gevallen heb je dus een structuur nodig die werkt.

code:

O  T  A  P
*  |  |  |
|->|  |  |
|---->|  |
|------->|

Dus niet:
O  T  A  P
*  |  |  |
|->|  |  |
|  |->|  |
|  |  |->|

toon volledige bericht

Het zal wel aan mij liggen maar wij zorgen er hier toch echt voor dat het van O -> T -> A -> P gaat, en dan de release als geheel. Direct vanuit O naar P lijkt me niet wenselijk want nu kan je niet meer garanderen dat wat op A stond naar P is gegaan. Los daarvan is van git het leuke dat het eigenlijk niet boeit vanuit welke branch je merged/commit aangezien ze (zeker vanaf T) in tijd hetzelfde zouden moeten zijn.

Je moet dan ook niet denken in losse features. Er komt een moment dat het 1 geheel wordt en dat moet vanaf O naar T en verder. Als dat niet lukt blijf je altijd de problemen houden die Douweegbertje beschrijft. Je gaat er dan ook niet aan ontkomen een release uit te stellen als er iets inzit wat de klant niet accepteerd. Maar eigenlijk moet je al veel eerder met de klant zitten over de gekozen werkwijze/oplossing zodat je tijdens het ontwikkelen al zo goed al zeker weet dat je het juiste voor de klant aan het maken bent. De A is dan vaak niet meer dan een formaliteit tenzij er 1 of andere rare bug is ingeslopen.

Als je verschillende klanten hebt die verschillende features hebben, dan heb je dus een release per klant (!) en dus eigenlijk ook een OTAP per klant nodig.

[pacificocean]

Dat is toch gewoon ITIL release managment en ITIL configuration management toepassen.

[DJMaze]

Creepy schreef op dinsdag 23 augustus 2016 @ 09:16:
Je moet dan ook niet denken in losse features. Er komt een moment dat het 1 geheel wordt en dat moet vanaf O naar T en verder. Als dat niet lukt blijf je altijd de problemen houden die Douweegbertje beschrijft. Je gaat er dan ook niet aan ontkomen een release uit te stellen als er iets inzit wat de klant niet accepteerd. Maar eigenlijk moet je al veel eerder met de klant zitten over de gekozen werkwijze/oplossing zodat je tijdens het ontwikkelen al zo goed al zeker weet dat je het juiste voor de klant aan het maken bent. De A is dan vaak niet meer dan een formaliteit tenzij er 1 of andere rare bug is ingeslopen.

Als je niet denkt in losse features dan klopt dat.
Hij vraagt echter hoe wij zijn voorgelegde probleem hanteren, het is dus één van:

• release uitstellen
• elke feature afzonderlijk.
• backout feature

In mijn optiek zou O gewoon niet 1 branch moeten zijn.
Ik noem het maar even FOTAP (Feature Ontwikkeling Test Acceptatie Productie)

code:

F1 F2 F3 O  T  A  P
*  |  |  |
|------->|
|  |  *  |
|  |  |->|
|  *  |  |
|  |---->|
|  |  |  |->|  |  |
|  |  |  |  |->|  |
|  |  |<-|  |  |  | BACKOUT F3
|  |  |  |->|  |  |
|  |  |  |  |->|  |
|  |  |  |  |  |->|

Dan kan je altijd nog kiezen voor O -> T -> A -> P of F afzonderlijk zodra een probleem optreed.

[ Voor 6% gewijzigd door DJMaze op 23-08-2016 11:48 ]

[NMe]

DJMaze schreef op dinsdag 23 augustus 2016 @ 11:38:
Dan kan je altijd nog kiezen voor O -> T -> A -> P of F afzonderlijk zodra een probleem optreed.

Daarmee heb je alsnog hetzelfde probleem als in de TS natuurlijk. Maar het is wat mij betreft wel de prettigste manier van werken, ja.

[ANdrode]

Creepy schreef op dinsdag 23 augustus 2016 @ 09:16:
[...]
Het zal wel aan mij liggen maar wij zorgen er hier toch echt voor dat het van O -> T -> A -> P gaat, en dan de release als geheel. Direct vanuit O naar P lijkt me niet wenselijk want nu kan je niet meer garanderen dat wat op A stond naar P is gegaan. Los daarvan is van git het leuke dat het eigenlijk niet boeit vanuit welke branch je merged/commit aangezien ze (zeker vanaf T) in tijd hetzelfde zouden moeten zijn.

Bij OTAP kan je niet meer terug nadat een commit in test terecht komt. Maar wanneer iets in test terecht komt is een keuze. Ik vind zelf een workflow waarbij deze merge plaatsvind nadat de product owner/klant accord is fijn. Hierna gaat er één atomair block door T -> A -> P heen.

Dit in een git flow achtige workflow.



Je hebt alleen wat extra regels nodig om er voor te zorgen dat elke ontwikkel versie goed is. Dat is:

• Alle feature branches/hotfix branches rebase je ten opzichte van de branch die je voor de testomgeving neemt. Bijvoorbeeld 'develop'
• Feature branches moeten rebasen tov develop voordat je weet of de post-merge situatie werkt
• De tests moet je doen per feature branch, na elke keer dat de develop branch verandert. Daarvoor heb je een geautomatiseerd test proces nodig
• Er moet dus ook een voor de klant/product-owner beschikbare VM/container zijn die deze branch gebruikt

Hiermee leg je dus ook de 'serialisatie' van merges van feature branch -> develop vast.

Mits het test proces voldoet zal je blokkerende issues voor de merge naar test tegen moeten komen. Kleine kritieke issues doe je met het hotfix proces uit git flow.
Feitelijke verschil: Dat wordt niet via develop master in ge-merged, maar hotpick/merge je direct naar master vanaf feature branch.

[DJMaze]

ANdrode schreef op dinsdag 23 augustus 2016 @ 14:30:
Je hebt alleen wat extra regels nodig om er voor te zorgen dat elke ontwikkel versie goed is. Dat is:

• Alle feature branches/hotfix branches rebase je ten opzichte van de branch die je voor de testomgeving neemt. Bijvoorbeeld 'develop'
• Feature branches moeten rebasen tov develop voordat je weet of de post-merge situatie werkt
• De tests moet je doen per feature branch, na elke keer dat de develop branch verandert. Daarvoor heb je een geautomatiseerd test proces nodig

Eigenlijk zeg je voor de leken met het plaatje:
Feature = Ontwikkeling
Develop = Test
Release = Acceptatie
Master = Productie

[ Voor 7% gewijzigd door DJMaze op 23-08-2016 14:47 ]

[Creepy]

Ik ben persoonlijk meer fan van deze https://barro.github.io/2...model-considered-harmful/, maar kies wat voor jou het beste werkt. Zolang je maar zeker weer dat wat wat op T heeft gestaan naar A gaan en naar P gaat.

[Douweegbertje]

Uiteindelijk is het toch wel de bedoeling dat wat op test staat getest wordt en wat op acceptatie staat, geaccepteerd gaat worden
Het leukste is dat iedereen wel een bepaald idee heeft maar als het allemaal zo simpel was dan hadden we gelukkig geen discussie zoals die nu is. Het kan gewoon op vele manieren.

In elk geval om een beetje verder te vertellen voor ons verhaal: we gaan binnenkort met een aantal mensen zitten en o.a. is 1 van de grotere punten om mensen goed te informeren over HOE het proces in elkaar zit zodat daar ook naar geleefd wordt. Dat zou al een groot deel van de problemen oplossen.

[ANdrode]

DJMaze schreef op dinsdag 23 augustus 2016 @ 14:47:
[...]

Eigenlijk zeg je voor de leken met het plaatje:
Feature = Ontwikkeling
Develop = Test
Release = Acceptatie
Master = Productie

Eigenlijk wel
Er zijn dus meerdere ontwikkel versies. Acceptatie doe je indien mogelijk (geen externe koppeling) voordat op zo'n versie, voordat je het develop/test in schuift. Daarna kan je namelijk niet meer terug.

Creepy schreef op dinsdag 23 augustus 2016 @ 14:57:
Ik ben persoonlijk meer fan van deze https://barro.github.io/2...model-considered-harmful/, maar kies wat voor jou het beste werkt. Zolang je maar zeker weer dat wat wat op T heeft gestaan naar A gaan en naar P gaat.

Ik besef mij nu dat het een tijd geleden is dat ik die post die ik linkte ook echt gelezen had. Wat ik beschrijf (rebase gebaseerde workflow) veroorzaakt namelijk alleen fast forwards. Dit proces hangt er echt op de development branch "de branch waar vanaf je ontwikkelt" altijd de tests passed en dat je nooit iets merged dat de tests breekt.

Omdat je niet "terug kan" zodra iets in develop zit heb je meerdere omgevingen nodig (of: PO doet dat lokaal) om acceptatie testen (product owner) te doen. Je moet je ook beseffen dat je niet alle feature branches achter elkaar kan mergen zonder te re-basen en her-testen.

Je test de linearisatie van de geschiedenis + één feature branch (n situaties). Niet alle mogelijke linearisaties van feature branches (n! situaties).

De hoeveelheid pijn die je hebt bij merge-klaar maken van een branch van commits hangt dan af van hoeveel parallelle branches er open staan en hoe lang de parallelle branch bestaan heeft.
Je wilt feature die klaar is zo snel mogelijk (product-owner/klant) geaccepteerd hebben.

De integratie moeite schaalt dus mee met het aantal openstaande tickets per programmeur.
Feature branches die al gedeeltelijk geimplementeerd zijn maar die in kanban 'blocked' zijn veroorzaken later dus veel werk als je verder gaat .

[ Voor 12% gewijzigd door ANdrode op 23-08-2016 16:28 ]

[DJMaze]

Douweegbertje schreef op dinsdag 23 augustus 2016 @ 15:15:
In elk geval om een beetje verder te vertellen voor ons verhaal: we gaan binnenkort met een aantal mensen zitten en o.a. is 1 van de grotere punten om mensen goed te informeren over HOE het proces in elkaar zit zodat daar ook naar geleefd wordt. Dat zou al een groot deel van de problemen oplossen.

Iemand zei ooit tegen mij: "Wie werkt maakt fouten, wie veel werkt maakt veel fouten"
De fouten zullen dus blijven. Stel daarom ook de vraag: hoe ga je om met fouten?

[Douweegbertje]

Afstraffen

Nja in het kort: je leert van je fouten en dat is ook een proces. Of je nu het gaat afvangen met code of een systeem of wat dan ook: daar zitten ook fouten in. Naar mijn mening zit het grootste probleem in gebrek aan kennis, duidelijk structuur en een stuk communicatie. Hier zijn wel dingen uit te halen om te verbeteren, maar het zou apart zijn om de gehele werkwijze van OTAP te gaan veranderen omdat het even niet lekker loopt.
IMO kun je dan beter een deel aan de "persoon" kant gaan fixen, en dan later verbeteringen in je systeem/strategie doorvoeren. Anders pas je nu te veel aan terwijl dat misschien absoluut niet nodig is/was.