Wat is continue levering?

Voordat software aan de eindgebruiker zou kunnen worden vrijgegeven, moet deze langdurig worden ontwikkeld, getest en gecontroleerd. Deze watervalmethode, waarbij alle producten vooraf werden ontwikkeld voordat ze werden getest en vervolgens werden geïmplementeerd, was zeer tijdrovend en resulteerde in langzame implementatiecycli en een minder positieve gebruikerservaring.

Als kernonderdeel van DevOps en werkend binnen de grotere context van CI/CDontstond continue levering als onderdeel van de Agile-softwarerevolutie. In plaats van complete pakketten tegelijk te maken, omvat continue levering alle aspecten van bouwcode die in productie kunnen worden genomen, terwijl geavanceerde automatiseringsoplossingen worden gebruikt voor repetitieve taken zoals testen. Ontwikkelaars kunnen hiermee kleinere softwarewijzigingen met een consistentere snelheid verzenden. Onder bepaalde omstandigheden kan de code rechtstreeks naar de productie gaan, iets wat ook wel continue implementatie wordt genoemd.

Dit biedt een aantal belangrijke voordelen voor bedrijven en softwareleveranciers:

Wanneer ontwikkelaars grootschalige implementaties uitbrengen, kan er veel fout gaan. Continue levering beperkt het risico van implementatie door te focussen op kleine veranderingen die gemakkelijker te onderzoeken zijn en op probleemoplossing, en waarvoor minder tijd nodig is in het geval ze niet werken zoals verwacht.

In plaats van alleen maar te wachten op ontwikkelaars om te beslissen wanneer het werk is voltooid, kunnen applicatie- en projecteigenaren met continue levering de voortgang eenvoudig in kaart brengen door de leveringscycli van software bij te houden en te bepalen wanneer en hoe de implementatie in productie- of testomgevingen moet worden voortgezet. In sommige gevallen kan het wenselijk zijn om de informatie die is verzameld tijdens de levenscyclus van continue levering te gebruiken binnen een Value Stream Management-oplossing om inzicht te krijgen in de relatieve capaciteiten van teams en om knelpunten te identificeren en te verwijderen.

Wanneer software-implementaties vooraf vastgestelde ontwikkelingsfasen doorlopen, kunnen afzonderlijke fasen veel tijd in beslag nemen. Continue levering dwingt teams om test- en hersteltaken in andere dagelijkse processen op te bouwen, te vertrouwen op automatisering bij het bouwen, leveren en meer om de last te helpen verlichten. Dit zorgt voor minder ontwikkelingsfasen, veel minder overbodig werk en snellere doorlooptijden. Het kenmerk van continue levering is zelfs dat het software produceert die op elk moment kan worden uitgebracht - een opmerkelijke verbetering ten opzichte van de lange levertijden van traditionele softwareontwikkeling.

Wanneer ontwikkelaars veel tijd investeren in het bouwen van iets, om pas bij de release te ontdekken dat het ineffectief of slecht ontvangen is, worden ze gedwongen om terug naar af te keren en kunnen ze nauwelijks blijk geven van al hun inspanningen. Kortere, frequentere releases brengen eerder test- en andere problemen aan het licht en stellen de gebruikers van de applicatie in staat om vroeg en vaak feedback te geven, zodat ontwikkelaars waar nodig koerscorrecties kunnen aanbrengen.

Met betrouwbare feedback gedurende de gehele levenscyclus van de levering kunnen ontwikkelaars hun producten verbeteren en stroomlijnen, functies en ideeën testen en alles wegnemen dat onnodig of ineffectief is of een negatieve gebruikerservaring creëert.

Continue levering is afhankelijk van automatisering om een groot deel van de vaste kosten te elimineren waarmee softwareontwikkeling traditioneel te kampen heeft. Dit betekent minder kosten voor en tijdens de ontwikkelingslevenscyclus, en een hoger rendement op de resterende kosten.

Ontwikkelingsmarathons en aanstormende projectdeadlines zijn een manier om ontwikkelingsteams uit te putten. Omgekeerd kunnen kleinschalige oplossingen en releases eenvoudiger en in combinatie met andere taken worden beheerd. Continue levering zorgt niet alleen voor een minder stressvolle werkomgeving en helpt burn-out te voorkomen, maar stelt ontwikkelaars ook in staat om rechtstreeks met gebruikers te communiceren en precies te zien hoe hun inspanningen klanten ten goede komen.

Op het eerste gezicht klinkt en ziet continue levering er veel uit als continue implementatie. Maar hoewel ze beide deel uitmaken van de Agile-benadering van softwareontwikkeling, zijn er subtiele verschillen tussen de twee variaties die de moeite waard zijn om te erkennen.

Zoals hierboven beschreven, automatiseert continue levering veel van de processen die betrokken zijn bij softwareontwikkeling en stelt het teams in staat om incrementele, doorlopende wijzigingen aan te brengen in producten. Maar waar continue levering niet wordt geautomatiseerd, is de laatste fase van de goedkeuring van de implementatie voor productie. Wijzigingen die zijn aangebracht en doorgevoerd in testomgevingen, worden doorgaans handmatig beoordeeld en geautoriseerd als onderdeel van een geplande release voor volledige implementatie.

Bij continue implementatie gaat automatisering nog verder doordat updates automatisch worden geïmplementeerd volgens een vooraf gedefinieerd schema of zodra de code wordt geleverd vanuit het continue levering-proces. Als code geen implementatieperiode vereist, krijgen ontwikkelaars door change governance (indien gebruikt) te automatiseren op een betrouwbare manier direct toegang tot de productie en zorgen er zo voor dat updates regelmatig worden uitgevoerd, zonder dat ze de deur uit hoeven te gaan. Dit geeft bedrijven meer capaciteit om op elk moment meer implementaties uit te brengen en neemt zelfs veel gedoe met grote releases weg. Voor de meeste organisaties is de noodzaak van een sterk bestuur, bijvoorbeeld vanwege de regelgeving in de branche, een van de belangrijkste remmen op continue implementatie. De invoering van continue implementatie in dit soort organisaties is grotendeels afhankelijk van de mogelijkheid om op effectieve wijze te automatiseren wat voorheen handmatige goedkeuringen waren, zoals in een formeel proces voor wijzigingsbeheer.

Het algemene concept van continue levering is eenvoudig te begrijpen: splits tijdrovende ontwikkelingsprocessen op door automatisering ondersteunde kleinschalige taken en releases. Het idee begrijpen en weten hoe de methodologie moet worden geïmplementeerd, zijn echter twee afzonderlijke dingen. De volgende essentiële voorwaarden zijn van essentieel belang bij de overstap naar continue levering van software:

De hierboven genoemde watervalbenadering van softwareontwikkeling kan nog steeds diep in de gedachten en processen van ontwikkelingsteams zijn verankerd. Daarom is uitgebreide planning en grondige training nodig om de culturele overstap te maken naar DevOps en Agile-ontwikkeling. Als ontwikkelingsteams niet betrokken zijn, zal continue levering waarschijnlijk niet slagen.

De culturele verschuiving naar DevOps moet verder gaan dan alleen maar softwareontwikkeling. Snelle feedbacklussen en effectieve besluitvorming vragen om een duidelijke samenwerking en coördinatie met het management, zodat iedereen zich volledig bewust is van de juiste processen en zich daarvoor helemaal inzet.

Snelle doorlooptijden en probleemloze softwarereleases doen organisaties niet veel goed als de eindproducten niet kunnen voldoen aan beveiligings- of compliancevereisten. Gelukkig kunnen veel van dezelfde benaderingen van automatiseringstools, die worden gebruikt voor continue levering, worden toegepast om het beveiligingsrisico dat de implementatie met zich meebrengt, te beperken. Tools voor het automatisch scannen van codes met beleid dat is vastgesteld door gespecialiseerde beveiligingsteams maken deel uit van de pijplijn. Als geautomatiseerd wijzigingsbeheer in gebruik is, worden de succesvolle voltooiing van deze scans onderdeel van de informatie die wordt gebruikt om wijzigingsaanvragen automatisch te maken en goed te keuren.