De rollen binnen software development-teams veranderen snel nu steeds meer bedrijven devops omarmen. Ook de organisatiestructuur en toolkeuzes bewegen mee. Continuous development begint nu echt door te breken.
Dit blijkt uit het vierde jaarlijkse devsecpps-onderzoek dat GitLab heeft gedaan onder 3650 respondenten in 21 landen. Uit Nederland beantwoordden ruim honderd mensen de vragen, uit België deden er vrijwel geen mensen mee aan het onderzoek.
Het gebruik van devops stijgt snel. Een kwart van de bedrijven heeft er inmiddels drie tot vijf jaar praktijkervaring mee. 37 procent is goed op weg met devops en beschikt over een tot drie jaar ervaring. Veel bedrijven die hier gebruik van maken, plukken de voordelen van continuous deployment. Bijna 60 procent implementeert code meerdere keren per dag, één keer per dag of eens in de zoveel dagen. Dit percentage lag vorig jaar nog op 45 procent.
70 procent van alle operations professionals zegt dat developers hun eigen omgevingen in kunnen richten. Dat wijst op veranderende verantwoordelijkheden. De releasetijden worden korter. Continuous integration/deployment (ci/cd) neemt toe.
De grens tussen developers en operations begint bovendien te vervagen. Ruim driekwart, 35 procent van de developers zegt dat ze de infrastructuur waarop hun apps draaien zelf definiëren dan wel inrichten. 14 procent bewaakt en beheert die infrastructuur, een taak die traditioneel was weggelegd voor het operations team. Meer dan 18 procent van de developers implementeert code voor het bewaken van de productieomgeving en 12 procent fungeert als aanspreekpunt voor incidenten.
Security blijft heet hangijzer
Ceo en medeoprichter Sid Sijbrandij ziet in deze cijfers een bevestiging voor de stelling dat elk bedrijf tegenwoordig een softwarebedrijf is. Volgens hem is het belangrijker dan ooit dat teams goed begrip hebben van de veranderende rol van developer en de invloed daarvan op de verantwoordelijkheden van de security, operations en test teams.
Security blijft een heet hangijzer. Volgens Sijbrandij bestaat er nog steeds een behoorlijke kloof tussen de teams van developers en security. Daarbij is er vooral onzekerheid over de vraag wie verantwoordelijk is voor beveiligingsactiviteiten. Ruim een kwart van de developers zegt zich als enige verantwoordelijk te voelen voor security. Datzelfde geldt voor 23 procent van de testers en 21 procent van de operations professionals.
Binnen securityteams bestaat nog meer verwarring. Een derde van de ondervraagde securityspecialisten zegt verantwoordelijk te zijn voor de eigen beveiliging. Bijna evenveel respondenten (29 procent) menen dat iedereen voor de beveiliging verantwoordelijk zou moeten zijn. Ook klinkt regelmatig de klacht dat ontwikkelaars onvoldoende verantwoordelijkheid nemen voor bugs. Securityteams verwijten hen niet genoeg bugs te vinden in een vroegtijdig ontwikkelingsstadium. Daarnaast wordt hen voor de voeten geworpen dat ze niet genoeg vaart maken met het prioriteren en verhelpen van deze bugs. Bij het onderzoek van vorig jaar werd daar ook veel over geklaagd. Meer dan 42 procent zegt dat het testen nog altijd te laat in de levenscyclus plaatsvindt terwijl 36 procent zegt het lastig te vinden geïdentificeerde kwetsbaarheden te begrijpen, te verwerken en te repareren. 31 procent vond het stellen van prioriteiten tijdens het verhelpen van kwetsbaarheden tot slot een lastig proces.
Testproces blijkt bottleneck
GitLab constateert dat bijna 83 procent van de developers na de overstap op devops in staat is om sneller code af te leveren. Continuous integration/deployment (ci/cd) blijkt de tijd die nodig is voor het ontwikkelen en in productie nemen van applicaties, aanzienlijk te verkorten. Ruim een derde van de developers zegt dat hun devops-implementaties ci/cd omvatten. Nog eens 29 procent zegt voor hun devops-implementaties gebruik te maken van geautomatiseerde testprocessen, 16 procent heeft devsecops omarmd, bijna 9 procent werkt in een multi-cloud-omgeving.
Tegelijkertijd blijkt het testproces net als vorig jaar de belangrijkste bottleneck te zijn. Geautomatiseerd testen is in opkomst, maar slechts 12 procent van alle respondenten zegt het testproces volledig te hebben geautomatiseerd. En hoewel 60 procent aangeeft implementaties meerdere keren per dag, eenmaal per dag of eens in de zoveel dagen uit te voeren, vindt 42 procent dat het testen te laat in de levenscyclus van ontwikkeling plaatsvindt.
Leuk stukje en vooral ook heel herkenbaar!
Misschien leuk om eens te kijken naar http://www.orangebeard.io. Deze dienst (een uitgebreid dashboard met al je testruns en testresultaten in één overzicht, onder meer grafisch weergegeven op basis van de test automation pyramid) brengt niet alleen “real-time” al je geautomatiseerde testprocessen en -resultaten in beeld, waardoor je snel(lere) feedback krijgt,maar heeft ook nog eens een ingebouwde security scan die automatisch bij iedere deployment in je pijplijn meeloopt en in ieder geval rapporteert over de kwetsbaarheden conform de OWASP top 10.
Het systeem/dashboard is gebouwd op Artificial Intelligence en hierdoor zelflerend. Orangebeard gebruikt Machine Learning om te leren van eerdere resultaten en acties. Hierdoor worden bepaalde fouten door het systeem gecategoriseerd. Op deze manier is er minder tijd nodig om de testresultaten te evalueren, fouten uit te zoeken en kan de software sneller worden aangepast. Door het zelflerende vermogen van Orangebeard kan het systeem herkennen welke tests horen bij bepaalde code(wijzigingen). Orangebeard zoekt zelfstandig, dankzij haar algoritme, naar de correlatie tussen eerder ingecheckte code en uitgevoerde tests en de aankomende test die benodigd is voor de specifieke build. Hierdoor selecteert het systeem enkel de relevante tests zodat de testtijd aanzienlijk wordt gereduceerd. Hiermee wordt voorkomen dat een build binnen een CI/CD-pipeline de gehele testset moet doorlopen. Er wordt dus enkel getest wat er getest moet worden, met een snellere release tot gevolg.
Om snel live te kunnen gaan in een continuous delivery omgeving is een regressietest (die bijvoorbeeld 8 uur duurt) niet wenselijk. De vraag is dan of elke test binnen de regressieset wel nodig is? Het handmatig prioriteren van tests binnen een geautomatiseerde testomgeving is nagenoeg niet meer te doen en kost te veel tijd ten opzichte van de tijd dat de test duurt.
Herkenbaar dat security weer iets achterblijft in dit soort ontwikkelingen. Dat terwijl er tegenwoordig genoeg automated security scanners geïntegreerd kunnen worden in het CI/CD proces. Dat gecombineerd met handmatig security testing zou het toch aanzienlijk veiliger maken.
@Joep .. zal deels van de omgeving afhangen. Ik heb een tijdje in een, wat we vandaag de dag noemen, low-code development omgeving gewerkt. De ontwikkelomgeving draaide in de cloud onder beheer van de leverancier van die omgeving. Als je dan security en penetratietesten wilde doen, moest dit ruim van tevoren aangevraagd worden, en als je dan iets vond en opnieuw wilde testen mocht je weer een nieuw test-window aanvragen
Werkt op zich wel, maar past niet binnen het continue plaatje
@ PAVAKE. Ja dat maak ik ook wel eens mee, maar wordt gelukkig steeds beter. Steeds meer partijen weten inmiddels wel wat de risico;s zijn van een test. En grotere partijen zoals MS en AWS kun je zonder toestemming testen tegenwoordig.
Tegenstrijdige statistieken die op allerlei manieren uitgelegd kan worden. De een zegt wat, een ander vindt wat.
Interessant.
Als ik het goed begrijp gaat het er om dat je sneller deployt dan dat je weet wie nou vooraf, tijdens en na afloop van de deployment ergens verantwoordelijk voor was, is en wordt.
To be continued.
Vrij bizar dat slechts 12% automatisch testen heeft geimplementeerd. Wat is het nut om continuous te gaan developen als je continu moet wachten op de uitslag van handmatige tests? Implementaties meerdere keren per dag … arme gebruikers.
@KJ … jammer genoeg missen we wat context in het artikel. In de wereld van websites en apps bijvoorbeeld is volledig geautomatiseerd testen al helemaal ingeburgerd, en zijn er diverse tools en technieken beschikbaar waaruit je kunt kiezen
Ga je echter in de industrie/embedded wereld kijken, dan ligt dat een stuk complexer. Unittesten etc zijn daar ondertussen wel ingeburgerd, maar integratie- en/of systeemtesten zijn lang niet altijd even eenvoudig te automatiseren (complexiteit, klant-specifieke systemen, kosten)
Het zou interessant zijn als de getallen te mappen zijn op sectoren/industrieën
@Pa Va Ke | 20 mei 2020 13:39
Inderdaad, we missen wat context. Wellicht dat de auteur eea. nog kan toelichten?