:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
Ja, dan lees je zo'n titel, en dan denk je, w*f bedoelt die vent...
Dus eerst een situatie schets.
We (@ $klant waar ik gedatacheerd zit) zijn bezig met een grote update/upgrade van de beheer tooling. Nieuwe versie van Puppet, nieuwe versie van Jenkins, nieuwe versie van de Deployment tooling, alle puppet modules bijwerken, je kent het wel.
Wat we voorheen hadden, was 2 puppet servers, 1 lab omgeving, en 1 productie omgeving. De code zat in een SVN repository, welke door middel van een branch met de naam "PROD" gesynchroniseerd werd. (Dus je commit in de trunk, is code klaar, move/copy/of whatever je het naar de PROD branch, je gaat naar de productie machine en je doet een svn up.)
Omdat dit systeem toch niet zo betrouwbaar en stabiel is, zijn we overgestapt naar R10k, Meer(dere) environments, Git en tagged versies van modules elk in hun eigen Git repository.
Allemaal goed en wel, maar we willen ook graag Auditing gaan toepassen. De workflow die we willen toepassen is: Je mag altijd commit naar de repository van waar de code staat, maar om code in een omgeving te zetten moet deze getagged zijn, en om de tag in productie te nemen moet je een R10k control file wijzigen.
Juist *die* change willen we reviewen/auditen. Dus we gaan niet zitten kijken wat je allemaal doet om je code werkend te maken, we gaan reviewen welke moduleversies er naar welke omgeving gaan. Daar aan vast kijken we wat de impact is van zo'n versiebump. Individuele code auditen kan in een later stadium ook nog, maar is out-of-scope voor dit topic.
We hebben gekeken naar Gerrit en Phabricator om deze workflow te ondersteunen, maar de tooling is veel te ingewikkeld voor wat we willen namelijk: *eenvoudig* commits reviewen.
Ik wil eigenlijk dat we een git commit reviewen per stuk, dus niet in een branch, niet tientallen changes door elkaar, geen rare rebase / merge acties, gewoon 1 commit (of beter gezegd, 1 push).
Zolang de change niet is goedgekeurd, moet de git repo gewoon op slot. Er is in principe toch maar 1 persoon die die file wijzigt, en het moet simpel en duidelijk zijn voor de beheerders hoe het review/auditing proces werkt. Als ik kijk naar alle workflows die Gerrit en Phabricator ondersteund, duizelt het mij (en ik ben afgestudeerd programmeur en werk best veel met Git).
Laat staan dat onze DBA'ers van 55+ dit systeem goed gaan gebruiken...
Weet iemand of er een (miniscuul) tooltje is om deze workflow mogelijk te maken?
Dus eerst een situatie schets.
We (@ $klant waar ik gedatacheerd zit) zijn bezig met een grote update/upgrade van de beheer tooling. Nieuwe versie van Puppet, nieuwe versie van Jenkins, nieuwe versie van de Deployment tooling, alle puppet modules bijwerken, je kent het wel.
Wat we voorheen hadden, was 2 puppet servers, 1 lab omgeving, en 1 productie omgeving. De code zat in een SVN repository, welke door middel van een branch met de naam "PROD" gesynchroniseerd werd. (Dus je commit in de trunk, is code klaar, move/copy/of whatever je het naar de PROD branch, je gaat naar de productie machine en je doet een svn up.)
Omdat dit systeem toch niet zo betrouwbaar en stabiel is, zijn we overgestapt naar R10k, Meer(dere) environments, Git en tagged versies van modules elk in hun eigen Git repository.
Allemaal goed en wel, maar we willen ook graag Auditing gaan toepassen. De workflow die we willen toepassen is: Je mag altijd commit naar de repository van waar de code staat, maar om code in een omgeving te zetten moet deze getagged zijn, en om de tag in productie te nemen moet je een R10k control file wijzigen.
Juist *die* change willen we reviewen/auditen. Dus we gaan niet zitten kijken wat je allemaal doet om je code werkend te maken, we gaan reviewen welke moduleversies er naar welke omgeving gaan. Daar aan vast kijken we wat de impact is van zo'n versiebump. Individuele code auditen kan in een later stadium ook nog, maar is out-of-scope voor dit topic.
We hebben gekeken naar Gerrit en Phabricator om deze workflow te ondersteunen, maar de tooling is veel te ingewikkeld voor wat we willen namelijk: *eenvoudig* commits reviewen.
Ik wil eigenlijk dat we een git commit reviewen per stuk, dus niet in een branch, niet tientallen changes door elkaar, geen rare rebase / merge acties, gewoon 1 commit (of beter gezegd, 1 push).
Zolang de change niet is goedgekeurd, moet de git repo gewoon op slot. Er is in principe toch maar 1 persoon die die file wijzigt, en het moet simpel en duidelijk zijn voor de beheerders hoe het review/auditing proces werkt. Als ik kijk naar alle workflows die Gerrit en Phabricator ondersteund, duizelt het mij (en ik ben afgestudeerd programmeur en werk best veel met Git).
Laat staan dat onze DBA'ers van 55+ dit systeem goed gaan gebruiken...
Weet iemand of er een (miniscuul) tooltje is om deze workflow mogelijk te maken?
Even niets...
:strip_exif()/u/128904/hoagie_ani.gif?f=community)