Devops er nå viktig i mange teknologiorganisasjoner på grunn av to tilsynelatende motsatte oppdrag og kulturer som trenger å komme sammen:
- Agile utviklingsteam beveger seg raskt for å oppfylle forretningskravene og implementere applikasjonsendringer.
- Operasjonelle team jobber hardt for å opprettholde systemene, sikre at databehandlingsmiljøene er sikre og administrere databehandlingsressurser.
Agile team ser ofte på operasjonelle team som sakte og stive mens systemingeniører ser på smidige utviklere som ikke støtter driftsbehov og hensynsløs når applikasjonsutrullinger forårsaker produksjonsproblemer.
Dette er generaliseringer, men de to fagene har ofte forskjellige motivasjoner, terminologi og verktøy - og denne feiljusteringen kan skape forretningsproblemer. Når oppstart for eksempel blir større, må de utvikle operasjonelle prosedyrer for å sikre stabilitet mens de påvirker utviklingshastigheten og smidigheten deres minimalt. For store bedrifter må de finne måter å levere applikasjoner som vender mot kunder og forbedringer i intern arbeidsflyt raskere uten å gå på kompromiss med påliteligheten eller falle ut av samsvar.
Devops tar sikte på å adressere disse konfliktene med en kultur, et sett med driftsprinsipper, og et voksende sett med beste praksis som muliggjør hastigheten for distribusjon av applikasjoner og stabilitet, med mindre konflikter og kompromisser. Dette gjøres i stor grad ved å tilby praksis som automatiserer operasjonelle trinn og standardiserer konfigurasjoner:
- For utviklingsteam standardiserer og automatiserer denne fremgangsmåten trinn fra utvikling av kode til testing, sikring og kjøring av applikasjoner i flere miljøer.
- For operasjoner driver fremgangsmåtene automatisering i å konfigurere og distribuere infrastruktur, overvåking på tvers av flere domener og muliggjør løsning av produksjonsproblemer raskere.
Devops praksis inkluderer:
- Versjonskontroll og forgreningsstrategier.
- Kontinuerlig integrasjon og kontinuerlig levering (CI / CD) rørledninger.
- Beholdere som standardiserer og isolerer applikasjons kjøretidsmiljøer.
- Infrastructure as code (IAC), som muliggjør skripting av infrastrukturlaget.
- Overvåking av devops-rørledninger og helse for applikasjoner som kjører.
Devops begynner med praksis og verktøy som brukes for å gi ut programvare for å beregne miljøer med grunnleggende prosedyrer som har eksistert i flere tiår. De inkluderer versjonskontroll for å administrere kodeendringer på tvers av et team av utviklere, forgrening av kodebasen for å støtte forskjellige utviklingsaktiviteter, og versjonsmerking programvareutgivelser før de skyves inn i forskjellige miljøer.
Hovedforskjellene for devops-team er at verktøyene er enklere å bruke og integreres bedre med andre teknologier som automatiserer bygging og distribusjon av applikasjoner. Det er også mer standardiserte forgrenings- og kodesammenslåingsstrategier som er enklere å administrere med moderne versjonskontrollsystemer.
For eksempel bruker mange organisasjoner Git (inkludert GitHub- og BitBucket-versjoner) og andre versjonskontrollverktøy som tilbyr flere klientapplikasjoner, APIer for integrering og kommandolinjeverktøy for å administrere hyppigere eller komplekse prosedyrer. I dag har de fleste utviklere brukt minst en versjonskontrollteknologi i prosjektene sine, og implementering av standarder er ikke så vanskelig som før.
Organisasjoner som bruker disse verktøyene, kan vedta forgreningsstrategier som Gitflow som standardiserer filialer for produksjon, testing og utvikling og etablerer prosedyrer for å utvikle nye funksjoner eller produksjonsoppdateringer. Disse forgreningsstrategiene lar team samarbeide om forskjellige typer utviklingsbehov og kun introdusere kode som er testet og kan distribueres i produksjonsgrener. Teamene bruker deretter versjonstagging for å merke alle versjonene av kildekoden og andre filer som er en del av en programvareutgivelse.
De fleste organisasjoner som krever brukerstøtte etter produksjonsutgivelser, og andre som er tidlig ute med å utvikle sin devops-praksis, følger ofte tradisjonelle utgivelsesadministrasjonspraksiser som støtter konstruksjoner som større og mindre utgivelser. De mer sofistikerte teamene som utvikler applikasjoner som krever mindre brukerstøtte, kan øve kontinuerlig distribusjon når det er automatisering som kontinuerlig integrerer og leverer kodeendringer til produksjonsmiljøer.
For å muliggjøre hyppigere utgivelser, ser teamene ut til å automatisere trinnene fra å sjekke inn kode til å levere fullt testede applikasjoner til målgruppemiljøer. Kontinuerlig integrasjon (CI) er automatiseringen for å bygge og integrere alle programvarekomponentene slik at de er i en distribuerbar pakke. Kontinuerlig distribusjonsverktøy (CD) administrerer miljøspesifikke variabler og automatiserer push-applikasjoner til utvikling, test, produksjon og andre databehandlingsmiljøer. Sammen utgjør disse verktøyene CI / CD-rørledningen.
For at CI / CD skal være en effektiv automatiseringsprosess, må kontinuerlig testing implementeres i rørledningen for å sikre at ny kode ikke introduserer feil og andre problemer. Enhetstester implementert i den kontinuerlige integrasjonsrørledningen sikrer at den forpliktede koden ikke bryter noen eksisterende enhetstester. Andre tester som ser etter sikkerhetsproblemer på kodenivå og kodestruktur, kan også implementeres i integrasjonstrinnet. Automatisert funksjonalitet og ytelse som krever kjøretidsmiljøer blir ofte automatisert som en del av kontinuerlige leveringsrørledninger.
Denne automatiseringen driver mange gunstige atferds- og praksisendringer som gjør at teamene kan gjøre endringer oftere og tryggere. Det driver teamene til å sjekke inn og teste koden oftere, noe som lar feil bli funnet og løst raskere. Manuelle distribusjonsprosedyrer er utsatt for feil, noe som automatiseringen i stor grad eliminerer. Automatiseringen tar også det meste av overhead i å skyve nye muligheter til brukere, slik at team kan distribueres oftere.
Hvis CI / CD gir automatisering for å levere applikasjoner, er containere emballasjen til applikasjonens driftsmiljø. Utviklere kan spesifisere operativsystem, applikasjonskrav og konfigurasjonskrav som en beholder for å kjøre applikasjonene i et isolert lag som deler operativsystemet til verten. Docker og Kubernetes er containerteknologier som hjelper utviklere med å definere applikasjonsmiljøene sine på konsistente måter.
Med CI / CD-rørledninger for å integrere og distribuere kode og med standardiserte containere som isolerer databehandlingsbehovene til hvert program, har utviklerne verktøyene til å produsere applikasjonstjenester uten mye overhead. Utviklingsteam har da større muligheter for å oversette forretningskrav til mikrotjenester som kan distribueres, skaleres og utnyttes for flere forretningsbehov.
Siden automatisering av kodeintegrering og levering og containerisering av applikasjoner driver applikasjonslevering, hjelper neste devops-praksis å automatisere og standardisere infrastrukturen og skytjenestene.
Tidligere var det vanskelig å automatisere og administrere infrastruktur. Når en arkitektur ble valgt, gikk driftsingeniører til forskjellige infrastrukturkomponenter for å bygge og konfigurere dem i henhold til kravene. Konfigurasjons- og kapitaladministrasjonsverktøyene som ble brukt for å fange opp disse arkitekturene, krevde en blanding av automatiserte og manuelle trinn og var ofte utdaterte eller manglet viktig informasjon. Datamiljøer var også stive, og selv om det var noen verktøy for å automatisere skaleringsmiljøer, ble de ofte isolert til en bestemt infrastrukturtype, krevde forskjellige ferdigheter for å implementere automatiseringen, og hadde tilgang til bare en delmengde av operative data for å avgjøre om og hvordan å skalere.
Dagens skymiljøer tilbyr brukergrensesnitt som forenkler arbeidet for ingeniører. Ingeniører kan bruke disse verktøyene til å sette opp virtuelle private nettverk, konfigurere sikkerhetsgrupper og deretter starte beregning, lagring og andre nødvendige tjenester.
Men devops-team tar dette et skritt videre. I stedet for å bruke webgrensesnittene og manuelt konfigurere databehandlingsressurser, automatiserer de prosessen med kode. Infrastruktur som kode (IaC) -verktøy lar operasjonelle ingeniører skript og automatisere infrastrukturoppsett og administrasjon. Konfigurasjonene som muliggjør opp- og nedmiljøer kan også være innebygd i disse skriptene. Chef, Puppet, Ansible og Salt er fire konkurrerende teknologier som hjelper med å implementere operasjonelle team med å implementere IaC.
En produksjonsprosess er bare like god som muligheten til å overvåke, varsle og gjenopprette problemer. Det samme gjelder overvåking av devops og brukeropplevelsen av å kjøre applikasjoner og tjenester. Når organisasjoner investerer i automatisering, containerisering, standardisering og distribusjon av applikasjoner, er en parallell investering i overvåking en best praksis.
Tenk på overvåking på flere nivåer. På det laveste nivået er infrastrukturovervåking som gjør det mulig å gjenkjenne og svare når beregningsressursene ikke er sunne eller underpresterer. Skymiljøer i dag tilbyr muligheter for å overvåke, varsle og bruke elastiske skyegenskaper for å svare på infrastrukturproblemer.
Det neste laget består av verktøyene for å overvåke og fange beregninger rundt devops automatisering. Disse verktøyene blir mer kritiske etter hvert som antall utviklere og distribuerbare tjenester øker. Disse verktøyene gir varsler når bygg mislykkes og revisjonsverktøy for å diagnostisere problemer.
Til slutt er det verktøy som overvåker applikasjonens oppetid, ytelse og andre kjøretidsberegninger. Disse overvåkingsverktøyene tester ofte API-er og utfører også fullstendige nettlesertester på enten enkelt sluttpunkter eller flertrinnstransaksjoner. Disse skjermene er et frontlinjeforsvar for å varsle devops-team når API-er eller applikasjoner fungerer utenfor akseptable servicenivåer.
Det er mange devops praksis, og det tar alle tid å modnes og integreres. Det er ikke en foreskrevet rekkefølge for å implementere dem eller harde anbefalinger om hvor mye automatisering du skal investere i.
Likevel bør organisasjoner først se etter å tilpasse kulturen og tankegangen rundt devops-prinsippene, og deretter innse hvilken praksis som passer best med forretningsbehovet. For eksempel kan organisasjoner som allerede opplever dårlig applikasjonsytelse, velge å implementere overvåking først for å løse problemer raskere og identifisere grunnårsaker lettere. Andre organisasjoner som starter skymigrering, kan velge å distribuere infrastruktur som kode, mens de som etablerer standard applikasjonsutviklingsarkitekturer kan investere i CI / CD-rørledninger.
Teknologer bør huske at det koster å implementere automatisering, og at ikke alle organisasjoner krever kontinuerlig distribusjon. Den beste fremgangsmåten er å sørge for å oppfylle forretningsbehovet først og justere devops automatisering til områder med høy repetisjon der manuell innsats er utsatt for feil.
