Recent schreef ik over wat Continuous delivery is en hoe je dit technisch het beste faciliteert. In deze bijdrage ga ik een stapje verder en komt Continuous deployment aan de orde. Ook hier vind je weer meer over de benodigde technologie.
Continous deployment gaat net een stapje verder dan continuous delivery en staat geen enkele handmatige actie meer toe. Elke goedgekeurde broncodewijziging moet in principe in een automatische uitrol resulteren, inclusief automatisch gegenereerde release notes én een bijgewerkt databaseschema.
Maar ook geen enkele vorm van handmatig testen is toegestaan. Sterker nog, zelfs de servers waarop de software draait moeten automatisch ingericht worden. Heb je een bepaalde Windows-patch nodig? Dan is het uitrollen van die patch onderdeel van het bouwproces (en dat is weer onderdeel van de broncode).
Terugdraaien en foutcorrecties
En wat nu als je nu toch een fout in productie vindt? Het systeem dat zorgt voor het automatisch bijwerken van het databaseschema is ook in staat om dat weer terug te draaien (mits de ontwikkelaar daar natuurlijk rekening mee heeft gehouden). Dus ook het terugdraaien van een uitrol is dan niet meer dan een druk op de knop. Vaak is de bug echter vrij snel op te lossen en is het waarschijnlijker dat er gewoon een extra uitrol overheen gaat.
En als je toch al in staat bent om alles automatisch in productie te zetten, is het wellicht ook interessant om een nieuwe functionaliteit in verschillende verschijningsvormen voor een beperkte groep zichtbaar te maken. En te testen welke variant het beste werkt, ook wel A/B-testing genoemd. Mooi idee toch?
Speelt technologie hier nog een rol? Absoluut!
De invloed van technologie mogen we natuurlijk niet onderschatten. Veel van de hierboven geschetste methodieken waren een paar jaar geleden niet eens mogelijk en zijn enorm afhankelijk van moderne technologie. Zowel de software-architectuur als de tools rondom infrastructuur hebben een enorme vlucht genomen. Daarom is het vak van software-architect al lang niet meer zo simpel. Hieronder een greep uit de technologie en tools waar je in ieder geval niet zonder kunt.
Source Control
Git is niet alleen een versiebeheersysteem, maar verandert de manier van werken op een fundamenteel niveau. Veel zaken, zoals het automatisch nummeren van versies, zijn alleen mogelijk met Git. Er zijn zelfs ad-hoc releasestrategieën ontstaan zoals Gitflow en Githubflow die zonder veel werk direct aansluiten bij continuous delivery en continuous deployment. Git hosting services zoals Github en Bitbucket voegen daar nog concepten aan toe als Pull Requests, die de manier hoe teams samenwerken naar grote hoogten brengt.
Geautomatiseerd testen
Xunit is een unit-test-raamwerk dat het bouwen van geparallelliseerde software stimuleert. Niets is zo confronterend als het omzetten van bestaande unit-testen, die bijvoorbeeld met Microsoft’s eigen MSTest zijn gebouwd, naar Xunit. Dit haalt vaak pijnlijke ontwerpproblemen naar boven die normaal gesproken pas in productie aan het licht komen. Bijvoorbeeld als er veel gebruikers tegelijkertijd met het systeem bezig zijn. Door hier al vanaf het begin rekening mee te houden, is de kans een stuk hoger dat het uiteindelijke systeem goed omgaat met grote hoeveelheden gebruikers.
Hoewel je handmatige tests van het systeem moet minimaliseren, door bijvoorbeeld gebruik te maken van Javascript en Jasmine, heb je altijd een aantal zogenaamde smoke tests nodig. Dit zijn geautomatiseerde testen die het systeem in een testomgeving testen om na te gaan of alles nog goed werkt. In dat geval heeft de online service Browserstack in combinatie met het Selenium browser-testraamwerk de voorkeur. Hiermee kun je websites dynamisch testen in verscheidene browsers en platformen.
Build process
Psake is een op Powershell gebaseerd build process dat onderdeel blijft van je broncode en dus mee-evolueert met de rest van het systeem. De grote kracht van Psake is dat gebruikers het complete deploymentproces kunnen testen zonder afhankelijk te zijn van een specifiek build product.
Powershell DSC is een van de vele tools die het mogelijk maakt om ook de infrastructuur vanuit dezelfde broncode te kunnen configureren. Heeft een nieuwe release een andere versie van het .NET Framework nodig? Voeg dan de juiste instellingen toe aan de DSC-scripts en het build process installeert die automatisch.
Het bouwen van complexe software uit kleine onderhoudbare componenten is inmiddels dé manier om dit met vele teams te doen. Myget is een online service gebaseerd op Nuget, waarmee je de bouw van interne componenten stimuleert die allemaal hun eigen releasekalender hebben. Dit is wat mij betreft de ultieme manier om monolithische software (moeilijk te onderhouden en aan te passen software) te voorkomen.
Technologie
Owin is een open standaard waarmee je componenten ontwikkelt die via http communiceren en die je op allerlei manieren kunt hosten. Bijvoorbeeld in een automatische unit test, zonder directe afhankelijkheid van een web server als Microsoft IIS. Het is ook mogelijk om bijvoorbeeld de resistentie tegen netwerkproblemen en/of serveruitval te testen. Zonder überhaupt iets aan het netwerk aan te passen. Netflix doet dit al jaren met hun Chaos Monkey en Latency Monkey tools.
Zover over continuous deployment. Volgende week volgt het laatste deel van deze reeks, waarin je meer leest over de impact van beide methodieken op de organisatie en je met een handig stappenplan zelf aan de slag kunt.
Zie ook het eerder verschenen artikel Continuous delivery: het pijnloze productieproces.
Als jij wereldwijd je cloud applicaties hebt draaien en je elke twee weken een sprint update naar duizenden systemen wilt verzenden dan heb je dit soort systemen gewoon nodig want anders heb je een veelvoud van mensen nodig die dat allemaal handmatig zouden doen. Feitelijk ben je het automatiseren dan ook aan het automatiseren.
Naar verwachting ging deze artikel deployment inderdaad op dezelfde manier als die van de software.
Niets met de opmerkingen van de eerste aflevering gedaan.
Het gaat immers ook om het uitrolproces, niet om de kwaliteit van het product zelf.
DevOps in de praktijk.
Voorheen hadden we dat met ITIL en aanverwante standaarden. Alles en iedereen ASL en BiSL gecertificeerd dus de ontevreden klanten moesten het wel mis hebben.
Tis nu nog wachten op de derde aflevering van die flauwekul en we zijn er weer even vanaf.
Op naar de volgende trend.
@Dino, ik snap jouw punt niet helemaal. Het artikel een tweeledig doel. 1. om uit te leggen dat CI/CD veel meer is dan een techniek. 2. welke technieken er zijn om dit goed in te kunnen richten. Ik zeg bewust niet zo veel over de product owner omdat die voornamelijk gaat over welke functionele of niet-functionele eisen en in welke volgorde in het systeem moeten landen. CI/CD is typisch iets dat impact heeft op de hele organisatie en veelal gedreven wordt vanuit te techniek. De techniek zelf is geen doel, maar een middel om binnen de organisatie het vertrouwen te kweken om de traditionele manier van werken aan te passen. Wat er naast de techniek allemaal nodig is om een organisatie zo ver te krijgen is moeilijk te zeggen zonder de organisatie en de cultuur te kennen. Daarom zeg ik daar bewust niet zo veel over.
Ik heb beetje een dubbel gevoel bij het verhaal. De onderwerpen die aangehaald worden zijn op zich gewoon goed, maar wat ik jammer vindt is dat het heel erg aan bepaalde tools opgehangen wordt.
Afgelopen jaren heb ik meerdere malen meegemaakt in discussies dat mensen hun manier van werken ophangen aan de (on-)mogelijkheden van de gebruikte tools, zonder na te denken over welk probleem ze nu eigenlijk proberen op te lossen.
Een mooi voorbeeld hiervan is de veel geroemde gitflow. Na bestudering van betreffende flow was mijn conclusie: deze manier van werken hebben we 10 jaar geleden ook bedacht in het bedrijf waar ik toen werkte, maar dan op basis van ClearCase.
Een bouw-deploy-testcyclus hadden we begin 2000 al in place. Het heette alleen geen continuous integratie/deployment omdat bouwen/testen met de destijds beschikbare middelen enkele uren kon duren.
Ik zie dan ook veel “oude wijn in nieuwe zakken”
De manier van werken is niet zozeer veranderd, maar de ondersteunende tools zijn krachtiger geworden, wat overigens absoluut een vooruitgang is; daarover geen twijfel.
Maar om de goede tool keuzes te maken moet je af en toe eens “back to the roots” en bedenken welk probleem je nu eigenlijk probeert op te lossen, in plaats van je blind te staren op wat “de community” roept wat het beste is.
Waarom … niet iedere omgeving is hetzelfde. Een app of webservice ontwikkelen is namelijk soms net iets anders dan een wafer stepper of een diagnostisch röntgensysteem.
Pa Va Ke,
Inderdaad gebruikten we CI/CD al in de jaren, met als grootste verschil dat hierbij gebruik gemaakt werd van de in de jaren 70 bedachte CRUD-matrix zodat de integratiefouten in het logische model gevonden werden voordat het technisch uitgerold werd. En het test bijvoorbeeld of klantgegevens verwijderd (privacy-by-design?) kunnen worden als er nog openstaande orders of facturen van deze klant aanwezig zijn. Wat er uiteindelijk wel en niet mag met gegevens wordt vervolgens vastgelegd in een integriteitsregel die we ook wel een ‘businessrule’ noemen.
Het organisatorische ‘koppelvlakken’ probleem binnen de informatievoorziening gaat om een gebrek aan governance, data is namelijk de parel en een applicatie alleen maar de schelp. En ‘schelpenpad’ van allerlei datagedreven SOA architecturen zouden eens moeten kijken naar de verborgen kosten van integriteit.
@Pavake
Het concept mag weinig zijn veranderd maar zoals je zelf zegt zijn de tools krachtiger geworden. Maar het is ook duidelijk dat de uitgevoerde iteraties veel innovatie met zich mee hebben gebracht. Zoals git een significante verbetering is tov eerdere versie beheer tooling.
Het is meer modulair, schaalbaar en is breder inzetbaar binnen de software ontwikkeling. En uiteindelijk is het een tool die je werk uit handen kan nemen als je er goed mee om gaat.
Iteratief is reeks sprint watervallen.
Wat je bij waterval releases noemde, implementeer je nu in een sprint.
Het wordt proces wordt ook gewoon releasen genoemd. Kleine releases. Lekker rollen.
Regelmatig werk ik in zo’n team. De helft van de releases bestaat uit patches waarbij uit alle macht geprobeerd ze aan de organisatie te verkopen als feature.
We kunnen prima zonder git, zoals we ook kunnen klussen zonder de gamma.
Maar als je maar elke dag roept dat die gamma nodig is dan nemen we die gedachte wel over.
Innovatief, iteratief, wendbaar waarde toevoegen aan de business.. Wel eens een kosten/baten analyse gezien, daarvan ? Dat we zaken nu anders oplossen dan voorheen ?
Vrijwel alles dat je met git doet kan ook met bijv subversion.
Het gaat er toch echt vooral om wat je erin stopt.
Dennis begrijpt prima wat ik bedoel. Size does not matter, it’s what you do with IT. Shit in, shit out, een aloude wet nog uit het numoquest tijdperk.
CD/CI als oplossing voor alles. Gaat allemaal vanzelf goed. Net zoals de marktwerking bij aanbestedingen. Ze kunnen nog zo wendbaar werken, maar de kosten zullen uiteindelijk verdrievoudigd zijn.
“Manieren hoe teams samenwerken naar grote hoogten brengen.”
Loftrompet gespeeld door man met missie. Nieuwe hoempapa klinkt inderdaad zoveel beter als het enthousiast gebracht wordt. En Tis niks en twordt niks, schiet ook niet op. Laat je daarom niet tegenhouden.
Dennis was deployer in het leger van de techniek.
Hij itereerde van Den Helder tot Den Briel.
Hij had geen geld
en hij was geen held
en hij hield niet van het businessgeweld
maar trompetter was hij wel in hart en ziel.