Devops er nu vigtigt i mange teknologiorganisationer på grund af to tilsyneladende modsatte missioner og kulturer, der skal samles:
- Agile udviklingsteam bevæger sig hurtigt for at imødekomme forretningskrav og implementere applikationsændringer.
- Operationelle teams arbejder hårdt på at holde systemer ude, sikre, at computermiljøer er sikre, og administrere computerressourcer.
Agile teams ser ofte operationelle teams som langsomme og stive, mens systemteknikere ser agile udviklere som ikke-understøttende af operationelle behov og hensynsløse, når applikationsinstallationer forårsager produktionsproblemer.
Disse er generaliseringer, men de to discipliner har ofte forskellige motiver, terminologi og værktøjer - og denne fejljustering kan skabe forretningsproblemer. Når startups f.eks. Bliver større, skal de udvikle operationelle procedurer for at sikre stabilitet, mens de minimalt påvirker deres udviklingshastighed og smidighed. For store virksomheder er de nødt til at finde måder til at levere kundeorienterede applikationer og interne workflowforbedringer hurtigere uden at gå på kompromis med pålideligheden eller falde ud af compliance.
Devops sigter mod at tackle disse konflikter med en kultur, et sæt driftsprincipper og et nye sæt af bedste praksis, der muliggør hastigheden af implementering af applikationer og stabilitet, der kører dem med færre konflikter og kompromiser. Dette gøres stort set ved at levere fremgangsmåder, der automatiserer operationelle trin og standardiserer konfigurationer:
- For udviklingshold standardiserer og automatiserer denne praksis trin fra udvikling af kode til test, sikring og kørsel af applikationer i flere miljøer.
- Til operationer driver fremgangsmåden automatisering i konfiguration og implementering af infrastruktur, overvågning på tværs af flere domæner og muliggør løsning af produktionsproblemer hurtigere.
Devops praksis inkluderer:
- Versionskontrol og forgreningsstrategier.
- Kontinuerlig integration og kontinuerlig levering (CI / CD) rørledninger.
- Beholdere, der standardiserer og isolerer applikations runtime-miljøer.
- Infrastruktur som kode (IAC), som muliggør scripting af infrastrukturlaget.
- Overvågning af devops-rørledninger og sundhed for kørende applikationer.
Devops begynder med de fremgangsmåder og værktøjer, der bruges til at frigive software til at beregne miljøer med grundlæggende procedurer, der har eksisteret i årtier. De inkluderer versionskontrol til at styre kodeændringer på tværs af et team af udviklere, forgrening af kodebasen for at understøtte forskellige udviklingsaktiviteter og versionstagging softwareudgivelser, før de skubbes ind i forskellige miljøer.
De vigtigste forskelle for devops-teams er, at værktøjerne er lettere at bruge og integreres bedre med andre teknologier, der automatiserer opbygning og implementering af applikationer. Der er også mere standardiserede forgrenings- og kodesammensætningsstrategier, der er lettere at administrere med moderne versionskontrolsystemer.
For eksempel bruger mange organisationer Git (inklusive GitHub- og BitBucket-versioner) og andre versionskontrolværktøjer, der tilbyder flere klientapplikationer, API'er til integration og kommandolinjeværktøjer til at styre hyppigere eller komplekse procedurer. I dag har de fleste udviklere brugt mindst en versionskontrolteknologi i deres projekter, og implementering af standarder er derfor ikke så hårdt som før.
Organisationer, der bruger disse værktøjer, kan vedtage forgreningsstrategier som Gitflow, der standardiserer filialer til produktion, test og udvikling og fastlægger procedurer til udvikling af nye funktioner eller produktionsrettelser. Disse forgreningsstrategier lader hold samarbejde om forskellige typer udviklingsbehov og introducerer kun kode, der testes og implementeres i produktionsgrene. Hold bruger derefter versionstagging til at mærke alle versionerne af kildekoden og andre filer, der er en del af en softwareudgivelse.
De fleste organisationer, der har brug for brugersupport efter produktionsudgivelser, og andre, der er tidligt i at udvikle deres devops-praksis, følger ofte traditionelle frigørelsesadministrationspraksis, der understøtter konstruktioner som større og mindre udgivelser. De mere sofistikerede teams, der udvikler applikationer, der kræver mindre brugerstøtte, kan øve kontinuerlig implementering, når der er automatisering, der kontinuerligt integrerer og leverer kodeændringer til produktionsmiljøer.
For at muliggøre hyppigere udgivelser ser holdene ud til at automatisere trinnene fra at kontrollere kode til at levere fuldt testede applikationer til målgrupper. Kontinuerlig integration (CI) er automatiseringen til at opbygge og integrere alle softwarekomponenter, så de er i en implementerbar pakke. Kontinuerlig implementeringsværktøjer (CD) styrer miljøspecifikke variabler og automatiserer skubbe applikationer til udvikling, test, produktion og andre computermiljøer. Sammen udgør disse værktøjer CI / CD-pipelinen.
For at CI / CD skal være en effektiv automatiseringsproces, skal der implementeres kontinuerlig test i pipelinen for at sikre, at ny kode ikke introducerer fejl og andre problemer. Enhedstest implementeret i den kontinuerlige integrationsrørledning sikrer, at den forpligtede kode ikke bryder nogen eksisterende enhedstest. Andre tests, der ser efter sikkerhedsspørgsmål på kodeniveau og kodestruktur, kan også implementeres i integrationstrinnet. Automatiseret funktion og ydeevne, der kræver runtime-miljøer, automatiseres ofte som en del af kontinuerlige leveringsrørledninger.
Denne automatisering driver mange gavnlige adfærds- og praksisændringer, der gør det muligt for teams at foretage ændringer oftere og mere sikkert. Det driver hold til at tjekke ind og teste kode oftere, hvilket gør det muligt at finde og løse mangler hurtigere. Manuel implementeringsprocedurer er udsat for fejl, hvilket automatiseringen stort set eliminerer. Automatiseringen tager også det meste af omkostningerne ved at skubbe nye kapaciteter til brugerne, så teams kan implementere oftere.
Hvis CI / CD leverer automatisering til at levere applikationer, er containere emballagen til applikationens driftsmiljø. Udviklere kan specificere operativsystem, applikationskrav og konfigurationskrav som en container til at køre applikationerne i et isoleret lag, der deler operativsystemets vært. Docker og Kubernetes er containerteknologier, der hjælper udviklere med at definere deres applikationsmiljøer på ensartede måder.
Med CI / CD-rørledninger til at integrere og implementere kode og med standardiserede containere, der isolerer hver applikations computerbehov, har udviklere værktøjerne til at fremstille applikationstjenester uden meget overhead. Udviklingsteam har derefter større muligheder for at oversætte forretningskrav til mikroservices, der kan implementeres, skaleres og geares til flere forretningsbehov.
Da automatisering af kodeintegration og levering og containerisering af applikationer driver applikationslevering, hjælper den næste devops-praksis med at automatisere og standardisere infrastrukturen og cloudtjenesterne.
Tidligere var det vanskeligt at automatisere og administrere infrastruktur. Når en arkitektur blev valgt, gik driftsingeniører til forskellige infrastrukturkomponenter for at bygge og konfigurere dem i henhold til kravene. Konfigurations- og aktivstyringsværktøjerne, der blev brugt til at indfange disse arkitekturer, krævede en blanding af automatiserede og manuelle trin og var ofte forældede eller manglede kritisk information. Computemiljøer var også stive, og selvom der var nogle værktøjer til at automatisere skaleringsmiljøer, blev de ofte isoleret til en bestemt infrastrukturtype, krævede forskellige færdigheder for at implementere automatiseringen og havde kun adgang til en delmængde af operationelle data for at afgøre, om og hvordan at skalere.
Dagens skymiljøer tilbyder brugergrænseflader, der forenkler arbejdet for ingeniører. Ingeniører kan bruge disse værktøjer til at oprette virtuelle private netværk, konfigurere sikkerhedsgrupper og derefter starte beregning, opbevaring og andre nødvendige tjenester.
Men devops-hold tager dette et skridt videre. I stedet for at bruge webgrænsefladerne og manuelt konfigurere computerressourcer automatiserer de processen med kode. Infrastruktur som kode (IaC) -værktøjer lader operationelle ingeniører script og automatisere opsætning og styring af infrastrukturen. De konfigurationer, der muliggør skalering op og ned i miljøer, kan også integreres i disse scripts. Chef, Puppet, Ansible og Salt er fire konkurrerende teknologier, der hjælper med at implementere operationelle teams med at implementere IaC.
En fremstillingsproces er kun så god som evnen til at overvåge, advare og komme sig efter problemer. Det samme gælder for overvågning af devops og brugeroplevelsen af at køre applikationer og tjenester. Da organisationer investerer i automatisering, containerisering, standardisering og implementering af applikationer, er en parallel investering i overvågning en bedste praksis.
Tænk på overvågning på flere niveauer. På det laveste niveau er infrastrukturovervågningen, der muliggør genkendelse og svar, når beregningsressourcer ikke er sunde eller underpresterende. Cloud-miljøer tilbyder i dag muligheder for at overvåge, advare og bruge elastiske cloud-funktioner til at reagere på infrastrukturproblemer.
Det næste lag består af værktøjerne til at overvåge og fange målinger omkring devops automatisering. Disse værktøjer bliver mere kritiske, efterhånden som antallet af udviklere og implementerbare tjenester øges. Disse værktøjer giver advarsler, når konstruktioner mislykkes, og kontrolværktøjer til at hjælpe med at diagnosticere problemer.
Til sidst er der værktøjer, der overvåger applikationens oppetid, ydeevne og andre runtime-metrics. Disse overvågningsværktøjer tester ofte API'er og udfører også fulde browsertests på enten enkelt slutpunkter eller transaktioner med flere trin. Disse skærme er et frontlinjeforsvar, der advarer devops-hold, når API'er eller applikationer fungerer uden for acceptabelt serviceniveau.
Der er mange devops praksis, og de tager alle tid til at modnes og integreres. Der er ikke en foreskrevet rækkefølge til implementering af dem eller hårde anbefalinger om, hvor meget automatisering man skal investere i.
Alligevel skal organisationer først se på at tilpasse kulturen og tankegangen omkring devops-principper og derefter erkende, hvilken praksis der bedst passer til forretningsbehovet. For eksempel kan organisationer, der allerede oplever dårlig applikationsydelse, vælge at implementere overvågning først for at hjælpe med at løse problemer hurtigere og identificere grundårsager lettere. Andre organisationer, der starter cloudmigrationer, kan vælge at implementere infrastruktur som kode, mens de, der etablerer standardarkitekturer til applikationsudvikling, kan investere i CI / CD-rørledninger.
Teknologer skal huske på, at der er omkostninger ved implementering af automatisering, og at ikke alle organisationer kræver kontinuerlig implementering. Den bedste praksis er at sørge for først at imødekomme forretningsbehov og tilpasse devops-automatisering til områder med høj gentagelse, hvor manuel indsats er udsat for fejl.
