DevOps-metodologien: Principper for succes | StackPulse

DevOps-metodologien fusionerer to områder – softwareudvikling og it-drift. DevOps-metodologiens primære mål er hurtig produktudgivelse, der opnås ved hjælp af automatisering, kommunikation og en kontinuerlig arbejdsgang.

DevOps’ vigtigste kerneprincipper er krydstræning, samarbejde, løbende forbedringer, ansvarlighed, gennemsigtighed og automatisering. DevOps-teams anvender disse principper, når de opretter en DevOps-proces, som typisk omfatter syv faser – planlægge, kode, bygge, teste, levere, implementere og overvåge.

I denne artikel lærer du:

  • Hvad er DevOps-metodologien?
  • 6 centrale DevOps-principper
  • Hvad er en DevOps-proces?
  • DevOps vs Agile: en sammenligning

Hvad er DevOps-metodologi?

DevOps-metodologien er et sæt praksisser, der kræver samarbejde mellem udviklings- og driftsteams i hele softwareudviklingslivscyklussen (SDLC). Den inkorporerer Agile-praksis og fokuserer på at nedbryde teamsiloer, automatisere manuelle opgaver og øge produktiviteten gennem løbende feedback.

Når organisationer anvender DevOps-teams, implementerer de ofte flere praksisser og værktøjer samtidig. Disse omfatter:

  • Kontinuerlig integration/kontinuerlig implementering (CI/CD) – et sæt processer, der udnytter automatisering til at forbedre effektiviteten, kvaliteten og hastigheden i softwareudviklingslivscyklusen. CI indebærer hyppige, små ændringer af kodebaser, der testes og integreres så hurtigt som muligt. CD indebærer hyppig frigivelse af ny kode til produktion uden behov for manuelle opdateringer eller patches.
  • Cloud-baserede pipelines – pipelines er de værktøjskæder, der bruges til at udføre arbejdsgange som CI/CD. Ofte er disse værktøjskæder opbygget af tjenester og ressourcer, der er hostet i skyen, hvilket giver mulighed for cloud-nativ udvikling og større understøttelse af distribuerede teams.
  • Microservices – en arkitektur, der anvendes med cloud-native applikationer for at muliggøre større skalerbarhed, tilgængelighed og fleksibilitet. Microservices gør det muligt for teams at opbygge applikationer og pipelines, der er løst koblede og nemme at ændre eller opdatere.
  • Infrastruktur som kode (IaaC)-en metode, der gør det muligt for teams at stille infrastruktur til rådighed, konfigurere og administrere via software og kodede definitionsfiler. Denne metode giver mulighed for automatisering af mange infrastrukturopgaver og understøtter massive implementeringer uden at kræve betydeligt flere teamressourcer.

De centrale DevOps-principper

Når du opretter og arbejder under en DevOps-metode, er der flere centrale principper, som du bør overveje at vedtage.

Krydsuddannelse

I DevOps gøres der en indsats for at krydstræne teammedlemmer i alle processer i SDLC’en. Det betyder ikke, at alle teammedlemmer skal være lige dygtige, men alle bør være bekendt med de processer, værktøjer og færdigheder, der anvendes.

Når teammedlemmernes viden overlapper hinanden på denne måde, er det lettere for teammedlemmerne at kommunikere. Det fremmer nye løsninger, da medlemmerne er mindre “fanget” af forventningerne til, hvordan tingene skal gøres. Krydstræning kan også forhindre flaskehalse på grund af afhængighed af andre, hvilket fremskynder produktiviteten.

Samarbejde

Samarbejde og den kommunikation, som det kræver, er nøgleelementer i DevOps. Denne metode er afhængig af, at teammedlemmerne arbejder gnidningsløst sammen og reagerer på feedback, når noget ikke fungerer som forventet. Hvis teammedlemmerne ikke er i stand til at samarbejde, bliver arbejdet siloedannet, og produktiviteten begrænses af færdiggørelsen af faser.

Kontinuerlig forbedring

DevOps anvender en iterativ proces med små ændringer, der forfines, indtil en ændring passerer inspektionstærskler. Så snart en ændring er accepteret, sættes den næste i gang med den næste. Denne løbende forbedring anvendes på alle aspekter af DevOps, herunder produktudvikling, pipelineydelse og proceseffektivitet.

Accountability

En DevOps-model kræver ansvarlighed for alle opgaver – uanset om det er udviklingsopgaver eller driftsopgaver – og begge dele bør være ligeligt ejet af alle medlemmer af organisationen. Dette eliminerer den traditionelle tankegang om “en andens problem” og er med til at sikre, at teams er omhyggelige i deres handlinger, uanset om de vedrører udvikling eller drift. Det er også med til at opbygge og befæste relationerne i et team, da alle medlemmer forventer samme indsats og ansvar.

Transparens

Transparens af processer, konfigurationer, værktøjer og forventninger er alle vigtige i DevOps. Uden gennemsigtighed kan teams ikke samarbejde effektivt, og der er fortsat en følelse af “os mod dem”. Dette forhindrer kommunikation og gør det svært at holde andre ansvarlige. Med gennemsigtighed kan alle teammedlemmer hjælpe med at identificere eventuelle problemer, der opstår, og kan foreslå forbedringer i sammenhæng med det overordnede billede.

Automatisering

DevOps Automation hjælper teams med at strømline og standardisere arbejdet. Det er også med til at skabe gennemsigtighed, da det kræver, at procedurer defineres og dokumenteres. Ved at automatisere kedelige eller tidskrævende opgaver kan DevOps-teams fokusere på arbejde på et højere niveau. Dette fokus kan forbedre kvaliteten og fremme innovation.

DevOps-processen

Selv om de enkelte procedurer inden for DevOps-processen kan variere, følger den overordnede proces et sæt af ret ensartede trin. Disse trin forekommer i en cyklus og kan ændres eller sløjfes tilbage til tidligere trin afhængigt af feedback loops. En DevOps-livscyklus omfatter typisk følgende trin:

  • Planlæg – i begyndelsen af et projekt, et sprint/iteration eller en dag planlægges og prioriteres arbejdet. Dette er med til at sikre, at alle teammedlemmer forstår de aktuelle mål, og definerer, hvilket arbejde der forventes.
  • Kode-udviklere opretter og indsender kodeændringer eller tilføjelser, der opfylder de opgaver, der er defineret for den aktuelle iteration. Disse er baseret på en masterkodebase, som alle udviklere har adgang til. Dette trin omfatter også kodegennemgang og eventuelle afklaringer eller justeringer, der er nødvendige. Når indsendt kode ikke består testen, sendes den tilbage til dette trin med henblik på ændring.
  • Build – indsendt kode kompileres, enhedstestes og pakkes. Dette er generelt det første automatiserede trin i CI/CD-pipelinen. Hvis et build mislykkes, sendes der feedback til udvikleren, og den indsendte ændring afvises. Hvis build’et er vellykket, sendes det videre til yderligere testning.
  • Test – vellykkede builds sendes igennem en række tests for at sikre funktionalitet, kvalitet og ofte sikkerhed. Ideelt set udføres de hurtigste eller mest kritiske tests først. På denne måde kan den oprindelige kodeændring returneres med feedback så hurtigt som muligt, hvis en test mislykkes, og indsatsen er ikke spildt. Hvis alle tests bestås, overgår buildet til levering, og ændringerne føjes til masterkodegrenen. Dette sikrer, at alle udviklere fortsat arbejder ud fra det samme grundlag.
  • Deliver – det sidst beståede build vedligeholdes og holdes til udrulning.
  • Deploy – et build kan udrulles til et testmiljø med henblik på yderligere testning, f.eks. brugeraccept. Eller den kan leveres til staging- eller produktionsmiljøer med henblik på frigivelse.
  • Overvågning – efter frigivelse overvåges versionerne for at identificere eventuelle problemer, der blev overset, og for at indsamle brugsdata, der kan anvendes til fremtidige forbedringer. Du kan få mere at vide om DevOps-overvågning i vores artikel: DevOps-overvågning:

DevOps vs. Agile: Hvad er forskellen, og hvordan er de relateret?

Når man taler om DevOps-metodologien, forbindes den ofte med Agile. Det giver mening, når man tænker på, at mange DevOps-teams anvender agile metoder. Desuden fokuserer begge metodologier på at forbedre hastighed, effektivitet og kvalitet. På trods af dette adskiller metodologierne sig dog fra hinanden, og den ene kræver ikke nødvendigvis den anden.

Kommunikation

I Agile metodologier er der fokus på kommunikation mellem teams og på at inddrage kunderne i hele projektprocessen. Ligeledes kommer den meste feedback i agile processer fra kunderne.

I DevOps er kommunikationen centreret på udviklere og drift. Kundefeedback spiller en rolle i planlægningstrinene og leveringstrinene, men er generelt ikke til stede i de mellemliggende trin. I stedet er holdene afhængige af feedback fra værktøj og andre teammedlemmer til at styre arbejdet.

Teamstruktur

Både Agile og DevOps prioriterer deling af færdigheder og krydstræning. DevOps har dog en tendens til at anvende disse færdigheder mere på kommunikation og samarbejde end på ansvar. I DevOps-teams er udviklere ansvarlige for kodeoprettelse, og test- og driftsteams (kaldet DevOps-teams) er ansvarlige for pipelinehåndtering, miljøkonfiguration og udrulning.

I modsætning hertil udvisker agile teams ofte grænserne mellem ansvarsområderne. I et agilt team opfordres alle til at påtage sig de opgaver, der er nødvendige, og rollerne er mindre adskilte. Som følge heraf har Agile tendens til at fungere bedre med mindre teams, mens DevOps er bedre til at tilvejebringe den struktur, der er nødvendig for større teams.

Tidsplanlægning

Agile metoder følger et sprint eller en tidsbegrænset iteration. Der udføres flere sprints, indtil et projekt er afsluttet, med specifikke opgaver og mål defineret i hvert sprint. Sprints og det forventede arbejde justeres ofte for at matche teamets output.

I DevOps-implementeringer er målet altid at have et produkt, der kan leveres. Teams kan dog bruge sprints eller iterationer til at definere det arbejde, der forventes at indgå i en specifik udgivelse. Derudover holdes DevOps-teams ofte til mere specifikke deadlines og benchmarks og har mindre fleksibilitet med hensyn til at definere, hvornår et produkt er færdigt.

Automatisering til DevOps-metodologien: Kontinuerlig drift, overvågning og feedback med StackPulse

Da vores virksomheder bliver mere og mere digitale, bliver pålideligheden af de softwaretjenester, der styrker dem, et forretningskritisk spørgsmål. Ethvert softwaresystem, uanset hvor veludviklet det er, vil have produktionsalarmer. Der vil enten være tale om lokale problemer, der har lille eller ingen indvirkning på slutbrugerne, eller kritiske problemer, der påvirker tjenestens tilgængelighed for brugerne.

I begge tilfælde bør problemerne undersøges, analyseres og om nødvendigt rettes af de relevante ejere. Uden ordentlig automatisering vil det store antal hændelser og alarmer i de fleste organisationer føre til:

  • Negativ produktivitetspåvirkning på R&D- og DevOps-teams
  • “Alert fatigue” for ejere og supportteams
  • Længere nedetid for produktionstjenester.

StackPulse er en automatiseringsplatform til drift, overvågning og feedback-faser i DevOps-cyklusen. Den giver DevOps- og ingeniørteams mulighed for at definere kodificerede playbooks for disse processer. Dette giver din organisation mulighed for at automatisere processer på en gentagelig og målbar måde og udløse dem så ofte som nødvendigt, uden yderligere manuelt arbejde.

Få tidlig adgang til StackPulse og vær blandt de første til at prøve vores DevOps / SRE automatiseringsplatform.

Leave a Reply