Bygg din första DevOps-kedja i fem steg för nybörjare.
DevOps har blivit ett universalmedel för för långsamma, frånkopplade och annars problematiska utvecklingsprocesser. Men du behöver minimal kunskap i DevOps. Den kommer att täcka koncept som DevOps-kedjan och hur man skapar en i fem steg. Detta är inte en komplett guide, utan bara en "fisk" som kan utökas. Låt oss börja med historien.
Min introduktion till DevOps
Tidigare arbetade jag med moln på Citi Group och utvecklade en IaaS-webbapplikation för att hantera Citis molninfrastruktur, men jag har alltid varit intresserad av hur man kan optimera utvecklingskedjan och förbättra kulturen bland utvecklare. Greg Lavender, vår CTO för molnarkitektur och infrastruktur, rekommenderade den här boken till mig. . Den förklarar DevOps principer vackert och läser som en roman.
Tabellen på baksidan visar hur ofta företag rullar ut nya versioner:
Hur lyckas Amazon, Google och Netflix rulla ut så mycket? Och det är enkelt: de kom på hur man skapar en nästan perfekt DevOps-kedja.
Saker och ting var väldigt annorlunda för oss på Citi tills vi bytte till DevOps. Sedan hade mitt team olika miljöer, men vi gjorde leveransen till utvecklingsservern manuellt. Alla utvecklare hade tillgång till endast en utvecklingsserver baserad på IBM WebSphere Application Server Community Edition. Med ett samtidigt försök att leverera "föll" servern och varje gång var vi tvungna att "smärsamt" förhandla sinsemellan. Vi hade också otillräcklig kodtäckning med tester, en tidskrävande manuell leveransprocess och inget sätt att spåra leveransen av kod med någon uppgift eller kundkrav.
Det var tydligt att något akut behövde göras och jag hittade en likasinnad kollega. Vi bestämde oss för att skapa den första DevOps-kedjan tillsammans – han satte upp en virtuell maskin och en Tomcat-applikationsserver, och jag tog hand om Jenkins, integration med Atlassian Jira och BitBucket, samt kodtäckning med tester. Projektet var framgångsrikt: vi helautomatiserade utvecklingskedjan, uppnådde nästan 100 % drifttid på utvecklingsservern, kunde övervaka och förbättra kodtäckningen med tester, och en Git-gren kunde knytas till en Jira-leverans och -problem. Och nästan alla verktyg vi använde för att bygga DevOps-kedjan var öppen källkod.
Faktum är att kedjan förenklades, eftersom vi inte ens tillämpade avancerade konfigurationer med Jenkins eller Ansible. Men vi lyckades. Kanske är detta en konsekvens av principen (alias 80/20-regeln).
En kort beskrivning av DevOps och CI/CD-kedjan
DevOps har olika definitioner. DevOps innehåller, liksom Agile, olika discipliner. Men de flesta kommer att hålla med om följande definition: DevOps är en metod, eller livscykel, för mjukvaruutveckling, vars huvudprincip är att skapa en kultur där utvecklare och andra anställda är "på samma våglängd", manuellt arbete är automatiserat, alla gör det de är bäst på, leveransfrekvensen ökar, produktiviteten i arbetet ökar, flexibiliteten ökar.
Även om verktyg ensamma inte räcker för att skapa en DevOps-miljö, är de oumbärliga. Den viktigaste av dessa är kontinuerlig integration och kontinuerlig leverans (CI/CD). Det finns olika steg i kedjan för varje miljö (t.ex. DEV (utveckling), INT (integration), TST (testning), QA (kvalitetssäkring), UAT (testning av användaracceptans), STG (förberedelse), PROD (användning)) , manuella uppgifter automatiseras, utvecklare kan producera kvalitetskod, leverera den och enkelt bygga om.
Den här anteckningen beskriver hur man skapar en DevOps-kedja i fem steg, som visas i bilden nedan, med hjälp av verktyg med öppen källkod.
Låt oss komma till saken.
Steg 1: CI/CD-plattform
Först och främst behöver du ett CI/CD-verktyg. Jenkins är ett MIT-licensierat CI/CD-verktyg med öppen källkod skrivet i Java som populariserade DevOps-rörelsen och har blivit de facto-standarden för CICD.
Vad är Jenkins? Föreställ dig att du har en magisk kontrollpanel för en mängd olika tjänster och verktyg. I sig är ett CI/CD-verktyg som Jenkins värdelöst, men med olika verktyg och tjänster blir det allsmäktigt.
Förutom Jenkins finns det många andra verktyg med öppen källkod, välj vilket som helst.
Så här ser en DevOps-process ut med ett CI/CD-verktyg
Du har ett CI/CD-verktyg i localhost, men det finns inte mycket att göra ännu. Låt oss gå vidare till nästa steg.
Steg 2: Versionskontroll
Det bästa (och utan tvekan enklaste) sättet att testa magin i ett CI/CD-verktyg är att integrera det med ett verktyg för källkontrollhantering (SCM). Varför behöver du versionskontroll? Låt oss säga att du gör en ansökan. Du skriver det i Java, Python, C++, Go, Ruby, JavaScript eller något annat språk som är en vagn och en liten vagn. Det du skriver kallas källkod. Till en början, särskilt om du arbetar ensam, kan du spara allt i en lokal katalog. Men i takt med att projektet växer och fler ansluter sig behöver du ett sätt att dela kodändringar men undvika konflikter när du slår samman ändringar. Och du måste också på något sätt återställa tidigare versioner utan att använda säkerhetskopior och använda kopiera-klistra-metoden för kodfiler.
Och här utan SCM någonstans. SCM lagrar kod i arkiv, hanterar versioner av den och koordinerar den bland utvecklare.
Det finns många SCM-verktyg, men Git har välförtjänt blivit de facto-standarden. Jag råder dig att använda den, men det finns andra alternativ.
Så här ser DevOps-pipelinen ut efter att ha lagt till SCM.
CI/CD-verktyget kan automatisera uppladdning och nedladdning av källkod samt teamsamarbete. Inte dåligt? Men hur gör man nu en fungerande applikation från denna, älskad av miljarder användare?
Steg 3: Bygg automationsverktyg
Allt går rätt till. Du kan ladda upp kod och göra ändringar i källkontrollen och bjuda in vänner att arbeta med dig. Men du har ingen app än. För att detta ska vara en webbapplikation måste den vara kompilerad och paketerad för distribution eller köras som en körbar fil. (Ett tolkat programmeringsspråk som JavaScript eller PHP behöver inte kompileras.)
Använd ett verktyg för byggautomatisering. Vilket verktyg du än väljer kommer det att montera koden i rätt format och automatisera rensning, kompilering, testning och leverans. Byggverktygen varierar beroende på språk, men följande alternativ för öppen källkod används ofta.
Perfekt! Låt oss nu infoga konfigurationsfilerna för byggautomatiseringsverktyget i källkontrollen så att CI/CD-verktyget bygger dem.
Det känns bra. Men var ska allt detta rullas ut nu?
Steg 4: Web Application Server
Så du har en paketerad fil som kan köras eller rullas ut. För att en applikation ska vara riktigt användbar måste den ha någon form av tjänst eller gränssnitt, men du måste lägga allt någonstans.
En webbapplikation kan lagras på en webbapplikationsserver. Applikationsservern tillhandahåller en miljö där du kan exekvera paketerad logik, rendera gränssnitt och exponera webbtjänster över en socket. Du behöver en HTTP-server och några andra miljöer (till exempel en virtuell maskin) för att installera applikationsservern. Låt oss för nu låtsas att du hanterar allt detta när du går (även om jag kommer att prata om behållare nedan).
Det finns flera öppna webbapplikationsservrar.
Vi har redan en nästan fungerande DevOps-kedja. Bra jobbat!
I princip kan du sluta här, då kan du hantera det själv, men det är värt att prata om kvaliteten på koden.
Steg 5: Testtäckning
Att testa tar mycket tid och ansträngning, men det är bättre att hitta buggar direkt och förbättra koden för att tillfredsställa slutanvändarna. För detta ändamål finns det många öppna verktyg som inte bara testar koden utan också ger råd om hur man kan förbättra den. De flesta CI/CD-verktyg kan anslutas till dessa verktyg och automatisera processen.
Testning är uppdelad i två delar: testramverk för att skriva och utföra tester, och verktyg med tips för att förbättra kodkvaliteten.
Testa ramar
Verktyg med kvalitetstips
De flesta av dessa verktyg och ramverk är skrivna för Java, Python och JavaScript eftersom C++ och C# är proprietära (även om GCC är öppen källkod).
Vi har tillämpat testtäckningsverktygen, och nu bör DevOps-pipelinen se ut som bilden i början av handledningen.
Ytterligare steg
behållare
Som jag sa tidigare kan en applikationsserver vara värd i en virtuell maskin eller en server, men behållare är mer populära.
? Kort sagt, i en virtuell maskin tar operativsystemet ofta upp mer utrymme än applikationen och en container räcker vanligtvis med några bibliotek och konfiguration. I vissa fall är virtuella maskiner oumbärliga, men behållaren kan rymma applikationen tillsammans med servern utan extra kostnad.
För containrar används vanligtvis Docker och Kubernetes, även om det finns andra alternativ.
Läs artiklar om Docker och Kubernetes på :
Middleware automationsverktyg
Vår DevOps-kedja är fokuserad på samarbetsbyggande och leverans av en applikation, men det finns andra intressanta saker du kan göra med DevOps-verktyg. Använd till exempel Infrastructure as Code (IaC)-verktyg, även känd som middleware-automatiseringsverktyg. Dessa verktyg hjälper till att automatisera installation, hantering och andra uppgifter för mellanprogram. Ett automationsverktyg kan till exempel ta applikationer (webbapplikationsserver, databas, övervakningsverktyg) med rätt konfigurationer och skicka dem till applikationsservern.
Här är några alternativ för öppna verktyg för automatisering av mellanprogram:
Detaljer i artiklarna :
Och nu vad?
Det här är bara toppen av isberget. DevOps-kedjan kan mycket mer. Börja med ett CI/CD-verktyg och se vad du mer kan automatisera för att göra ditt jobb enklare. Glöm inte bort för effektivt samarbete.
Här är några fler bra DevOps-artiklar för nybörjare:
Du kan också integrera DevOps med öppna agila verktyg:
Källa: will.com