Undersøgelse: Devops sparker release-hastigheden i vejret

Illustration: Bigstock/KSLan
Mottoet 'udsend tidligt, udsend ofte' er blevet hørt på verdens softwarevirksomheder.

Devops-metodik kan sætte hastigheden hvormed nye udgaver af et stykke software udsendes drastisk i vejret.

Det viser kodefirmaet Gitlabs nye undersøgelse Global Devsecops Survey.

57 procent af besvarelserne fortæller, at Devops sætter release-hastigheden op til det dobbelte. Det er et pænt spring fra sidste års 35 procent. 19 procent melder, at koden ryger ud hele ti gange hurtigere.

84 procent fortæller, at de nu udsender kode hurtigere end tidligere.

En tendens, der forsætter fra sidste år, er, at udviklere i større grad tager ansvar for opgaver, der tidligere har ligget hos drift- og sikkerhedsfolk.

Sikkerhedstest er stadig et stort flaskehalsproblem for virksomheder, hvor 42 procent svarer, at test sker for sent i processen, mens 37 procent mener, at det er svært og udfordrende at holde styr på fejlrettelser.

Teknikker, der bygger på machine learning til test og gennemgang af kode, vinder større indpas. 75 procent svarer at man allerede benytter eller planlægger at benytte AI og ML, op fra 41 procent sidste år.

Der indgik over 4294 software-professionelle i undersøgelsen, der fandt sted fra januar til marts i år.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Claus Bobjerg Juul

Sikkerhedstest er stadig et stort flaskehalsproblem for virksomheder, hvor 42 procent svarer, at test sker for sent i processen, mens 37 procent mener, at det er svært og udfordrende at holde styr på fejlrettelser.

Mon de tests omfatter at software regner rigtigt? Altså kontrol som skal undgå tilfælde som Danske Bank sagen hvor beregningerne i mange år er foretaget forkert.

  • 0
  • 1
#3 Klavs Klavsen

Mon de tests omfatter at software regner rigtigt? Altså kontrol som skal undgå tilfælde som Danske Bank sagen hvor beregningerne i mange år er foretaget forkert.

Det er dem slags tests man forhåbentlig forsøger at have i sin CI test pipelines (som dog ikke er sikkerhedstests, men funktionstests) - og når først man har sin CI pipeline op og køre med et test framework, så hjælper det at have en god regel om at test coverage "ihvertfald ikke må gå ned ad" for en ny Merge Request (aka. Pull Request) - og så som minimum lave de tests der fanger bugs man finder, FØR man fikser bug'en (så man kan bekræfte at testen også fejler med bug'en - og går i grøn bagefter :)

  • 1
  • 0
#4 Claus Bobjerg Juul

Det er vel stregt taget ikke det en sikkerhedstest skal kunne?

For hvordan skulle en sikkerhedstest, som er beregnet til at fange sårbarheder, kunne fange, at der er noget galt i forretningslogikken?

IT-Sikkerheder er defineret som C, I og A eller på dansk F, I og T.

Hvis der ikke regnes rigtigt, så opretholdes integriteten ikke.

Så sikkerhedstests KAN inkludere tests der kontrollere om løsningen regner rigtigt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere