Het doorlopende leverings-/implementatiemodel
- 4 minuten
U hebt geleerd over de vele nadelen van de 'epische implementatie' als een model voor softwarelevering, maar weten wat niet goed werkt, is slechts de helft van de strijd. In deze les leert u meer over het alternatief voor die monolithische methode en hoe u hiermee uw doel van verbeterde betrouwbaarheid kunt verbeteren.
Het is ook de moeite waard om twee gerelateerde termen te onderscheiden die soms door elkaar worden gebruikt:
- Continue levering: elke wijziging die door geautomatiseerde tests wordt uitgevoerd, is gereed om in productie te worden geïmplementeerd, maar de daadwerkelijke release naar productie wordt door een handmatige goedkeuring afgesloten.
- Continue implementatie: elke wijziging die aan geautomatiseerde tests voldoet, wordt automatisch vrijgegeven voor productie, zonder handmatige poort.
Beide zijn afhankelijk van dezelfde basis (frequente integratie, geautomatiseerde tests, herhaalbare pijplijnen). Deze module is gericht op die gedeelde basisbeginselen.
Wat is doorlopende levering?
Continue levering is een methode waarmee elke wijziging in uw codebase op een snellere, minder stressvolle, minder riskante en meer reproduceerbare manier wordt vrijgegeven . In plaats van van elke software-implementatie een epische gebeurtenis te maken, verandert continue oplevering deze in een snelle, voorspelbare en routinematige ervaring die op aanvraag plaatsvindt.
Implementatiefrequentie: Met een model voor continue levering vinden implementaties vaak plaats. Cadans kan maandelijks, wekelijks, dagelijks of zelfs uurlijk zijn. De sleutel is dat u kleinere, meer gerichte wijzigingen vaker implementeert.
Geactiveerd door het doorvoeren van code: in plaats van te wachten op een releasevenster dat ver van tevoren is gepland, wordt de leveringspijplijn gestart wanneer de code wordt doorgevoerd. Deze code kan software, infrastructuur of zelfs softwareconfiguraties zijn. Elke wijziging wordt vervolgens gebouwd, getest en gereed gehouden voor release. Afhankelijk van de controles van uw organisatie kan promotie naar productie later nog steeds plaatsvinden, na een goedkeuring.
Geautomatiseerd testen: u kunt geïntegreerde geautomatiseerde tests gebruiken, niet alleen om de code te testen, maar ook om snel feedback te geven over de resultaten van deze tests. Dit is deze snelle feedback waarmee u snel mislukte tests kunt herhalen en herstellen.
Zodra uw code is getest, kunt u de implementatie testen totdat deze eindigt in een reeks gefaseerde omgevingen, zoals testen, QA, enzovoort. Als u uw implementaties doorlopend via deze omgevingen uitvoert, wordt dit een geïntegreerd onderdeel van de implementatie-ervaring.
Historische records: U wilt niet alleen een historisch overzicht van implementatieactiviteiten, maar u wilt ook uw productieomgeving op elk gewenst moment kunnen afstemmen. U wilt weten welke implementatie uw huidige productieomgeving heeft gemaakt. Met deze kennis kunt u zaken traceren zoals configuraties, testresultaten en de code zelf helemaal terug naar de afzonderlijke pull-aanvraag die de implementatie heeft geactiveerd.
Implementatiedoelen
Nu u weet hoe continue levering werkt, kunt u de doelstellingen voor continue levering en andere DevOps-procedures overwegen om softwareoplossingen te implementeren.
Doel 1: Verminder de stress die gepaard gaat met het implementeren van services terwijl de betrouwbaarheid van deze services wordt verhoogd
Het verminderen van de stress van software- en infrastructuurimplementaties verbetert de dagelijkse ervaring van de technici die deze uitvoeren. De resulterende toename van betrouwbaarheid levert ook eindgebruikers op, die minder storingen en onderbrekingen zien.
Doel 2: Verminder de tijd tussen wanneer u weet dat een wijziging vereist is en wanneer die wijziging wordt geïmplementeerd in productie
Stel dat u een codefout hebt geïdentificeerd die invloed heeft op de omzet en u weet precies hoe u dit kunt oplossen. Met volwassen DevOps-procedures is het pad van doorvoer naar productie kort en voorspelbaar. De wijziging wordt gebouwd, automatisch getest in de relevante omgevingen en wordt binnen enkele minuten voorbereid op release. Zodra de vereiste goedkeuring is gegeven, kan deze worden gepromoveerd naar productie in plaats van te worden bewaard voor een toekomstig releasevenster.
Doel 3: De tijd beperken tussen het hebben van een idee en het leveren van bruikbare software
Dit doel is vergelijkbaar met de vorige, maar richt zich op innovatie in plaats van oplossingen. Hoe lang duurt het om op een nieuw idee te reageren? Met dit implementatiemodel kunt u een nieuw concept integreren in een productiesysteem met het vertrouwen dat de toevoeging het huidige systeem niet onderbreekt of belemmert. Met dit vertrouwen kunt u snel nieuwe functies leveren.
Implementatieresultaten
De doelstellingen die in deze les worden besproken, zijn niet alleen theoretische aspiraties, ze zijn meetbaar. Sinds 2014 heeft het DORA-team (DevOps Research and Assessment) jaarlijks state of DevOps research gepubliceerd over de prestaties van softwarelevering. In de afgelopen jaren is dit werk gepubliceerd als de versnelde status van het DevOps-rapport. Het huidige DORA-model houdt vijf metrische leveringsgegevens bij:
- Implementatiefrequentie
- Doorlooptijd wijzigen
- Wijziging faalpercentage
- Hersteltijd voor mislukte implementatie
- Implementatieherwerkfrequentie
Jaar na jaar toont het onderzoek aan dat beter presterende teams vaker wijzigingen leveren, sneller overstappen van doorvoer naar productie, sneller herstellen van mislukte implementaties en minder tijd besteden aan het oplossen van implementatieproblemen. Zie de metrische gegevens over softwarelevering van DORA voor de meest recente onderzoeks- en metrische definities.
Deze resultaten valideren het idee dat implementatieprocedures van belang zijn.