Continuous delivery en/of continuous deployment vereisen beide dat je organisatie snel kan schakelen en mee kan groeien met nieuwe wensen en eisen. En dat werkt natuurlijk niet als je nog volgens een watervalmethodiek werkt. Het zal niet als een verrassing komen dat continuous werken hand in hand gaat met Agile methodieken als Scrum en Kanban.
Veel van de onderliggende engineeringprincipes komen uit Extreme Programming (één van de eerste Agile methodieken). Het iteratieve karakter van Scrum past perfect bij continuous delivery, terwijl het continue proces van Kanban juist weer beter aansluit bij continuous deployment.
Groeiproces
Ook qua groeiproces klopt dit als een bus. Veel organisaties die voor het eerst in aanraking komen met Agile-softwareontwikkeling beginnen met Scrum. Hoewel ze bijna altijd onderschatten hoeveel impact Scrum heeft op de organisatie, introduceert dat wel de juiste mentaliteit voor continuous delivery.
Daarnaast zie je dat teams die volwassen genoeg zijn, uiteindelijk overgaan op Kanban. Kanban is een wat vrijer proces, zonder een vooraf gedefinieerde planning. Hierbij ligt de nadruk op het beperken van de hoeveelheid werk die tegelijkertijd wordt opgepakt. Er kan nog wel een project aan ten grondslag liggen, maar in de praktijk is elk brokje werk dat het team oppakt een afgebakend geheel. Een prima combinatie met continuous delivery dus. Helemaal als ze dat brokje werk volledig geautomatiseerd in productie kunnen zetten.
En nu? Aan de slag in zeven stappen!
Is je interesse gewekt voor continuous development en deployment, maar staat je organisatie hier nog erg ver vandaan? Dan is het slim om stap voor stap te starten. Wat mij betreft is dit de beste aanpak:
- Stap over op Git. Zonder Git is de rest wel te doen, maar een stuk moeilijker. Probeer maar eens met Team Foundation Server verschillende branches te monitoren, zonder elke keer de Team Build-instellingen aan te moeten passen.
- Start met automatiseren van het build process. Heb je dit voor elkaar, dan is het een stuk makkelijker om andere onderdelen gecontroleerd te automatiseren.
- Zorg dat het build process flexibel genoeg is om alle configuratie- en infrastructuurinstellingen te ondersteunen die de beheerafdeling normaliter handmatig uitvoert. Zo hoef je straks geen handmatige stappen meer uit te voeren, buiten het op de juiste plek zetten van de dll's of executables.
- Vervang eventuele database scripts met een library die schema’s vanuit code kan bijwerken naar de laatste versie. Fluent Migrator en Entity Framework kennen beide zulke functies.
- Begin met het herstructuren van de broncode (ook wel refactoring genoemd) en zorg dat je meer en meer aspecten automatisch test vanuit het build process. Overweeg ook om onderdelen van het systeem los te trekken, zodat je die apart kunt beheren en ontwikkelen.
- Kies een releasestrategie en volg die ook, eventueel in combinatie met automatische versionering met behulp van Gitversion.
- Begin met het schrijven van tijdelijke karaktertesten die als vangnet dienen voor de veranderingen die nodig zijn om continuous delivery of deployment mogelijk te maken.
Bestaande patronen doorbreken
Het mooie van alle in dit artikel genoemde werkwijzen, is dat ze ieder al een heel specifiek probleem oplossen. Continuous delivery kan een doel op zich zijn, maar het is de weg ernaartoe die het grote verschil maakt. In tegenstelling tot veel alles-of-niets principes zoals bijvoorbeeld Scrum, zijn het de individuele stappen die je softwareontwikkeling naar een hoger plan brengen.
En hoewel er behoorlijk wat technische uitdaging zit in het introduceren van deze nieuwe kijk op softwareontwikkeling, is dat niet de grootste uitdaging van het geheel. Wat veel lastiger zal zijn, is het doorbreken van de bestaande patronen. Zeker als verantwoordelijkheden nog verdeeld zijn over verschillende - mogelijk zelfs fysiek gescheiden - afdelingen. Maar als je dat punt eenmaal voorbij bent, vraag je je waarschijnlijk af hoe je ooit überhaupt zonder kon werken.
Reacties
Na het lezen van stap 1 krijg ik toch een klokken-klepel-verhaal gevoel.
GIT is een versiebeheers systeem, niets meer, niets minder. Het monitoren van meerdere branches gebeurt vanuit een bouwomgeving (bijv. Bamboo of Jenkins). Dit zijn wezenlijk andere tools.
Ergo, je kunt Team Foundation Server gebruiken met een GIT repository onder de motorkap. Daarmee los je het (vermeende) probleem wat genoemd wordt niet op.
Overigens kun je ook met TFS meerdere parallele streams monitoren. Maar ook met tools als Rational Team Concert en zelfs met SubVersioN kun je dit doen. En als je een beetje goed bent in scripting, draai je je hand er niet voor om dit met good old ClearCase te realiseren.
Ik zal eens kijken of ik daar wat leuks over kan schrijven
Beste Pa Va Ke,
Dan heb je waarschijnlijk zelf nog niets met Git gedaan. Git is weliswaar 'maar' een versiebeheersysteem, maar het feit dat het gedecentraliseerd werkt, branching en merging volledig pijnloos werkt (in tegenstelling tot TFS's eigen versiebeheersystem), en dat er een enorme set van tools ontstaan zijn die heel veel van de 'oude' problemen oplossen kan ik zelf onderschrijven. TFS heeft tegenwoordig wel ondersteuning voor Git, maar mist de cruciale functionaliteit die nodig is om een organisatie verder te schalen. Maar goed, dit ga je pas zien als je er zelf mee aan de slag gaat.
Het doel van deze drie artikelen was om te laten zien wat je zelf kunt doen om de eerste stappen naar CI/CD te nemen. Het beschrijft vele ingredienten die op zichzelf al heel nuttig zijn, maar die als geheel de complete manier van werken kunnen veranderen.
Ik heb met verschillende source code versioning systemen gewerkt, GIT vind ik de lastigst om mee te werken, maar ook de krachtigste.
Ben benieuwd naar je artikel PaVaKe, maar deze vond ik ook wel te verteren. Hopelijk komen er ook nog specifieke artikelen naar aanleiding van de details waarover je schrijft Dennis.
Beste Dennis
Verkeerde aanname, ik werk momenteel dagelijks met GIT. Helaas nog niet de tijd gehad om alle ins en outs te verkennen. Wel heb ik wat meer vergelijkingsmateriaal dan alleen TFS (ClearCase, RTC en SVN). Dito voor bouwomgevingen (Jenkins, TFS, RTC, Electric Commander, BuildForge)
Mijn doel is overigens niet om GIT (of wel ander tool dan ook) af te kraken, maar om duidelijk te maken dat je enerzijds naast GIT wat meer nodig hebt (bijv. de atlassian suite), en dat er anderzijds ook andere tools zijn waarmee je CI/CD kunt doen.
@Henri Koppen, zie http://www.continuousimprover.com. Over bijna elk aspect heb ik al apart geblogged.
@Pa Va Ke, zie ook specifiek deze post http://www.continuousimprover.com/2016/02/how-git-can-help-you-prevent-monolith.html. Ik heb met eigen ogen gezien dat Git je hele manier van ontwikkelen op de schop gaat gooien. Dat het alleen maar een versiebeheersysteem is naar mijn mening een van de grootste misvattingen. Ik heb zelf jaren met ClearCase en TFS gewerkt (en daarvoor met SVN).
@Dennis: bepaalt het CM omgeving de architectuur en de manier van werken, of bepalen de architectuur en manier van werken de inrichting van je CM omgeving?
De laatste jaren zie ik een trend die naar het eerste neigt, maar volgens mij zou het tweede leidend moeten zijn.
@PA VA KE, CM?
@Dennis: CM, configuration management (sorry, beroepsdeformatie).
@PaVaKe
Denk niet dat Dennis de doelgroep heeft van de ontwikkel clubs die wel voorop lopen met deze nieuwe ontwikkelingen. Alhoewel is voor IMHO elk zichzelf respecterende ontwikkelaar CI/CD al gesneden koek en het hoor een vanzelfsprekendheid.
Denk dat hij eerder de organisaties aanschrijft die nog met waterfall, oudere VCS of nog erger houtje touwtje oplossingen werken. En die zullen zich echt nog eens een keer goed achter de oren moeten krabben of ze toch maar eens niet mee moeten gaan met de innovaties en zorgen dat ze weer competitief worden want de bottomline is dat je met CI/CD (mits goed toegepast uiteraard) je meer effectief kan werken.
Beste Johan & Dennis Doomen,
Onze 'jongens en meisjes' die er op uitgestuurd worden naar de NCOI - HBO Informatica opleiding (ja, van 20 tot 60 jaar, ze gaan allemaal, wij betalen - 2 dagen (1 lesdag - 1 studiedag per week worden doorbetaald natuurlijk).
Als ik roep delivery & deployment krijg ik vraagtekens terug... (?)
Wat te doen, Engelse les?
Ik ga ermee door hoor, maar 't kost toch totaal snel 4.000 euro per werknemer. Da's veel geld als je er veel hebt en niemand weet waar het overgaat.
delivery & deployment. Tja...