Verslag Continuous Delivery Conference 2016

In het Spant! te Bussum vond op 1 december 2016 de Continuous Delivery Conference plaats. Na een korte introductie door Charlotte Verschoor, Project Manager van de organiserende organisatie CKC Seminars, en na een elevator pitch van alle sprekers opende dagvoorzitter Frank Simon de conferentie door de eerste keynote spreker aan te kondigen.

2

De eerste keynote werd gegeven door Lothar Schulz, Continuous Delivery Team Lead bij Zalando. Zijn presentatie had de titel “How Zalando Scaled Continuous Delivery: from Data Centers to the Cloud”. In de zomer van 2014 begon het continuous delivery ontwikkelteam van Zalando te brainstormen over hoe ze de infrastructuur op een gedistribueerde manier konden aanpakken. De kennis was welzeker aanwezig, maar meer in de vorm van een slapende leeuw, aldus Lothar. De oorzaak van de denksessies was dat er binnen Zalando geluiden te horen waren dat een uniforme continuous integratie oplossing niet meer werkte voor alle teams. De servers konden de load niet aan van de vele builds waardoor de feedback soms pas na uren kwam in plaats van in minuten. Ook speelde het feit mee dat elk team alsmaar veranderende doelen had en verschillende business behoeftes bedienden. De teams paste daarom de oorspronkelijke drie continuous integration servers aan naar een continuous delivery landschap in de cloud van meerdere continuous integration servers die door automatische schaling aansloten bij de specifieke behoeftes van de verschillende teams. Ze gebruikten hiervoor de al aanwezige kennis binnen de teams en maakten diverse alternatieve plannen voordat ze kozen voor de gedistribueerde oplossing. De oplossing bestaat onder andere uit twee API’s, genaamd CloudLobster en CloudKraken, die Zalando gebruikt voor het creëren en managen van continuous integration instanties en agents. Uiteraard kwamen de teams de nodige problemen tegen op de weg er naar toe, maar één voor één werden die uit de weg geruimd met behulp van een support team. Het resultaat was een gedistribueerde en schaalbare aanpak voor continuous integration die precies op zijn plaats is voor een bedrijf met meer dan 18 miljoen klanten en 1300 ontwikkelteam leden. Waarin teams zelf beslissingen mogen nemen, zoals bijvoorbeeld over welke (test)technieken ze gebruiken.. Hij sloot af met de hoop dat alle toehoorders ook binnen hun bedrijven deze transformatie met succes konden starten en doorvoeren. Dat bij iedereen net als bij Zalando de leeuw wakker mag worden.

3

De eerste parallelle sessie die werd bijgewoond werd gegeven door vier personen van Conclusion die bij de Nederlandse Spoorwegen een continuous delivery implementatie begeleiden bij NS reizigers. De tracksessie had de titel “NS Travelers , Continuous Delivery in a Large chained Enterprise Environment (using Puppet, Jenkins, Rspec)” gepresenteerd door Robbrecht van Amerongen, Bert Hajee, Dylan Krul en Rouke De Jong. Bij de spoorwegen werd continuous delivery ingevoerd terwijl de spreekwoordelijke softwarewinkel gewoon open bleef. Volgens de sprekers wordt continuous delivery binnen grote organisaties vaak slechts lokaal en deels gebruikt. Het naar productie brengen van de producten voelt vaak als een kudde olifanten die in een rij achter elkaar loopt. Je krijgt te maken met complexe pakketten zoals IBM, Oracle en veranderingen die enorme impact hebben op meerdere afdelingen en processen. Ze lieten zien hoe je afhankelijk van de situatie een op maat ingeregelde delivery pipeline kunt invoeren in combinatie met het doorvoeren van aanpassingen in de code en het op aanvraag snel uitrollen van omgevingen binnen verschillende producten en applicatie ketens. Ze kregen dit bij de NS voor elkaar door gebruik te maken van een combinatie van tools zoals Jenkins, Selenium, RSPEC, Puppet, WebLogic, Oracle, RedHat en Linux. Door een blueprint te vergelijken met de daadwerkelijke situatie werd meteen duidelijk welke infrastructurele aanpassingen er nog nodig waren om een omgeving uit te rollen. Via de pipeline werden de applicaties automatisch gebuild, gedeployed en getest naar de uitgerolde omgevingen gebracht. Hierdoor ontstond een compleet geautomatiseerde release pipeline. De invoeren werd uitgevoerd in samenwerking met de architecten, DevOps ontwikkelaars en verandermanagers. Het mooie van de oplossing is dat het zo is ingericht dat het klantonafhankelijk is. Door de generieke onderdelen er uit te lichten kan hetzelfde snel worden geïmplementeerd bij andere bedrijven.

4

De tweede parallelle sessie was van Wouter Lagerweij, oprichter van make.io, met “Testing in a Continuous Delivery World”. Wouter vroeg de zaal of we ons nog konden herinneren dat iedereen zich afvroeg wat de rol van de tester zou worden binnen een agile team. Nou, dat gebeurt nu weer, want de zaken gaan alweer veranderen. Met Continuous Delivery gaan teams weer een hele nieuwe uitdaging aan. Ook op het gebied van testen. Ze zullen nieuwe manieren van testen moeten bedenken. Testers en ontwikkelaars zullen in een nieuwe dynamiek met elkaar moeten leren werken. Er zullen nieuwe wegen worden gevonden bij de interactie met de klanten, stakeholders en product owners. Want de invoering van continuous delivery zorgt er voor dat er gevraagd wordt om zaken zoals bijvoorbeeld test driven development. Bedrijven beginnen meer en meer in te zien dat als je meerdere keren per dag naar productie wilt met je applicaties dat je dan op een andere manier moet gaan testen. Specification by Example, snellere feedback loops en geautomatiseerde testen die continue de kwaliteit van de software checken, aangevuld met exploratory testing, zorgen er voor dat de kwaliteit centraal komt te staan. We werken zo continu samen aan de kwaliteit. De rol van de tester verandert, net zoals die van de ontwikkelaar verandert. De klant staat centraal. De teams werken continue samen met de klant om zo precies te bouwen wat de klant wil. En juist hierin kan de tester een grote rol spelen. Die weet namelijk met zijn test competenties als geen ander om de connectie te leggen tussen de klant en het ontwikkelteam. Testers moeten mee veranderen met hun omgeving om niet net zo te eindigen als de Dodo, aldus Wouter.

5

Na de pauze was het tijd voor de tweede keynote. “Testing is everyone’s responsibility” door Pavel Chunyayev, Continuous Delivery Architect bij Levi9 IT Services. Het verkrijgen van kwaliteit is volgens Pavel waarschijnlijk één van de meest uitdagende aspecten van Continuous Delivery. In sommige bedrijven leeft bij ontwikkelaars en managers nog steeds het beeld, ondanks alle veranderingen, dat de kwaliteit iemands anders verantwoordelijkheid is. Ze gaan er onterecht van uit dat het uitvoeren van testcases en het houden van een stabilisatie sprint genoeg zijn om kwaliteit te leveren. En zelfs teams die wel begrijpen dat de kwaliteit een zaak is van het hele team ziet Pavel worstelen met het inregelen van herhaalbare processen rondom kwaliteit. Hij pleit er daarom ook voor om gebruik te maken van continue herbruikbare automatische testen, standaard processen voor het releasen van software en het gebruiken van zo snel mogelijke feedbackloops. Kwaliteit moet bij iedereen de grootste aandacht hebben en het hele team, de klant en de product owner moeten samen gemotiveerd zijn om constant de meest waardevolle en kwalitatief hoge producten op te leveren. Geef het product zo snel mogelijk aan de klant. Niet alleen tijdens de bouw, maar ook tijdens het voorbereiden en het specificeren van de werkzaamheden. Door constant feedback te krijgen over de kwaliteit kan er op elk gewenst moment inzichtelijk worden gemaakt hoe het staat met die kwaliteit en kan er dus ook elk gewenst moment met software naar de productie worden gegaan. Alles testen is daarbij niet nodig zegt Pavel. Geen bugs vinden zegt niet dat ze er niet zijn. Wel bugs vinden zegt niet dat dat de enige bugs zijn. Veel belangrijker is dat we de belangrijkste bugs vinden. Pavel sloot af met te zeggen dat testen teamwork is. Niet alleen de testers testen. Iedereen test op allerlei niveaus om zo snel mogelijke feedback te verkrijgen. En als je het niet kunt testen dan kun je het ook niet bouwen. Andersom kun je het niet testen als je het niet kunt bouwen.

6

Vervolgens waren René van Osnabrugge en Marcel de Vries, respectievelijk Lead ALM Consultant en CTO bij Xpirit Netherlands, aan de beurt met hun tracksessie over “Continuous Delivery 3.0 – The next step”. Veel bedrijven zijn op dit moment bezig met het invoeren van CD. Volgens René en Marcel richt hun aanpak zich vaak op het automatiseren van de handmatige testen en processen, maar door dat te doen missen ze de kans om gaande de veranderingen meteen zaken te verbeteren. In plaats van het bestaande om te zetten is het een veel beter idee om bij de invoering van CD meteen de traditionele manier van denken los te laten en ruimte te maken voor nieuwe concepten en technologieën die kunnen zorgen voor een enorm potentieel. De wereld verandert sneller dan we bij kunnen houden. De grootste bedrijven ter wereld zijn IT bedrijven. Bedrijven zien zichzelf vaak niet als IT bedrijf, terwijl al hun belangrijke processen en producten via IT de klant bereiken. Als je als bedrijf snel aan de vraag van de klant wilt voldoen is het noodzakelijk dat je je ontwikkelproces anders gaat aanpakken, aldus René en Marcel. Het probleem van continuous delivery is volgens hun dat teams daarmee wel snel kunnen produceren, maar het naar productie brengen kan niet snel genoeg plaatsvinden. Om dit op te lossen moet je volgens de heren buiten de lijntjes denken. Oude obstakels zijn wellicht ondertussen al weg en maken de weg vrij voor oplossingen die tot nu toe nog niet mogelijk waren binnen je bedrijf. Denk hierbij bijvoorbeeld aan het gebruik van feature flags, het opknippen van applicaties, het uitrollen van canary releases, het lanceren van dark launches, het doorvoeren van architectuur wijzigingen of het gebruik van containers. Optimaliseer niet wat je nu weet, maar denk na over de volgende “volgende stap”.

7

De laatste tracksessie was “Feature Branching is evil to Continuous Delivery” door Thierry de Pauw, Agile Technical Coach bij ThinkingLabs. Thierry vroeg zich tijdens zijn presentatie af waarom de community zich toch zo onterecht richt op het omarmen van feature branching. Bij feature branching wordt de code pas gemerged in de main line als de code done is. Maar dat is dan niet “done done” volgens Thierry. Daarna moet nog worden aangetoond dat het werkt in combinatie met de code in de main line. Feature branching wordt door eigen zeggen door bedrijven toegepast om het werk van de ontwikkelaars te isoleren en zo meer productief te kunnen zijn. Maar dat is helemaal niet zo zegt Thierry. Want daarmee laten ze de vroege feedback loops los die worden gebruikt binnen continuous delivery en creëren ze op die manier een hoop extra overhead. Je bent volgens hem zo traag als je langzaamste merge. Je krijgt verder alleen waardevolle feedback in de main line, aldus Thierry. Hoe langer de feature branch bestaat, hoe groter de change set en het risico op fouten bij het terug mergen. Maar wat dan? Hij zet liever in op trunk based development waarbij iedereen zijn code op zijn minst één keer per dag merged naar de master trunk. Hierdoor moeten de ontwikkelaars elke dag werkende software op kunnen leveren. In plaats van een grote change worden er nu meerdere kleinere changes doorgevoerd. Door elke dag de code terug te brengen in de master krijg je veel sneller feedback. Hiervoor is een ontkoppelde code base nodig en veel automatische testen. En is een deel niet af aan het eind van de dag dan verstop je het gewoon door middel van feature flags of een dark luanch.

8

De dag werd afgesloten met de laatste keynote gegeven door Anders Wallgren, CTO bij Electric Cloud. Zijn verhaal ging over “The Value of Application Delivery, Continuous Delivery and DevOps in software delivery”. Waar DevOps eerst werd gezien als een door economische en management belangen doorgevoerde verandering, is DevOps ondertussen compleet ingeburgerd in de meest grote bedrijven ter wereld. DevOps is van levensbelang voor grote bedrijven om sneller betere software op te leveren van hoge kwaliteit. Continuous integration, continuous delivery en continuous deployment zijn nu de norm voor zowel kleine als grote ontwikkelteams. De veranderingen volgen elkaar steeds sneller op. Van decennia, naar jaren, maar minuten. De grootste bedrijven ter wereld zijn software bedrijven en software wordt in de toekomst alleen maar belangrijker. Het draait om de kwaliteit en de veiligheid van de software. Het nieuws halen vanwege een bug of lek kan een bedrijf maken of breken en kan miljarden kosten. Bedrijven kunnen volgens Anders alleen overleven als ze continu de software kunnen leveren die voldoet aan de wensen van de klant en die ook nog eens van hoge kwaliteit en veilig is. Continuous delivery helpt daarbij. Maar het invoeren is niet genoeg. Team en klant moeten bij elkaar zitten en constant samen werken aan kwaliteit. De mindset moet veranderen. Je bent niet agile als je stand-ups houdt. Je bent pas agile als je een waardevol product levert aan de klant.

Na de afsluitende woorden van de dagvoorzitter was het vervolgens tijd voor de borrel en het nodige netwerken op de infomarkt als afronding van de door CKC Seminars georganiseerde 2016 editie van de Continuous Delivery Conference. Op naar volgend jaar voor weer een nieuw en leerzaam evenement, waarbij in de tussentijd de opgedane kennis door de bezoekers tijdens de dagelijkse werkzaamheden in de praktijk gebracht kan worden.