DevOps ( en akronym för utveckling och drift ) är en metod för att automatisera de tekniska processerna för att bygga, konfigurera och distribuera programvara. Metodiken innebär ett aktivt samspel mellan utvecklingsspecialister och specialister inom informationsteknologitjänster och ömsesidig integration av deras tekniska processer i varandra för att säkerställa mjukvaruproduktens höga kvalitet . Designad för effektiv organisation av skapande och uppdatering av mjukvaruprodukter och tjänster. Den är baserad på idén om ett nära ömsesidigt beroende av produktskapande och mjukvarudrift, vilket ingjuts i teamet som en produktskapande kultur.
Organisationer som behöver frekventa programutgåvor kan behöva DevOps, d.v.s. automatisering av tekniska processer för montering, konfiguration och distribution av programvara. Den dagliga cykeln av mjukvarusläpp kan vara mycket mer intensiv för organisationer som släpper flera olika applikationer.
Metodiken fokuserar på standardisering av utvecklingsmiljöer för att snabbt flytta mjukvara genom stadierna av mjukvarans livscykel, vilket underlättar en snabb utgivning av programvaruversioner. Helst bör bygga och släppa automationssystem vara tillgängliga för alla utvecklare i alla miljöer, och utvecklare bör ha kontroll över utvecklingsmiljön, och IT-infrastrukturen bör bli mer applikationsfokuserad.
Ingenjörernas uppgift för att automatisera de tekniska processerna för att bygga, konfigurera och distribuera programvara (DevOps-ingenjörer) är att göra processerna för att utveckla och leverera mjukvara överensstämmande med verksamheten, kombinera dem till en helhet med hjälp av automationsverktyg.
Rörelsen att automatisera de tekniska processerna för att bygga, konfigurera och distribuera programvara (DevOps-movement) uppstod 2009 och var utformad för att lösa problemen med interaktion mellan mjukvaruutveckling och driftteam. Samma år anordnades en serie DevOps Days [1] [2] konferenser i Belgien . Sedan hölls "DevOps-dagar" i olika städer och länder i världen.
Ursprunget till det som har blivit moderna DevOps, inklusive några standardprinciper som byggautomation och testning, kontinuerlig integration och kontinuerlig leverans , har sitt ursprung i Agile -världen , som (inofficiellt) går tillbaka till 1990-talet och formellt 2001. Utvecklingsteam som använder metoder som Extreme Programming skulle inte kunna "tillgodose kundens behov genom regelbunden och tidig leverans av värdefull programvara" [3] om dessa metoder inte inkluderade ansvaret för att sätta upp verksamheten och underhålla infrastrukturen för applikationen utvecklas (på det mest automatiserade sättet). När Scrum blev det dominerande agila ramverket i början av 2000-talet och saknade de ingenjörsrutiner som var en del av många Agile-team, splittrades rörelsen för infrastrukturdrift/funktionsautomatisering från Agile och expanderade till vad som har blivit moderna DevOps. DevOps fokuserar idag på att distribuera utvecklad mjukvara, oavsett om den är utvecklad med agila eller andra metoder.
Så, indirekt, föddes behovet av DevOps från den växande populariteten för den agila utvecklingsmetoden , eftersom det ledde till fler releaser.
Eftersom DevOps är en laginsats (mellan Dev, Operations och Test), finns det inget enskilt "DevOps"-verktyg: det är mer en uppsättning (eller "DevOps-verktygskedja") med flera verktyg. Vanligtvis passar DevOps-verktyg in i en eller flera av dessa kategorier, vilket återspeglar nyckelaspekter av mjukvaruutveckling och leverans: [4]
Även om det finns många tillgängliga verktyg, är vissa kategorier av verktyg särskilt viktiga för att anpassa DevOps-verktyg för användning i en organisation. Vissa försök att identifiera dessa grundläggande verktyg finns i den befintliga litteraturen [5] .
Verktyg som containeriseringshantering ( Docker , Kubernetes ), kontinuerlig integration ( Jenkins , GitLab ), distribution av mallmiljöer ( Puppet , Ansible , Terraform ) och många andra används ofta och nämns ofta i diskussioner om DevOps-verktyg [6] .
Kontinuerlig leverans och DevOps har liknande betydelse (och ofta kombinerade), men de är två olika koncept:
DevOps tillämpas i en bredare mening och är centrerad kring:
Kontinuerlig leverans är ett tillvägagångssätt för att automatisera leveransaspekten som fokuserar på:
De delar gemensamma slutmål och används ofta tillsammans för att uppnå dem. DevOps och Continuous Delivery använder agila metoder: små och snabba förändringar med ett riktat resultat för slutkunden.
De specifika DevOps-målen täcker hela mjukvaruleveransprocessen. Dessa inkluderar:
DevOps-praxis gör enkla processer mer programmerbara och dynamiska. Med DevOps kan du maximera förutsägbarheten, effektiviteten, säkerheten och underhållsbarheten för operativa processer.
DevOps-integration är designad för produktleverans, kontinuerlig testning, kvalitetstestning, funktionsutveckling och underhållsuppdateringar för att förbättra tillförlitlighet och säkerhet och ge en snabbare utvecklings- och distributionscykel. [åtta]
DevOps ger en organisation fördelarna med hantering av programutgåvor genom att standardisera utvecklingsmiljön. Händelser kan spåras lättare och dokumenterade hanteringsprocesser och detaljerade rapporter kan aktiveras. DevOps-metoden ger utvecklare mer kontroll över miljön genom att ge infrastrukturen en mer applikationscentrerad förståelse.
Företag som använder DevOps har rapporterat betydande fördelar, inklusive: avsevärt kortare tid till marknaden, förbättrad kundnöjdhet, förbättrad produktkvalitet, mer tillförlitliga releaser, ökad produktivitet och effektivitet samt ökad förmåga att bygga rätt produkt genom snabba experiment. [åtta]
En studie som släpptes i januari 2017 av F5 Labs, baserad på en undersökning av nästan 2 200 IT-chefer och branschfolk, fann dock att endast en av fem tillfrågade tror att DevOps har en strategisk inverkan på deras organisation, trots ökad användning. Samma studie fann att endast 17 % identifierade DevOps som ett nyckelverktyg. [9]
För att kunna använda DevOps effektivt måste applikationer uppfylla en uppsättning arkitektoniskt signifikanta krav (ASR), såsom: utplacerbarhet, föränderlighet, testbarhet och övervakningsmöjligheter.
Medan DevOps i princip kan användas med vilken arkitektonisk stil som helst, håller mikroservicestilen på att bli standarden för att bygga ihärdigt.[ förtydliga ] system. Eftersom storleken på varje tjänst är liten blir det möjligt att förändra varje enskild tjänst genom kontinuerlig refactoring, vilket minskar behovet av stor upfront-design och möjliggör att mjukvara släpps i ett tidigt skede kontinuerligt.
GitOps utvecklades från DevOps [10] [11] [12] . Under detta tillvägagångssätt är det specifika tillståndet för konfigurationen bestämt till Git som gav tillvägagångssättet dess namn. I teorin kan ett annat versionskontrollsystem användas istället för Git , men i praktiken är det nästan alltid Git. Genom att använda ett versionskontrollsystem kan du tillämpa rutiner för kodgranskning och återställa konfigurationen.