Fremskynd frigivelseslivscyklussen med udrulningsvej: Del 1 – IBM Blog

For mange virksomheder reducerer rejsen til cloud tekniske gældsomkostninger og opfylder CapEx-til-OpEx mål. Dette omfatter ombygning til microservices, løft-og-skift, replatforming, refaktorering, udskiftning og mere. Som praksis som DevOps, sky indfødte, serverless , site reliability engineering (SRE) modent skifter fokus mod betydelige niveauer af automatisering, hastighed, smidighed og forretningstilpasning til IT (hvilket hjælper virksomhedens IT med at transformere sig til ingeniørorganisationer).

Mange virksomheder kæmper for at få reel værdi ud af deres cloud-rejser og kan fortsætte med at overforbruge. Mange analytikere har rapporteret, at over 90 % af virksomhederne fortsætter med at overforbruge i skyen, ofte uden at opnå væsentlige afkast.

Den sande essens af værdi opstår, når forretning og IT kan samarbejde om at skabe nye muligheder med høj hastighed, hvilket resulterer i større udviklerproduktivitet og hastighed til markedet. Disse mål kræver en måldriftsmodel. Hurtig udrulning af applikationer til skyen kræver ikke kun udviklingsacceleration med kontinuerlig integration, implementering og test (CI/CD/CT), det kræver også acceleration af forsyningskædens livscyklus, som involverer flere andre grupper såsom governance risk and compliance (GRC), change management , drift, robusthed og pålidelighed. Virksomheder leder hele tiden efter måder, der giver produktteams mulighed for at bevæge sig fra koncept til implementering hurtigere end nogensinde før.

Automation-first og DevSecOps-ledet tilgang

Virksomheder eftermonterer ofte cloud-transformationselementer inden for eksisterende applikationsforsyningskædeprocesser i stedet for at overveje nye livscyklus- og leveringsmodeller, der er velegnede til hastighed og skala. De virksomheder, der genskaber applikationslivscyklussen gennem en automatisering-først tilgang, tilskynder til en ingeniørdrevet produktlivscyklusacceleration, der realiserer potentialet i cloud-transformation. Eksempler omfatter:

• Mønsterbaseret arkitektur, der standardiserer arkitektur- og designprocessen (mens teams har autonomi til at vælge mønstre og teknologi eller samskabe nye mønstre).
• Mønstre, der adresserer sikkerheds- og overholdelsesdimensioner, hvilket sikrer sporbarhed til disse krav.
• Mønstre-som-kode, der hjælper med at kodificere flere tværgående bekymringer (dette fremmer også den indre kildemodel for mønstres modenhed og fremmer genbrugelighed).
• DevOps pipeline-drevne aktiviteter, der kan bruges på tværs af livscyklussen.
• Automatisk generering af specifikke data, der er nødvendige for sikkerheds- og overholdelsesgennemgange.
• Driftsberedskabsgennemgange med begrænset eller ingen manuel indgriben.

Efterhånden som virksomheder omfavner cloud native og alt som kode, er rejsen fra kode til produktion blevet et kritisk aspekt for at levere værdi til kunderne. Denne indviklede proces, ofte omtalt som "vej at implementere,” omfatter en række indviklede trin og beslutninger, der kan påvirke en organisations evne til at levere software effektivt, pålideligt og i stor skala. Fra arkitektur, design, kodeudvikling, test til implementering og overvågning, byder hvert trin i implementeringsvejen på unikke udfordringer og muligheder. Mens du navigerer i kompleksiteten, der eksisterer i dag, sigter IBM® på at hjælpe dig med at afdække strategierne og måltilstandstilstanden for at opnå en problemfri og effektiv implementeringsvej.

De bedste praksisser, værktøjer og metoder, der giver organisationer mulighed for at strømline deres softwareleveringspipelines, reducere time-to-market, forbedre softwarekvaliteten og sikre robuste operationer i produktionsmiljøer, vil alle blive udforsket.

Det andet indlæg i denne serie leverer en modenhedsmodel og byggeklodser til at hjælpe virksomheder med at accelerere deres softwareforsyningskædelivscyklus i det stadigt udviklende landskab af enterprise cloud-native softwareudvikling.

Vej til implementering: Nuværende visning og udfordringer

Diagrammet nedenfor opsummerer en visning af virksomhedens softwareudviklings livscyklus (SDLC) med typiske porte. Selvom flowet er selvforklarende, er nøglen at forstå, at der er flere aspekter af softwareforsyningskædeprocessen, der gør dette til en kombination af vandfald og intermitterende agile modeller. Udfordringen er, at tidslinjen for build-implementering af en applikation (eller en iteration af den) påvirkes af adskillige første- og sidste-mile-aktiviteter, som typisk forbliver manuelle.

De vigtigste udfordringer med den traditionelle karakter af SDLC er:

1. Før-udvikling ventetid på 4-8 uger inden for arkitektur og design fase for at komme til udvikling. Dette skyldes:
   • Flere første mile-gennemgange for at sikre, at der ikke er negative forretningsmæssige konsekvenser, herunder privatlivsproblemer, dataklassificering, forretningskontinuitet og lovoverholdelse (og de fleste af disse er manuelle).
   • Enterprise-wide SDLC-processer, der forbliver vandfald eller semi-agile, der kræver sekventiel udførelse, på trods af agile principper i udviklingscyklusser (f.eks. miljøprovisionering først efter fuld designgodkendelse).
   • Ansøgninger, der opfattes som "unikke", er genstand for dyb undersøgelse og indgreb med begrænsede muligheder for acceleration.
   • Udfordringer med at institutionalisere mønsterbaseret arkitektur og udvikling på grund af manglende sammenhængende indsats og forandringsagentdrift, sådan standardisering.
   • En sikkerhedskultur, der påvirker udviklingshastigheden, med overholdelse af sikkerhedskontroller og retningslinjer, der ofte involverer manuelle eller semi-manuelle processer.
2. Udviklingsventetid til levering af miljø og CI/CD/CT-værktøjsintegration på grund af:
   • Manuel eller semi-automatiseret miljøforsyning.
   • Mønstre (på papir) kun som foreskrivende vejledning.
   • Fragmenteret DevOps-værktøj, der kræver en indsats for at sy sammen.
3. Ventetiden efter udvikling (sidste mile) før start er let 6-8 uger eller mere på grund af:
   • Manuel bevisindsamling for at komme igennem sikkerheds- og overholdelsesgennemgange ud over standard SAST/SCA/DAST (såsom sikkerhedskonfiguration, dag 2 kontroller, tagging og mere).
   • Manuel indsamling af beviser til gennemgang af drift og modstandsdygtighed (såsom understøttelse af cloud-drift og forretningskontinuitet).
   • Serviceovergangsgennemgange for at understøtte it-service og hændelseshåndtering og løsning.

Vej til implementering: Måltilstand

Vejen til at implementere måltilstand kræver en strømlinet og effektiv proces, der minimerer flaskehalse og accelererer transformation af softwareforsyningskæden. I denne ideelle tilstand er vejen til implementering kendetegnet ved en problemfri integration af design (first mile), såvel som udvikling, test, platformskonstruktion og implementeringsstadier (last mile), efter agile og DevOps-principper. Dette hjælper med at accelerere implementeringen af ​​kodeændringer hurtigt og automatisk med nødvendige (automatiseringsdrevne) valideringer til produktionsmiljøer.

IBMs vision om måltilstand prioriterer sikkerhed og overholdelse ved at integrere sikkerhedstjek og overensstemmelsesvalidering i CI/CD/CT-pipelinen, hvilket muliggør tidlig opdagelse og løsning af sårbarheder. Denne vision lægger vægt på samarbejde mellem udviklings-, drift-, pålideligheds- og sikkerhedsteams gennem en fælles ansvarsmodel. Det etablerer også løbende overvågning og feedback-loops for at indsamle indsigt til yderligere forbedringer. I sidste ende sigter målstaten mod at levere softwareopdateringer og nye funktioner til slutbrugere hurtigt, med minimal manuel indgriben og med en høj grad af tillid for alle virksomhedens interessenter.

Diagrammet nedenfor viser en potentiel målvisning af en vej til implementering, der hjælper med at omfavne den cloud-native SDLC-model.

Nøgleelementer i den cloud-native SDLC-model inkluderer:

• Mønsterdrevet arkitektur og design institutionaliseret på tværs af virksomheden.
• Mønstre, der inkorporerer nøglekrav til sikkerhed, compliance, robusthed og andre virksomhedspolitikker (som kode).
• Sikkerheds- og compliance-gennemgange, der accelereres som mønstre og bruges til at beskrive løsningen.
• Kerneudvikling, herunder oprettelse af miljøer, pipelines og servicekonfigurationer (som er drevet gennem platformsingeniørvirksomhedskatalog).
• CI/CD/CT-pipeline, der bygger forbindelser til alle aktiviteter på tværs af forløbet for at implementere livscyklus.
• Platformteknik bygger-konfigurerer-administrerer platforme og tjenester med alle virksomhedspolitikker (såsom kryptering) indlejret som platformspolitikker.
• Sikkerheds- og complianceværktøjer (f.eks. sårbarhedsscanninger eller politiktjek) og automatisering, der er integreret i pipelines eller tilgængelig som selvbetjening.
• Generering af en høj grad af data (fra logfiler, værktøjsoutput og kodescanningsindsigt) til flere anmeldelser uden manuel indgriben.
• Sporbarhed fra efterslæb til udgivelsesbemærkninger til implementering og ændringspåvirkning.
• Indgreb kun ved undtagelser.

Vejen til implementering driver acceleration gennem klarhed, ansvarlighed og sporbarhed

Ved at definere en struktureret vej til implementering, kan organisationer standardisere de trin, der er involveret i forsyningskædens livscyklus, og sikre, at hver fase er sporbar og auditerbar. Dette giver interessenter mulighed for at overvåge fremskridt gennem adskilte faser, fra indledende design til implementering, hvilket giver real-time synlighed i programmets status. Ved at tildele ejerskab på hvert trin i implementeringsforløbet sikrer det, at teammedlemmer er ansvarlige for deres leverancer, hvilket gør det nemmere at spore bidrag og ændringer samt fremskynde problemløsning med det rette niveau af indgreb. Sporbarhed gennem implementeringsvejen giver datadrevet indsigt, der hjælper med at forfine processer og øge effektiviteten i fremtidige programmer. En veldokumenteret vej til implementering understøtter overholdelse af industriregler og forenkler rapportering, da hver del af processen er klart registreret og kan genfindes.

Læs del 2: Udforskning af modenhedsmodellen og realiseringstilgangen