Accelerera utgivningslivscykeln med väg att distribuera: Del 1 – IBM Blog

För många företag minskar resan till molnet tekniska skuldkostnader och möter CapEx-till-OpEx mål. Detta inkluderar omarkitektur till microservices, lyft-och-skift, omplattformar, omfaktorer, ersätter och mer. Som praxis som DevOps, moln infödd, Server och site reliability engineering (SRE) När det är moget förskjuts fokus mot betydande nivåer av automatisering, snabbhet, smidighet och affärsanpassning med IT (vilket hjälper företags-IT att omvandlas till ingenjörsorganisationer).

Många företag kämpar för att få verkligt värde från sina molnresor och kan fortsätta att spendera för mycket. Flera olika analytiker har rapporterat att över 90 % av företagen fortsätter att spendera för mycket i molnet, ofta utan att realisera betydande avkastning.

Den sanna essensen av värde uppstår när företag och IT kan samarbeta för att skapa nya möjligheter i hög hastighet, vilket resulterar i högre produktivitet hos utvecklarna och snabbare ut på marknaden. Dessa mål kräver en målsättningsmodell. Att snabbt distribuera applikationer till molnet kräver inte bara utvecklingsacceleration med kontinuerlig integration, implementering och testning (CI/CD/CT), det kräver också acceleration av leveranskedjans livscykel, vilket involverar flera andra grupper som förvaltningsrisk och efterlevnad (GRC), förändringshantering , drift, motståndskraft och tillförlitlighet. Företag letar ständigt efter sätt som ger produktteam möjlighet att gå från koncept till implementering snabbare än någonsin.

Automation-first och DevSecOps-ledd strategi

Företag retrofiterar ofta molntransformationselement inom befintliga applikationsförsörjningskedjasprocesser snarare än att överväga nya livscykel- och leveransmodeller som är lämpade för hastighet och skala. De företag som ombildar applikationslivscykeln genom ett tillvägagångssätt med automatisering först uppmuntrar en ingenjörsdriven produktlivscykelacceleration som realiserar potentialen i molntransformation. Exempel inkluderar:

• Mönsterbaserad arkitektur som standardiserar arkitekturen och designprocessen (medan teamen har autonomi att välja mönster och teknik eller samskapa nya mönster).
• Mönster som adresserar säkerhets- och efterlevnadsdimensioner, vilket säkerställer spårbarhet till dessa krav.
• Mönster-som-kod som hjälper till att kodifiera flera tvärgående problem (detta främjar också den inre källmodellen för mönstermognad och driver återanvändbarhet).
• DevOps pipeline-drivna aktiviteter som kan användas över hela livscykeln.
• Automatisk generering av specifik data som behövs för säkerhets- och efterlevnadsgranskningar.
• Driftsberedskapsgenomgångar med begränsade eller inga manuella ingrepp.

När företag omfamnar cloudnative och allt som kod, har resan från kod till produktion blivit en kritisk aspekt för att leverera värde till kunderna. Denna invecklade process, ofta kallad "väg att distribuera”, omfattar en serie komplicerade steg och beslut som avsevärt kan påverka en organisations förmåga att leverera programvara effektivt, tillförlitligt och i stor skala. Från arkitektur, design, kodutveckling, testning till implementering och övervakning, varje steg i implementeringsvägen erbjuder unika utmaningar och möjligheter. När du navigerar i komplexiteten som finns idag, syftar IBM® till att hjälpa dig att upptäcka strategier och målläge för att uppnå en sömlös och effektiv väg att implementera.

De bästa metoderna, verktygen och metoderna som gör det möjligt för organisationer att effektivisera sina pipelines för mjukvaruleverans, minska tiden till marknad, förbättra mjukvarukvaliteten och säkerställa robust verksamhet i produktionsmiljöer kommer alla att utforskas.

Andra inlägget i denna serie tillhandahåller en mognadsmodell och byggstenar för att hjälpa företag att accelerera sin mjukvaruförsörjningskedjas livscykel i det ständigt föränderliga landskapet av molnbaserad mjukvaruutveckling för företag.

Väg att implementera: Aktuell vy och utmaningar

Diagrammet nedan sammanfattar en bild av livscykeln för företagsmjukvaruutveckling (SDLC) med typiska grindar. Även om flödet är självförklarande, är nyckeln att förstå att det finns flera aspekter av mjukvaruförsörjningskedjan som gör detta till en kombination av vattenfall och intermittenta smidiga modeller. Utmaningen är att tidslinjen för att bygga ut en applikation (eller en iteration av den) påverkas av flera aktiviteter på första och sista milen som vanligtvis förblir manuella.

De viktigaste utmaningarna med den traditionella karaktären hos SDLC är:

1. Väntetid före utveckling på 4-8 veckor inom arkitektur och designfas för att komma till utveckling. Detta orsakas av:
   • Flera första milsrecensioner för att säkerställa att inga negativa konsekvenser för verksamheten, inklusive integritetsproblem, dataklassificering, affärskontinuitet och regelefterlevnad (och de flesta av dessa är manuella).
   • Företagsomfattande SDLC-processer som förblir vattenfall eller semi-agila, som kräver sekventiell exekvering, trots agila principer i utvecklingscykler (till exempel miljöprovisionering först efter fullständigt designgodkännande).
   • Ansökningar som uppfattas som "unika" är föremål för djup granskning och ingrepp med begränsade möjligheter till acceleration.
   • Utmaningar med att institutionalisera mönsterbaserad arkitektur och utveckling på grund av bristande sammanhållen ansträngning och förändringsagenter, sådan standardisering.
   • En säkerhetskultur som påverkar utvecklingshastigheten, med efterlevnad av säkerhetskontroller och riktlinjer som ofta involverar manuella eller halvmanuella processer.
2. Väntetid för utveckling till tillhandahållande av miljö och CI/CD/CT-verktygsintegration på grund av:
   • Manuell eller halvautomatiserad miljöprovisionering.
   • Mönster (på papper) endast som föreskrivande vägledning.
   • Fragmenterade DevOps-verktyg som kräver ansträngning att sy ihop.
3. Väntetiden efter utveckling (sista mil) innan start är lätt 6–8 veckor eller mer på grund av:
   • Manuell bevisinsamling för att gå igenom säkerhets- och efterlevnadsgranskningar utöver standard SAST/SCA/DAST (som säkerhetskonfiguration, dag 2-kontroller, taggning och mer).
   • Manuell bevisinsamling för drift- och resiliensgranskningar (som att stödja molndrift och affärskontinuitet).
   • Serviceövergångsgranskningar för att stödja IT-tjänster och incidenthantering och lösning.

Väg att distribuera: Måltillstånd

Vägen för att distribuera måltillstånd kräver en strömlinjeformad och effektiv process som minimerar flaskhalsar och påskyndar transformation av mjukvaruförsörjningskedjan. I detta idealiska tillstånd kännetecknas vägen till implementering av en sömlös integrering av design (first mile), såväl som utveckling, testning, plattformskonstruktion och implementeringsstadier (last mile), enligt agila och DevOps-principer. Detta hjälper till att påskynda distributionen av kodändringar snabbt och automatiskt med nödvändiga (automationsdrivna) valideringar till produktionsmiljöer.

IBMs vision om måltillstånd prioriterar säkerhet och efterlevnad genom att integrera säkerhetskontroller och efterlevnadsvalidering i CI/CD/CT-pipelinen, vilket möjliggör tidig upptäckt och lösning av sårbarheter. Denna vision betonar samarbete mellan utvecklings-, drift-, tillförlitlighets- och säkerhetsteam genom en modell för delat ansvar. Det etablerar också kontinuerlig övervakning och återkopplingsslingor för att samla in insikter för ytterligare förbättringar. I slutändan syftar målstaten till att leverera mjukvaruuppdateringar och nya funktioner till slutanvändare snabbt, med minimala manuella ingrepp och med en hög grad av förtroende för alla företagsintressenter.

Diagrammet nedan visar en potentiell målvy av väg att distribuera som hjälper till att omfatta den molnbaserade SDLC-modellen.

Nyckelelementen i den molnbaserade SDLC-modellen inkluderar:

• Mönsterdriven arkitektur och design institutionaliserad över hela företaget.
• Mönster som innehåller nyckelkrav för säkerhet, efterlevnad, motståndskraft och andra företagspolicyer (som kod).
• Säkerhets- och efterlevnadsgranskningar som accelereras som mönster och används för att beskriva lösningen.
• Kärnutveckling, inklusive skapandet av miljöer, pipelines och tjänstekonfigurationer (som drivs genom plattformskonstruktionsföretagskatalog).
• CI/CD/CT pipeline som bygger kopplingar till alla aktiviteter över hela vägen för att distribuera livscykeln.
• Plattformsteknik bygger-konfigurerar-hanterar plattformar och tjänster med alla företagspolicyer (som kryptering) inbäddade som plattformspolicyer.
• Säkerhets- och efterlevnadsverktyg (till exempel sårbarhetssökningar eller policykontroller) och automatisering som är integrerad i pipelines eller tillgänglig som självbetjäning.
• Generering av en hög grad av data (från loggar, verktygsutgångar och kodavsökningsinsikter) för flera granskningar utan manuell inblandning.
• Spårbarhet från eftersläpning till distributionsinformation och förändringseffekt.
• Ingripanden endast genom undantag.

Väg att implementera driver acceleration genom tydlighet, ansvarighet och spårbarhet

Genom att definiera en strukturerad väg att implementera kan organisationer standardisera stegen som är involverade i leveranskedjans livscykel, vilket säkerställer att varje fas är spårbar och granskbar. Detta gör det möjligt för intressenter att övervaka framstegen genom distinkta stadier, från initial design till implementering, vilket ger realtidsinsyn i programmets status. Att tilldela ägarskap i varje skede av implementeringsvägen säkerställer att teammedlemmarna är ansvariga för sina leveranser, vilket gör det lättare att spåra bidrag och förändringar, samt påskyndar problemlösning med rätt nivå av ingripande. Spårbarhet genom implementeringsvägen ger datadrivna insikter som hjälper till att förfina processer och förbättra effektiviteten i framtida program. En väldokumenterad väg att implementera stöder efterlevnad av branschföreskrifter och förenklar rapporteringen, eftersom varje del av processen är tydligt registrerad och återställbar.

Läs del 2: Utforska mognadsmodellen och realiseringsmetoden