Devops bästa praxis: De 5 metoderna du bör använda

Devops är nu viktigt i många teknikorganisationer på grund av två till synes motsatta uppdrag och kulturer som måste samlas:

  • Agila utvecklingsteam rör sig snabbt för att möta företagets krav och implementera applikationsändringar.
  • Operativa team arbetar hårt för att system ska fungera, se till att datormiljöer är säkra och hantera datorresurser.

Agila team ser ofta operativa team som långsamma och styva medan systemingenjörer ser agila utvecklare som inte stödjer operativa behov och hänsynslösa när applikationsdistributioner orsakar produktionsproblem.

Det här är generaliseringar, men de två disciplinerna har ofta olika motiv, terminologi och verktyg - och denna feljustering kan skapa affärsproblem. När startups till exempel blir större måste de utveckla operativa förfaranden för att säkerställa stabilitet samtidigt som de påverkar deras utvecklingshastighet och smidighet minimalt. För stora företag måste de hitta sätt att leverera kundinriktade applikationer och interna arbetsflödesförbättringar snabbare utan att kompromissa med tillförlitligheten eller inte följa kraven.

Devops syftar till att ta itu med dessa konflikter med en kultur, en uppsättning funktionsprinciper och en framväxande uppsättning bästa praxis som möjliggör snabb användning av applikationer och stabilitet med mindre konflikter och kompromisser. Detta görs till stor del genom att tillhandahålla metoder som automatiserar driftssteg och standardiserar konfigurationer:

  • För utvecklingsteam standardiserar och automatiserar dessa metoder steg från att utveckla kod till att testa, säkra och köra applikationer i flera miljöer.
  • För operationer driver metoderna automatisering vid konfigurering och distribution av infrastruktur, övervakning över flera domäner och möjliggör lösning av produktionsproblem snabbare.

Devops-metoder inkluderar:

  • Strategier för versionskontroll och förgrening.
  • Kontinuerlig integration och kontinuerlig leverans (CI / CD) -rörledningar.
  • Behållare som standardiserar och isolerar applikations runtime-miljöer.
  • Infrastruktur som kod (IAC), vilket möjliggör skriptning av infrastrukturlagret.
  • Övervakning av devops-rörledningar och hälsa för körande applikationer.

Devops börjar med de metoder och verktyg som används för att släppa programvara för att beräkna miljöer med grundläggande procedurer som har funnits i årtionden. De inkluderar versionskontroll för att hantera kodändringar i ett team av utvecklare, förgrena sig kodbasen för att stödja olika utvecklingsaktiviteter och versionmärkning av programvaruversioner innan de trycks in i olika miljöer.

De viktigaste skillnaderna för devops-team är att verktygen är lättare att använda och integreras bättre med andra tekniker som automatiserar att bygga och distribuera applikationer. Det finns också mer standardiserade förgrenings- och kodsammanfogningsstrategier som är lättare att hantera med moderna versionskontrollsystem.

Till exempel använder många organisationer Git (inklusive GitHub- och BitBucket-versioner) och andra versionskontrollverktyg som erbjuder flera klientapplikationer, API: er för integration och kommandoradsverktyg för att hantera mer frekventa eller komplexa procedurer. Idag har de flesta utvecklare använt minst en versionskontrollteknik i sina projekt och implementering av standarder är därför inte lika svårt som det brukade vara.

Organisationer som använder dessa verktyg kan anta förgreningsstrategier som Gitflow som standardiserar filialer för produktion, testning och utveckling och fastställer förfaranden för att utveckla nya funktioner eller produktionsfixar. Dessa förgreningsstrategier låter team samarbeta om olika typer av utvecklingsbehov och bara införa kod som testas och distribueras i produktionsgrenar. Team använder sedan versionstaggning för att märka alla versioner av källkoden och andra filer som ingår i en programversion.

De flesta organisationer som behöver användarsupport efter produktionsreleaser och andra som är tidigt i att utveckla sin devops-praxis följer ofta traditionella release-management-metoder som stöder konstruktioner som större och mindre versioner. De mer sofistikerade team som utvecklar applikationer som kräver mindre användarstöd kan öva kontinuerlig distribution när det finns automatisering som kontinuerligt integrerar och levererar kodändringar till produktionsmiljöer.

För att möjliggöra mer frekventa utgåvor, ser teamen till att automatisera stegen från att checka in kod till att leverera helt testade applikationer till måldatormiljöer. Kontinuerlig integration (CI) är automatiseringen för att bygga och integrera alla programvarukomponenter så att de finns i ett distribuerbart paket. Kontinuerlig distributionsverktyg (CD) hanterar miljöspecifika variabler och automatiserar applikationer för utveckling, test, produktion och andra datormiljöer. Tillsammans bildar dessa verktyg CI / CD-pipelinen.

För att CI / CD ska vara en effektiv automatiseringsprocess måste kontinuerlig testning genomföras i rörledningen för att säkerställa att ny kod inte introducerar defekter och andra problem. Enhetstester implementerade i den kontinuerliga integrationsrörledningen säkerställer att den kod som begås inte bryter mot några befintliga enhetstester. Andra tester som söker efter säkerhetsfrågor på kodnivå och kodstruktur kan också implementeras i integrationssteget. Automatiserad funktion och prestanda som kräver runtime-miljöer automatiseras ofta som en del av kontinuerliga leveransrörledningar.

Denna automatisering driver många fördelaktiga beteendemässiga och övningsändringar som gör det möjligt för team att göra förändringar oftare och säkrare. Det driver team att checka in och testa kod oftare, vilket gör att defekter kan hittas och lösas snabbare. Manuella distributionsprocedurer är felbenägna, vilket automatiseringen till stor del eliminerar. Automatiseringen tar också större delen av omkostnaderna för att skicka nya funktioner till användarna, vilket låter team distribuera oftare.

Om CI / CD tillhandahåller automatisering för att leverera applikationer är behållare förpackningen för programmets operativmiljö. Utvecklare kan ange operativsystem, applikationskrav och konfigurationskrav som en behållare för att köra applikationerna i ett isolerat lager som delar värdens operativsystem. Docker och Kubernetes är containerteknologier som hjälper utvecklare att definiera sina applikationsmiljöer på konsekventa sätt.

Med CI / CD-rörledningar för att integrera och distribuera kod och med standardiserade behållare som isolerar varje applikations datorbehov har utvecklare verktygen för att tillverka applikationstjänster utan mycket omkostnader. Utvecklingsteam har sedan större möjligheter att översätta affärsbehov till mikrotjänster som kan distribueras, skalas och utnyttjas för flera affärsbehov.

Eftersom automatisering av kodintegrering och leverans och containerisering av applikationer driver applikationsleverans hjälper nästa devops-praxis att automatisera och standardisera infrastrukturen och molntjänsterna.

Det var tidigare svårt att automatisera och hantera infrastruktur. När en arkitektur väl valts gick operativa ingenjörer till olika infrastrukturkomponenter för att bygga och konfigurera dem enligt kraven. Konfigurations- och tillgångshanteringsverktygen som används för att fånga dessa arkitekturer krävde en blandning av automatiserade och manuella steg och var ofta inaktuella eller saknade viktig information. Datormiljöer var också styva och, även om det fanns några verktyg för att automatisera skalningsmiljöer, isolerades de ofta till en viss infrastrukturtyp, krävde olika färdigheter för att implementera automatiseringen och hade endast tillgång till en delmängd av operativa data för att avgöra om och hur att väga.

Dagens molnmiljöer erbjuder användargränssnitt som förenklar arbetet för ingenjörer. Ingenjörer kan använda dessa verktyg för att ställa in virtuella privata nätverk, konfigurera säkerhetsgrupper och sedan starta beräkning, lagring och andra nödvändiga tjänster.

Men devops-team tar detta ett steg längre. Istället för att använda webbgränssnitten och konfigurera datorresurser manuellt automatiserar de processen med kod. Infrastruktur som kod (IaC) -verktyg låter operativa ingenjörer skript och automatisera installation och hantering av infrastruktur. Konfigurationerna som möjliggör upp- och nedskalning av miljöer kan också bäddas in i dessa skript. Chef, Puppet, Ansible och Salt är fyra konkurrerande teknologier som hjälper till att implementera operativa team att implementera IaC.

En tillverkningsprocess är bara lika bra som förmågan att övervaka, varna och återhämta sig efter problem. Detsamma gäller för övervakning av devops och användarupplevelsen av att köra applikationer och tjänster. Eftersom organisationer investerar i automatisering, containerisering, standardisering och distribution av applikationer är en parallell investering i övervakning en bästa praxis.

Tänk på övervakning på flera nivåer. På den lägsta nivån är infrastrukturövervakningen som möjliggör igenkänning och svar när beräkningsresurser inte är friska eller underpresterande. Molnmiljöer erbjuder idag funktioner för att övervaka, varna och använda elastiska molnfunktioner för att svara på infrastrukturproblem.

Nästa lager består av verktygen för att övervaka och fånga mätvärden kring devops automatisering. Dessa verktyg blir mer kritiska när antalet utvecklare och tjänster som kan distribueras ökar. Dessa verktyg ger varningar när konstruktioner misslyckas och granskningsverktyg för att hjälpa till att diagnostisera problem.

Slutligen finns det verktyg som övervakar applikationens driftstid, prestanda och andra körtidsmätvärden. Dessa övervakningsverktyg testar ofta API: er och utför även fullständiga webbläsartester på antingen enstaka slutpunkter eller flerstegstransaktioner. Dessa skärmar är ett frontlinjeförsvar för att varna devops-team när API: er eller applikationer fungerar utanför acceptabla servicenivåer.

Det finns många devops-metoder, och det tar alla tid att mogna och integrera. Det finns inte en föreskriven sekvens för att implementera dem eller hårda rekommendationer om hur mycket automatisering man ska investera i.

Ändå bör organisationer först försöka anpassa kulturen och tankesättet kring devops principer och sedan inse vilka metoder som bäst överensstämmer med affärsbehovet. Till exempel kan organisationer som redan upplever dålig applikationsprestanda välja att implementera övervakning först för att lösa problem snabbare och identifiera grundorsaker lättare. Andra organisationer som startar molnmigrationer kan välja att distribuera infrastruktur som kod, medan de som skapar standardarkitekturer för applikationsutveckling kan investera i CI / CD-pipelines.

Teknologer bör komma ihåg att det kostar att implementera automatisering och att inte alla organisationer kräver kontinuerlig distribution. Den bästa praxis är att se till att först tillgodose affärsbehov och anpassa devops automatisering till områden med hög repetition där manuella ansträngningar är felbenägna.

Relaterad video: Ökningen av devops i företaget