Developers slagen erin software sneller te releasen dan ooit. De overgrote meerderheid (84 procent) van de ontwikkelaars ziet het tempo zelfs behoorlijk omhoog gaan. Bijna zestig procent van de respondenten zegt dat ze twee keer sneller nieuwe versies uitbrengen; een forse toename ten opzichte van de 35 procent van vorig jaar. Nog eens bijna twintig procent zegt tien keer sneller te releasen.
Dit blijkt uit de jaarlijkse ‘DevSecOps Survey’ van GitLab waaraan wereldwijd 4.300 ontwikkelaars meewerkten. De tempoversnelling is te danken aan de toenemende integratie van tools voor broncodebeheer en continuous integration/continuous delivery. Dit laatste betekent dat een wijziging in de code binnen enkele minuten na het schrijven live kan gaan, en zonder downtime.
Levenscycli
Drie op de vier respondenten zegt dat hun devops-team van plan is om artificial intelligence (ai) en machine learning (ml) in te zetten voor het testen en evalueren van code of dit al doet; een toename van iets meer dan veertig procent ten opzichte van 2020.
Een meerderheid van alle operations-teams zegt hun levenscycli (vrijwel) volledig te hebben geautomatiseerd. Dat was in 2020 nog anders. Toen zei acht procent van alle teams dat ze hun cycli hadden geautomatiseerd. Door het integreren van automatisering en ai-/ml-tools in het ontwikkelproces winnen devops-teams tijd die ze aan andere prioriteiten kunnen wijden. Ruim de helft van alle professionals ziet het beheer van clouddiensten als hun belangrijkste prioriteit. Dit weerspiegelt de overstap naar de cloud die plaatsvond door de pandemie.
Knelpunt
Het testen van de beveiliging blijft nog een knelpunt voor devops-teams. Iet s meer dan veertig procent van de respondenten zegt dat dit te laat in het proces gebeurt. Bijna hetzelfde percentage worstelt met het identificeren en verhelpen van kwetsbaarheden. 37 procent ondervindt daarnaast problemen met het bijhouden van de status van bug fixes. Een derde vindt het prioriteren van het verhelpen van bugs lastig.
Het GitLab-onderzoek meldt vooruitgang op het gebied van devsecops. Circa driekwart van alle security-professionals noemt de security-activiteiten van hun organisatie goed of sterk. In 2020 lag dit percentage nog op bijna zestig procent. Zeventig procent laat hun teams security eerder binnen het ontwikkelingsproces plaatsvinden. Een van de redenen hiervoor is dat meer developers statische en dynamische beveiligingstests van applicaties uitvoeren.
Bedrijven blijken nog altijd moeite te hebben om te bepalen wie er precies verantwoordelijk is voor security. Net geen veertig procent van alle security-professionals zegt daar volledig verantwoordelijk voor te zijn. Maar een krappe derde van de respondenten zegt dat iedereen voor de beveiliging verantwoordelijk is. Deze percentages komen overeen met die van vorig jaar.
Johnathan Hunt, vicepresident security bij GitLab: ‘Security is sterker in het ontwikkelproces geïntegreerd. Ons onderzoek wijst echter op de noodzaak van een duidelijke afbakening van verantwoordelijkheden en de inzet van nieuwe tools. Dit is nodig om de security eerder binnen het ontwikkelproces plaats te laten vinden. We hopen dat security-teams innovatieve technologieën voor het scannen en evalueren van code blijven inzetten om de snelheid en kwaliteit van de ontwikkelingscycli op te voeren.’
Sneller releasen maar geen idee hebben wat.
je it levenscyli volledig automatiseren maar vinden dat beveiliging te laat in het proces gebeurt.
snel releasen maar bugs niet kunnen prioriteren.
snel releasen maar niet weten wie nou verantwoordelijk is voor security.
devops maar wel duidelijke afbakening van verantwoordelijkheden ?
agile maar wel met nieuwe tools, weg met “inviduals and interactions” ?
whats next ?
whats next ?
Crash!
Geen weg terug en niemand verantwoordelijk.
Of toch . . . . de ai.
De conclusie uit een enquête (survey) onder 4.300 ontwikkelaars wereldwijd geeft te denken over de ‘governance’ binnen een ontwikkelparadigma zoals DevSecOps omdat er blijkbaar nog altijd veel onduidelijkheid is over wie er voor wat verantwoordelijk is. Tenslotte is een nieuwe release met een paar functionele verbetering imago technisch goed om de markt te laten zien dat het project nog niet dood is want de projectmatige softwareontwikkeling met Short Term Support kent een groot aantal voortijdige beëindigingen. Functionele concurrentie is moordend en DevSecOps cowboys in mn. het open source domain zijn net zo opportuun als Batavus Droogstoppel van de cloud terwijl bedrijfsprocessen veelal een Long Term Support (LTS) contract vereisen als we kijken naar de totale beheerkosten van een silo. Gelukkig hebben steeds meer oplossingen een ‘legacy mode’ waardoor je voor eigen risico een versie kunt laten draaien die niet meer ondersteund wordt. Jan kan zelf onderzoek doen naar hoeveel oude Joomla versies er nog actief zijn.
Oudlid, wist je dat de LAMP-Stack, ook met NGINX, helemaal uit opensource bestaat?
Enige tijd geleden heb ik een artikeltje geschreven over updateritis, dit artikeltje illustreert dit probleem.
Het web draait voor een heel groot deel op foss.
Het is de backwards-compaibiliteit die (te) vaak vergeten wordt door ontwikkelaars die nooit over beheer nadenken.
Jan,
No shit Sherlock. En ben jij bekend met het fenomeen van (f)OSS waar ontwikkelaars niet een stel hippies zijn maar mensen die inzetten op de winst op termijn via opties en aandelen in een project waar de functionele concurrentie uiteindelijk nogal heftig is? Want de updateritis van de gratis community versie versus de enterprise editie leert dat verticale continuous integration in de stack niet zo zeer om de functionele backward compabiliteit (legacy mode) gaat maar om de bugfixes voor bijvoorbeeld security issues. De Long Term Support (LTS) optie is veelal één van de features die je wel tegenkomt in de Enterprise versies maar niet in de gratis community versies.
Dus ja, ik denk dat ik bekend ben met de projectmatige softwareontwikkeling middels het fenomeen (f)OSS zoals ik ook denk bekend te zijn met het paradigma van Dev(Sec)Ops. Want het enige voordeel van open source is een inzichtelijkheid in de code omdat de leesbaarheid ervan bepaalt wordt door andere factoren zoals een code version control system. Het beheer van de code in een release klinkt als iets wat ik 30 jaar geleden deed in de uitdaging van horizontale continuous integration als we kijken naar het probleem van silo’s.
Hoe agile innovatief wendbaar is LTS ? Hoe hip zijn conservatieve devopsers ? Wat heb je aan een code version control systeem als toch niet duidelijk is wat erin moet en wie voor de inhoud verantwoordelijk is ? Is een sprint niet gewoon een kleine release ? Heerlijk, dat vrijblijvend gefilouwehoer. Waar is Jack eigenlijk ?