Insights & Data Blog

Insights & Data Blog

Meningen op deze blog weerspiegelen de opvattingen van de schrijver en niet per definitie die van de Capgemini Group

Alternate title: 

De vele gezichten van DevOps

DevOps is het vervolg op Agile software ontwikkeling. Het is de samenvoeging van begrippen ‘Development’ en ‘Operations’.

DevOps is gericht op de hele keten van softwareontwikkeling tot en met het in gebruik nemen ervan in de productieomgeving. Devops beoogt een snellere oplevering van software en een vermindering van fouten in het hele proces en het eindproduct. Het moet sneller kunnen en beter.

Meer in detail richt DevOps zich op nieuwe of aangepaste code, op de vrij te geven build en op het release pakket. Geen code zonder platform, dus moet DevOps zich ook richten op de infrastructuur en op de configuratie ervan. En tooling niet te vergeten! Automatiseerders vergemakkelijken of automatiseren zelfs hun eigen werk met tools.

Ook richt DevOps zich op een aantal processen: ontwerpen, bouwen, testen, vrijgeven, integreren en installeren. Om het geheel in goede banen te leiden, zijn vooral de volgende activiteiten nodig: communiceren en plannen.

En mocht er toch iets fout gaan, dan is versiebeheer onmisbaar.

In onderstaande afbeelding zijn deze primaire software delivery processen of functies weergegeven. De pijlen geven een richting aan, maar het betekent zeker niet dat deze volgorde netjes kan worden aangehouden. Wel wordt hierbij het onderscheid gemaakt tussen activiteiten gericht op de code, op het maken van de build en activiteiten gericht op het daadwerkelijk releasen in een andere omgeving.

 Wat het extra complex maakt, is dat de verschillende activiteiten plaatsvinden op verschillende omgevingen. Daarbij is het schrijven van de code dus slechts een van de vele stappen, iets dat in mijn beleving vaak niet wordt gezien.

Maar nu de praktijk: Ik ben werkzaam bij een klant waar sinds 8 weken de ontwikkelmethode Scrum wordt gebruikt. Het is een klein team, heeft gezamenlijk een scrumtraining gevolgd en is serieus van plan Scrum zinvol toe te passen. Dat levert veel interessante discussies op. Tijdens een discussie over de ‘definition of done’ werd er besloten dat een item pas kan worden gereleased als het klaar is. Scrum zegt namelijk niks over het releasen van ontwikkelde software. En aangezien het releasen grotendeels door het ontwikkelteam zelf wordt uitgevoerd, is er besloten dat er met enige regelmaat een release sprint moet komen.

Het aanmaken van de ETL processen voor het bijwerken van het datawarehouse was al geautomatiseerd. Dat kon namelijk door gestandaardiseerde laadprocessen te gebruiken door de logica in database views te plaatsen. Het strikt volgen van principes uit de modelleringstechniek DataVault bleek goed te ondersteunen.

Het team had tot nu toe de ervaring dat er hooguit eens in de 3 maanden werd gereleased. Sneller lukte niet, want het samenstellen van het releasepakket en het testen van alle items ruim kostte al gauw een paar weken tijd. En daarnaast bleek er na het vele testwerk ook veel rework nodig te zijn.

Dus releasen na enkele korte sprints zou weliswaar minder tijd moeten kosten, maar zou evengoed nog verder verkort moeten kunnen worden. Vandaar dat er wordt gekeken naar methoden om het testen en het releasen te automatiseren.

Het kleine team is inmiddels zo ver dat ook het integreren van items en het maken van de build geautomatiseerd kan worden omdat de versiebeheertool dit blijkt te ondersteunen! Het samenstellen van de release en de release notes is daardoor ook eenvoudiger geworden.

Het distribueren en installeren van de release items kan nog verder geautomatiseerd worden, maar gaat inmiddels voldoende snel. Een belangrijke uitdaging was voorheen de communicatie tussen het ontwikkelteam en het beheerteam. Maar nu hetinstallerenvan de release grotendeels geautomatiseerd plaatsvindt, ontstaan er ook minder misverstanden en misinterpretaties van de meegeleverde installatieinstructies.

 Kortom: DevOps is mogelijk, maar heeft vele gezichten. Het raakt veel verschillende processen die tevens moeten zijn ingericht op wijzigingen.

Gelukkig is het team klein en is de bereidheid om te kijken naar een andere methoden en technieken groot. En dat maakt het voor mij een leerzame werkomgeving!

Over de auteur

Frank Fledderus
Frank Fledderus
Sinds 1997 ben ik werkzaam geweest bij diverse klanten in verschillende sectoren. Daardoor heb ik veel ervaring opgedaan met architectuur, informatie analyse en business intelligence. En mijn nieuwsgierigheid zorgt ervoor dat dat nooit verveelt!

Plaats een reactie

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.