Akselerer utgivelseslivssyklusen med distribusjonsvei: Del 1 – IBM Blog

For mange virksomheter reduserer reisen til skyen tekniske gjeldskostnader og møter CapEx-til-OpEx mål. Dette inkluderer rearkitekting til microservices, løft-og-skift, replattforming, refaktorisering, utskifting og mer. Som praksis som DevOps, sky innfødte, server og site reliability engineering (SRE) moden, skifter fokuset mot betydelige nivåer av automatisering, hastighet, smidighet og forretningstilpasning til IT (som hjelper bedrifts-IT med å transformere seg til ingeniørorganisasjoner).

Mange bedrifter sliter med å hente reell verdi fra sine skyreiser og kan fortsette å bruke overforbruk. Flere analytikere har rapportert at over 90 % av bedriftene fortsetter å bruke overforbruk i skyen, ofte uten å realisere betydelig avkastning.

Den sanne essensen av verdi dukker opp når virksomhet og IT kan samarbeide for å skape nye evner i høy hastighet, noe som resulterer i høyere utviklerproduktivitet og hastighet til markedet. Disse målene krever en måldriftsmodell. Rask distribusjon av applikasjoner til skyen krever ikke bare utviklingsakselerasjon med kontinuerlig integrasjon, distribusjon og testing (CI/CD/CT), det krever også livssyklusakselerasjon i forsyningskjeden, som involverer flere andre grupper som styringsrisiko og overholdelse (GRC), endringsledelse , drift, robusthet og pålitelighet. Bedrifter leter kontinuerlig etter måter som gjør produktteam i stand til å gå fra konsept til implementering raskere enn noen gang.

Automatisering først og DevSecOps-ledet tilnærming

Bedrifter ettermonterer ofte skytransformasjonselementer innenfor eksisterende applikasjonsforsyningskjedeprosesser i stedet for å vurdere nye livssyklus- og leveringsmodeller som er egnet for hastighet og skala. Bedriftene som reimaginerer applikasjonens livssyklus gjennom en automatisering-først-tilnærming oppmuntrer til en ingeniørdrevet produktlivssyklusakselerasjon som realiserer potensialet i skytransformasjon. Eksempler inkluderer:

• Mønsterbasert arkitektur som standardiserer arkitektur- og designprosessen (mens team har autonomi til å velge mønstre og teknologi eller samskape nye mønstre).
• Mønstre som adresserer sikkerhets- og samsvarsdimensjoner, og sikrer sporbarhet til disse kravene.
• Mønstre-som-kode som hjelper til med å kodifisere flere tverrgående bekymringer (dette fremmer også den indre kildemodellen for mønstermodenhet og gjenbrukbarhet).
• DevOps pipeline-drevne aktiviteter som kan brukes over hele livssyklusen.
• Automatisk generering av spesifikke data som trengs for gjennomgang av sikkerhet og samsvar.
• Driftsberedskapsgjennomganger med begrenset eller ingen manuell intervensjon.

Ettersom bedrifter omfavner cloud native og alt som kode, har reisen fra kode til produksjon blitt et kritisk aspekt for å levere verdi til kundene. Denne intrikate prosessen, ofte referert til som "vei å distribuere", omfatter en rekke intrikate trinn og beslutninger som kan påvirke en organisasjons evne til å levere programvare effektivt, pålitelig og i stor skala betydelig. Fra arkitektur, design, kodeutvikling, testing til implementering og overvåking, hvert trinn i distribusjonsveien byr på unike utfordringer og muligheter. Når du navigerer i kompleksiteten som eksisterer i dag, har IBM® som mål å hjelpe deg med å avdekke strategier og måltilstandsmodus for å oppnå en sømløs og effektiv distribusjonsvei.

De beste fremgangsmåtene, verktøyene og metodene som gir organisasjoner mulighet til å strømlinjeforme programvareleveringspipelines, redusere time-to-market, forbedre programvarekvaliteten og sikre robust drift i produksjonsmiljøer, vil alle bli utforsket.

Det andre innlegget i denne serien gir en modenhetsmodell og byggeklosser for å hjelpe bedrifter med å akselerere livssyklusen for programvareforsyningskjeden i det stadig utviklende landskapet med skybasert programvareutvikling for bedrifter.

Vei til distribusjon: Gjeldende visning og utfordringer

Diagrammet nedenfor oppsummerer en oversikt over livssyklusen for utvikling av bedriftsprogramvare (SDLC) med typiske porter. Selv om flyten er selvforklarende, er nøkkelen å forstå at det er flere aspekter av programvareforsyningskjeden som gjør dette til en kombinasjon av fossefall og intermitterende smidige modeller. Utfordringen er at tidslinjen for bygge-distribusjon av en applikasjon (eller en iterasjon av den) påvirkes av flere første og siste mile aktiviteter som vanligvis forblir manuelle.

De viktigste utfordringene med den tradisjonelle karakteren til SDLC er:

1. Ventetid før utbygging på 4-8 uker innen arkitektur og designfase for å komme til utvikling. Dette er forårsaket av:
   • Flere første mile-gjennomganger for å sikre at ingen negative forretningsmessige konsekvenser, inkludert personvernhensyn, dataklassifisering, forretningskontinuitet og regeloverholdelse (og de fleste av disse er manuelle).
   • Enterprise-wide SDLC-prosesser som forblir vannfall eller semi-agile, som krever sekvensiell utførelse, til tross for smidige prinsipper i utviklingssykluser (for eksempel miljøprovisionering først etter full designgodkjenning).
   • Søknader som oppfattes som «unike» er gjenstand for dyp gransking og inngrep med begrensede muligheter for akselerasjon.
   • Utfordringer med å institusjonalisere mønsterbasert arkitektur og utvikling på grunn av manglende helhetlig innsats og endringsagentdrift, slik standardisering.
   • En sikkerhetskultur som påvirker utviklingshastigheten, med overholdelse av sikkerhetskontroller og retningslinjer som ofte involverer manuelle eller semi-manuelle prosesser.
2. Utviklingsventetid til leveringsmiljø og CI/CD/CT-verktøyintegrasjon på grunn av:
   • Manuell eller semi-automatisert miljøklargjøring.
   • Mønstre (på papir) kun som foreskrivende veiledning.
   • Fragmentert DevOps-verktøy som krever innsats for å sy sammen.
3. Ventetiden etter utvikling (siste mil) før start er lett 6–8 uker eller mer på grunn av:
   • Manuell bevisinnsamling for å komme gjennom sikkerhets- og samsvarsgjennomganger utover standard SAST/SCA/DAST (som sikkerhetskonfigurasjon, dag 2-kontroller, tagging og mer).
   • Manuell bevisinnsamling for gjennomgang av drift og motstandskraft (som støtte for skydrift og forretningskontinuitet).
   • Tjenesteovergangsgjennomganger for å støtte IT-tjenester og hendelseshåndtering og løsning.

Vei til distribusjon: Måltilstand

Veien for å distribuere måltilstand krever en strømlinjeformet og effektiv prosess som minimerer flaskehalser og akselererer transformasjon av programvareforsyningskjeden. I denne ideelle tilstanden er veien til distribusjon preget av en sømløs integrasjon av design (first mile), samt utvikling, testing, plattformutvikling og distribusjonsstadier (last mile), etter smidighet og DevOps-prinsipper. Dette hjelper til med å akselerere distribusjon av kodeendringer raskt og automatisk med nødvendige (automatiseringsdrevne) valideringer til produksjonsmiljøer.

IBMs visjon om måltilstand prioriterer sikkerhet og samsvar ved å integrere sikkerhetssjekker og samsvarsvalidering i CI/CD/CT-pipelinen, noe som muliggjør tidlig oppdagelse og løsning av sårbarheter. Denne visjonen legger vekt på samarbeid mellom utviklings-, drift-, pålitelighets- og sikkerhetsteam gjennom en delt ansvarsmodell. Den etablerer også kontinuerlig overvåking og tilbakemeldingssløyfer for å samle inn innsikt for ytterligere forbedring. Til syvende og sist har målstaten som mål å levere programvareoppdateringer og nye funksjoner til sluttbrukere raskt, med minimal manuell intervensjon og med høy grad av tillit for alle bedriftsinteressenter.

Diagrammet nedenfor viser en potensiell målvisning av ruten for distribusjon som hjelper til med å omfavne den skybaserte SDLC-modellen.

Nøkkelelementer i den skybaserte SDLC-modellen inkluderer:

• Mønsterdrevet arkitektur og design institusjonalisert på tvers av bedriften.
• Mønstre som inkorporerer nøkkelkrav til sikkerhet, overholdelse, robusthet og andre bedriftspolicyer (som kode).
• Sikkerhets- og samsvarsgjennomganger som akselereres som mønstre og brukes til å beskrive løsningen.
• Kjerneutvikling, inkludert opprettelse av miljøer, rørledninger og tjenestekonfigurasjon (som er drevet gjennom plattformkonstruksjonsbedriftskatalog).
• CI/CD/CT-pipeline som bygger koblinger til alle aktiviteter på tvers av veien for å distribuere livssyklus.
• Plattformteknikk bygger-konfigurerer-administrerer plattformer og tjenester med alle bedriftspolicyer (som kryptering) innebygd som plattformpolicyer.
• Sikkerhets- og samsvarsverktøy (for eksempel sårbarhetsskanninger eller policysjekker) og automatisering som er integrert i rørledningene eller tilgjengelig som selvbetjening.
• Generering av høy grad av data (fra logger, verktøyutganger og kodeskanningsinnsikt) for flere gjennomganger uten manuell intervensjon.
• Sporbarhet fra etterslep til utgivelsesnotater for distribusjon og endringseffekt.
• Inngrep kun ved unntak.

Veien til distribusjon driver akselerasjon gjennom klarhet, ansvarlighet og sporbarhet

Ved å definere en strukturert vei å distribuere, kan organisasjoner standardisere trinnene som er involvert i forsyningskjedens livssyklus, og sikre at hver fase er sporbar og reviderbar. Dette lar interessenter overvåke fremdriften gjennom forskjellige stadier, fra første utforming til utrulling, og gir sanntidssynlighet til programmets status. Å tildele eierskap på hvert trinn i distribusjonsveien sikrer at teammedlemmene er ansvarlige for leveransene sine, noe som gjør det enklere å spore bidrag og endringer, samt akselerere problemløsning med riktig intervensjonsnivå. Sporbarhet gjennom distribusjonsveien gir datadrevet innsikt, som bidrar til å avgrense prosesser og forbedre effektiviteten i fremtidige programmer. En godt dokumentert vei for å distribuere støtter samsvar med bransjeforskrifter og forenkler rapportering, ettersom hver del av prosessen er tydelig registrert og gjenfinnbar.

Les del 2: Utforsking av modenhetsmodellen og realiseringstilnærmingen