Hoe gaaf is het als je je software volledig pijnloos in productie brengt zonder kans op installatiefouten door handmatige acties? En zou het niet nuttig zijn als je een nieuwe functie gedurende een korte periode kunt testen bij een kleine doelgroep, om die functie op elk gewenst moment weer uit te schakelen?
Kun je je voorstellen dat dit met een enkele druk op de knop kan? En dat beheerders samen met de ontwikkelaars optrekken om dit voor elkaar te krijgen? Het zal niet makkelijk zijn, maar het is echt mogelijk. Kijk maar naar bedrijven als Facebook, Twitter en Github. Die doen dit al jaren. Sterker nog, het nastreven van zo’n manier van werken kan een complete cultuurverandering met zich meebrengen, die traditionele organisatorische silo’s doorbreekt.
Continuous wat?
Deze manier van ontwikkelen heet continuous delivery. Wat is dat nou eigenlijk? Er zijn eigenlijk twee termen in de omloop; continuous delivery en continuous deployment. Volgens mijn definitie is continuous delivery een verzamelterm voor een aantal methodieken, principes en tools die het mogelijk maken om een stuk software of een systeem met één druk op de knop op te kunnen leveren. Zonder dat daar handmatige acties bij komen kijken.
Normaal gesproken heb je bij een oplevering te maken met zaken als (handmatig) testen, versienummers bepalen, de juiste bestanden verzamelen, instellingen aanpassen en deze op te leveren als een zip-bestand. Als het systeem een database nodig heeft, dan is het vaak ook nog zaak om de update van (een kopie van) de productiedatabase te testen.
Continuous deployment: een stapje verder
Als je dit allemaal goed voor elkaar hebt, dan zou het voor de beheerders voldoende moeten zijn om het ingepakte bestand uit te pakken, de infrastructuurafhankelijke instellingen op de juiste plek te zetten en de database scripts te draaien. Hoewel die laatste zaken nog te overzien zijn, zijn dit eveneens handmatige en dus foutgevoelige stappen. Continuous deployment gaat nog een stap verder en heeft als doel om het volledige proces van codewijziging tot het in productie brengen van de software te automatiseren. En mocht er toch een probleem zijn met de wijziging, dan kan ook het terugdraaien van de productieomgeving naar een vorige versie volledig geautomatiseerd verlopen.
Waarom zou je dit doen?
Continuous werken doe je om je software zo snel en zo pijnloos mogelijk in productie te krijgen, zónder de kwaliteit in gevaar te brengen. En dat lukt organisaties nu vaak nog niet. Wellicht omdat er nog een organisatorische scheiding bestaat tussen de afdeling die de software ontwikkelt en de afdeling die verantwoordelijk is voor het in productie brengen en beheren van die omgeving. Daar ontbreekt het nog wel eens aan vertrouwen in elkaars kunnen.
Continuous delivery kan dat patroon doorbreken door de mensen uit de afdelingen een stimulans te geven om samen te werken aan een gezamenlijk doel. Zo kunnen testers hun kennis en ervaring gebruiken om het systeem meer geautomatiseerd testbaar te maken in plaats van saai en repetitief handmatige testwerk uit te voeren. En het uitrolproces kan een stuk gestroomlijnder als je softwareontwikkelaars zich ermee gaan bemoeien. Immers, ontwikkelaars hebben over het algemeen een hekel aan dingen twee keer doen.
Technieken
Zoals ik al eerder aangaf, is continuous delivery de eerste stap naar continuous deployment. Een zelfde soort onderscheid kun je maken in de methodieken en technieken die nodig zijn. Om met continuous delivery te beginnen bijvoorbeeld, zul je een veelvoud aan werkwijzen moeten introduceren.
Testen? Dat moet automatisch!
Zoveel mogelijk van de productiecode moet je dekken door geautomatiseerde tests, ook wel unit tests genoemd. Het is daarbij belangrijk om de juiste scope (unit) van testen te kiezen. Test Driven Development, een ontwerp- en ontwikkeltechniek die het bouwen van testbare software enorm stimuleert, kan je daarbij helpen. Het is geen vereiste, maar uit eigen ervaring weet ik dat het achteraf toevoegen van geautomatiseerde tests heel moeilijk is.
Als het systeem bestaat uit meerdere onderdelen die normaal gesproken alleen na de uitrol samen getest kunnen worden, dan zijn acceptatietesten geen overbodige luxe. Deze zogenaamde end-to-end tests raken één van die onderdelen en gebruiken dummies om de overige componenten te simuleren.
Handmatig testen zou je sowieso moeten verbannen. Uiteraard is dat in de praktijk niet altijd mogelijk, maar breng dan in ieder geval in kaart waarom dat niet kan. En wat er voor nodig is om het toch te verwezenlijken.
Versienummers? Niet meer over nadenken!
Een releasestrategie en bijbehorende branchingstrategie zijn cruciaal. Zo’n strategie geeft aan hoe het team om moet gaan met tussentijdse releases, definitieve releases, hot-fixes en het reguliere ontwikkelwerk. Ook zegt het iets over labeling en schema’s voor versienummers.
Modules moet je daarnaast automatisch versioneren. Een ontwikkelaar zou geen handmatige acties meer hoeven uitvoeren om het versienummer op te hogen. Als je Git gebruikt als versiecontrolesysteem zijn er handige tools die, op basis van de branchingstrategie en naamgevingsconventies, automatisch een versienummer genereren.
Uitrollen zonder risico’s
Bij de uitrol moet een beheerder vaak nog handmatige aanpassingen doen aan de instellingen die afhankelijk zijn van de infrastructuur. Denk aan databaseconnectie-informatie, gebruikersnamen en wachtwoorden. Ook dit kun je verbeteren door softwarepakketten te gebruiken die de uitrol van dit soort gegevens en/of instellingen automatiseren.
Het proces waarmee de broncode wordt omgezet naar de definitieve versie van de software is vaak ingericht met een standaardpakket. Maar wat veel ontwikkelaars vergeten, is dat dit proces veelal net zo veranderlijk is als de broncode zelf. Door dit proces onderdeel te maken van de broncode kan het meegroeien met veranderende wensen en eisen. Bijkomend voordeel is dat ontwikkelaars het hele uitrolproces op hun eigen ontwikkel-pc’s kunnen testen. En dat draagt weer bij aan korte feedbackcycli.
Niets is meer vertragend dan een databasespecialist die elke aanpassing aan het databaseschema moet goedkeuren en uitrollen. Ook dit kun je volledig geautomatiseerd uitvoeren. Er zijn softwarebibliotheken zoals Fluent Migrator die eigen metadata toevoegen aan het databaseschema en daarmee exact bepalen wat de verschillen zijn tussen het huidige schema en dat van de nieuwe softwareversie.
Zover over Continuous delivery. Volgende week deel twee van deze reeks, waarin je meer leest over Continuous deployment.
Leuk artikel Dennis.
Wij doen ook aan “continuous delivery” en dat is grotendeels geautomatiseerd (salt, jenkins). Team ontwikkelt en maakt tests. Andere testen en accepteren en dan word het uitgerold naar de productie omgevingen.
Heerlijk om zo snel request changes naar productie te brengen.
Helaas komt er nog veel meer kijken bij “continuous delivery” en daar word nogal eens overheen gekeken. Technisch werkt dit allemaal als een zonnetje, maar hoe zit het met release notes? Gebruikers instructies? Documentatie? Beheer?
Dit zijn uitdagingen die ons nogal eens bezig houden. Gebruikers die ineens geconfronteerd worden met een wijziging, nieuwe dingen zien die ze niet begrijpen (en dan bijna automatisch zich ertegen verzetten) , of beheerders die ineens er weer iets bij krijgen of geconfronteerd worden met vragen….
Dat je versienummering helemaal kan vergeten, dat geloof ik niet. Je moet een fix of versie van je software kunnen identificeren en weet welke functionaliteit daarbij hoort. Als je helemaal vertrouwt op de automatische versienummering vanuit de software dan weet je helemaal niet meer waar je aan toe bent en welke versie waarbij hoort. Het is niet nieuw dit, het automatiseren van handmatige processen bij ontwikkeling, test en beheer.
Continuous delivery maakt het het leven gemakkelijker en bepaalde onderdelen betrouwbaarder maar iedere wijziging is een risico.
@Henri Inderdaad om nu je gebruikers te confronteren met nieuwe functionaliteit en ook beheerders zonder dat ze weten wat er gebeurd is, is ook geen pretje. Release notes, dat suggereert versies. Zit nu wat in de nodejs en het leuke daarvan vind ik dat er hooks in ziten om dit, geautomatiseerd testen, integreren en release, in te bouwen.
Het is geen wonder dat nu de term bimodal daar is. Voor ieder probleem een nieuwe hippe term. Misschien is de wens aan betrouwbare en werkende software belangrijker dan software die bij wijze van spreke iedere dag nieuwe features bevat. Naast de verwarring die het kan brengen ook een grote risico op problemen. Je mag hopen dat de software in de auto of vliegtuig niet op die manier onderhouden wordt. Of ieder ander kritische stuk software.
Ik geloof dat CD/CI handig kan zijn in het ontwikkel/test traject, het doen van releases blijft naar mijn mening iets waar voorzichtigheid troef moet zijn. Bug fixing is iets anders.
Ik ben dan ook benieuwd hoe lang Microsoft doorgaat met rolling releases. Voor de gewone gebruiker tot daar aan toe maar in een grote organisatie?
“Technisch werkt dit allemaal als een zonnetje, maar hoe zit het met release notes? Gebruikers instructies? Documentatie? Beheer?”
die scope je gewoon uit, net zoals de auteur dat doet.
Merk op dat in het hele verhaal de eindgebruiker of zelfs de productowner als vertegenwoordiger daarvan, niet voorkomt.
Interessant artikel! Interessant genoeg om me te registreren en te reageren!
“Immers, ontwikkelaars hebben over het algemeen een hekel aan dingen twee keer doen”. Volgens mij heeft iedereen een hekel aan dingen twee keer doen, ik zie niet zo goed wat hier nu precies gesteld wordt.
“Wellicht omdat er nog een organisatorische scheiding bestaat tussen de afdeling die de software ontwikkelt en de afdeling die verantwoordelijk is voor het in productie brengen en beheren van die omgeving. Daar ontbreekt het nog wel eens aan vertrouwen in elkaars kunnen”. DevOps kan hier een mooie oplossing voor zijn (dit geeft ook een oplossing voor de beheerders waar Henri het over heeft).
“Het proces waarmee de broncode wordt omgezet naar de definitieve versie … meegroeien met veranderende eisen en wensen”. Dit betekent dat dit ‘proces’ (packaging software?) ook onderdeel van je repository wordt, inclusief bijbehorend beheer, bugfixing, releasing, etc. Goed om je dat te realiseren. Dat ontwikkelaars dit kunnen testen op hun eigen ontwikkel-pc’s is waar, én goed, maar hoeveel zegt dit over andere testomgevingen en de productie omgeving? Wat mij betreft gaat deze vlieger alleen op als ontwikkelomgevingen behoorlijk productie-like zijn (denk bijvoorbeeld aan loadbalanced omgevingen, of omgevingen waarbij niet alle services op alle nodes draaien). Er moet in ieder geval één test uitrol op een échte productie-like omgeving worden gedaan om te borgen dat de uitrol op de productie omgeving een zo groot mogelijke kans van slagen heeft.
Voor de database gaat het bij een productie uitrol vaak niet eens zozeer om een wijziging op het schema, die zijn relatief makkelijk terug te vinden, maar nog meer om de data! Stel je voor dat je een uitrol hebt gedaan waarbij data wordt gewijzigd/toegevoegd/verwijderd, en dan blijkt bij de eerste testen op productie of eerste productie-run dat de productie-omgeving tóch anders is dan de testomgevingen, en de change moet worden teruggedraaid. Hoe pak je dat aan? Voor dit aspect geloof ik niet zo in een ‘druk-op-de-knop-rollback’.
Henri heeft het over ‘Gebruikers die ineens geconfronteerd worden met een wijziging, nieuwe dingen zien die ze niet begrijpen (en dan bijna automatisch zich ertegen verzetten) , of beheerders die ineens er weer iets bij krijgen of geconfronteerd worden met vragen….’. Als je DevOps en Agile werkt, dan kun je al heel veel van dit soort dingen tackelen.
Voor de goede orde: ik ben een groot voorstander voor het minimaliseren van menselijke handelingen tijdens een uitrol, maar ik zie ook de nodige haken en ogen. Hoe je dit proces daadwerkelijk gaat implementeren in een omgeving waar tot nu toe handmatige uitrollen plaatsvinden is misschien ook nog voer voor een artikel?
Ik kijk in ieder geval met belangstelling uit naar het volgende deel van deze reeks!
Dat valt mij ook altijd op Dino, de focus is helemaal op de techniek en het proces maar dat er ook nog gebruikers of mensen uit de organisatie lijkt vergeten. Gebruikers zijn dus eigenlijk je testers. Maar de productowner schijnt heel belangrijk te zijn bij de scrummers. Belangrijk en bepalend, dus dat die gepasseerd wordt…
@Dick Volgens mij staat devops juist aan de basis van zaken CD en CI. Eerst devops en daarna het hele circus wat er uit voorgekomen. Al is Devops in essentie dat de juiste mensen (gebruikers, ontwikkelaars, testers, beheerders) samen kunnen werken met niet al teveel ruis ertussen. Devops is een oplossing voor een organisatorisch probleem waarbij technisch en inhoudelijke gerelateerde functie gescheiden zijn door organisatie en procedures. Vervolgens de technieken die daar uit voortkomen. Al is het allemaal niet nieuw, dat gebeurde al voordat deze termen bedacht zijn voor bestaande problemen.
De “technische” kant van continuous delivery is prima beschreven in dit artikel, complimenten.
Daarnaast is er ook nog een organisatorische kant. Het gaat daarbij om een verandering in de mindset, niet meer denken in plannen en grote releases maar in kleine product aanvullingen en verbeteringen die het product waardevoller maken voor de klanten.
Een agile aanpak met Scrum of Kanban past hierbij, waarbij je er voor zorgt dat je kleine stukjes definieert die je ontwikkelt en deployed. Pas als het gedeployed is kan de klant het gebruiken, tot die tijd levert de investering geen waarde of geld op.
In veel organisaties zijn de belemmeringen niet technisch maar organisatorisch. Vreemd genoeg wordt er dan vaak wel gesproken over het automatiseren van testen en deployment, maar niet over verbeteren van de samenwerking binnen de organisatieketen om ideeën en klantwensen daadwerkelijk sneller te realiseren. DevOps geeft handvatten hiervoor.
@Dino / Louis : sinds wanneer komen facebook en twitter (de voorbeelden van de auteur) met releasenotes en documentatie ???
Maar … met jullie opmerking geef je ook meteen aan waarom dit soort artikelen (zonder afbreuk te willen doen aan de inhoud) in het juiste perspectief geplaatst moet worden.
Voor het leveren van webdiensten of apps zijn continuous deliver/integration heel goed bruikbaar.
Maar op het moment dat je een product maakt, waarbij ook handleidingen zitten en in sommige sectoren releasenotes verplicht zijn, dan krijgt deze aanpak wel wat beperkingen.
Wordt het daarmee onbruikbaar? Nee hoor, voor intern bouwen en testen kun je de CI/CD aanpak heel goed gebruiken, alleen voor de officiële releases moet je wat extra doen.
Overigens kan een sector nog wel meer beperkingen naar boven brengen. Stel je moet elke levering laten toetsen door een externe organisatie … zijn die er op voorbereid dat ze meerdere malen per dag een toetsing moeten doen?
Ook kan de vraag rijzen, zeker in de wereld van producten, of je wel een deugdelijk product gekocht hebt. Ooit, lang geleden, kochten we televisies waar geen software in zat, en die gingen jaaaren mee. Vandaag de dag kopen we een tv, met software, welke regelmatig bijgewerkt wordt en dan nog niet aan de verwachtingen voldoet. Voor mijn gevoel (als consument) heb ik dan een ondeugdelijk product gekocht.
Nee, Facebook komt met voorstellen waarbij je weet dat je belazerd wordt, maar ook dat als je nee zegt, dat je meteen helemaal niks meer kunt.
Inderdaad veel effectiever dan acceptatietests 🙂
New brave world waarbij de tester en beheerder te stom zijn om te automatiseren en de eindgebruiker te stom is om meer dan het product te zijn. Redding alleen als “de softwareontwikkelaars zich ermee gaan bemoeien. Immers, ontwikkelaars hebben over het algemeen een hekel aan dingen twee keer doen.”