Om du är ny på DevOps, ta en titt på denna femstegsguide för att skapa din första pipeline.
DevOps har blivit standardlösningen för att fixa långsamma, osammanhängande eller trasiga programvaruutvecklingsprocesser. Problemet är att om du är ny på DevOps och inte vet var du ska börja, kanske du saknar förståelse för dessa tekniker. Den här artikeln kommer att diskutera definitionen av en DevOps-pipeline och kommer också att tillhandahålla fem-stegsinstruktioner för att skapa en. Även om den här handledningen inte är uttömmande bör den ge dig en grund för att börja din resa och utöka din kunskap i framtiden. Men låt oss börja med historien.
Min DevOps-resa
Jag har tidigare arbetat i Citi Groups molnteam med att utveckla en Infrastructure-as-a-Service (IaaS) webbapplikation för att hantera Citis molninfrastruktur, men jag har alltid varit intresserad av hur man kan göra utvecklingsprocessen mer effektiv och bringa positiv kulturell förändring till utvecklingsteam. Jag hittade svaret i en bok som rekommenderas av Greg Lavender, CTO för Cloud Architecture and Infrastructure på Citi. Boken hette The Phoenix Project (), och den förklarar principerna för DevOps, men den läser som en roman.
Tabellen längst bak i boken visar hur ofta olika företag distribuerar sina system i en releasemiljö:
Amazon: 23 000 per dag
Google: 5 500 per dag
Netflix: 500 per dag
Facebook: En gång om dagen
Twitter: 3 gånger i veckan
Typiskt företag: En gång var 9:e månad
Hur är Amazon, Google och Netflix ens möjliga? Detta beror på att dessa företag har listat ut hur man skapar en nästan perfekt DevOps-pipeline.
Vi var långt ifrån detta tills vi implementerade DevOps på Citi. Då hade mitt team olika miljöer, men distributionen på utvecklingsservern var helt manuell. Alla utvecklare hade tillgång till endast en utvecklingsserver baserad på IBM WebSphere Application Server Community Edition. Problemet var att servern stängdes av när flera användare försökte distribuera samtidigt, så utvecklarna var tvungna att kommunicera sina avsikter till varandra, vilket var ganska jobbigt. Dessutom fanns det problem med testkodstäckning på låg nivå, besvärliga manuella distributionsprocesser och oförmågan att spåra distributionen av kod som är associerad med en specifik uppgift eller användarberättelse.
Jag insåg att något måste göras och hittade en likasinnad kollega. Vi bestämde oss för att samarbeta för att bygga den första DevOps-pipelinen - han satte upp en Tomcat virtuell maskin och applikationsserver medan jag arbetade på Jenkins, integrerade Atlassian Jira och BitBucket och arbetade med testkodstäckning. Detta sidoprojekt var mycket framgångsrikt: vi automatiserade nästan helt många processer, uppnådde nästan 100 % drifttid på vår utvecklingsserver, tillhandahöll spårning och förbättrad testtäckning av koden och lade till möjligheten att länka Git-grenar till Jira-problem eller distributioner. De flesta av verktygen vi använde för att bygga vår DevOps-pipeline var öppen källkod.
Nu förstår jag hur enkel vår DevOps-pipeline var: vi använde inte tillägg som Jenkins-filer eller Ansible. Denna enkla pipeline fungerade dock bra, kanske på grund av Pareto-principen (även känd som 80/20-regeln).
En kort introduktion till DevOps och CI/CD Pipeline
Om du frågar flera personer, "Vad är DevOps?", kommer du förmodligen att få flera olika svar. DevOps har, precis som Agile, utvecklats till att spänna över många olika discipliner, men de flesta kommer överens om några saker: DevOps är en mjukvaruutvecklingsmetod eller mjukvaruutvecklingslivscykel (SDLC) vars centrala grundsats är att förändra kulturen där utvecklare och icke- utvecklare finns i en miljö där:
Operationer som tidigare utförts manuellt har automatiserats;
Alla gör det de är bäst på;
Antalet implementeringar under en viss tidsperiod ökar; Genomströmningen ökar;
Ökad utvecklingsflexibilitet.
Även om att ha rätt mjukvaruverktyg inte är det enda du behöver för att skapa en DevOps-miljö, är vissa verktyg viktiga. Ett nyckelverktyg är kontinuerlig integration och kontinuerlig driftsättning (CI/CD). I den här pipelinen har miljöer olika stadier (t.ex. DEV, INT, TST, QA, UAT, STG, PROD), många operationer är automatiserade och utvecklare kan skriva högkvalitativ kod, uppnå utvecklingsflexibilitet och höga distributionshastigheter.
Den här artikeln beskriver en metod i fem steg för att skapa en DevOps-pipeline som den som visas i följande diagram med hjälp av verktyg med öppen källkod.
Steg 1: CI/CD-metoder
Det första du behöver är ett CI/CD-verktyg. Jenkins, ett verktyg med öppen källkod baserat på Java och licensierat under MIT-licensen, är verktyget som populariserade DevOps och har blivit de facto-standarden.
Så vad är Jenkins? Se det som någon sorts magisk universell fjärrkontroll som kan prata med och organisera olika tjänster och verktyg. I sig är ett CI/CD-verktyg som Jenkins värdelöst, men det blir kraftfullare när det ansluter till olika verktyg och tjänster.
Jenkins är bara ett av många CI/CD-verktyg med öppen källkod som du kan använda för att bygga din DevOps-pipeline.
Jenkins: Creative Commons och MIT
Travis CI: MIT
CruiseControl:BSD
Byggbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Så här ser DevOps-processer ut med ett CI/CD-verktyg:
Du har ett CI/CD-verktyg som körs på din lokala värd, men det finns inte mycket du kan göra för tillfället. Låt oss gå vidare till nästa steg av DevOps-resan.
Steg 2: Hantera källkontrollsystem
Det bästa (och kanske enklaste) sättet att verifiera att ditt CI/CD-verktyg kan göra sin magi är att integrera med ett källkodskontrollverktyg (SCM). Varför behöver du källkontroll? Låt oss säga att du utvecklar en applikation. När du skapar en applikation programmerar du, och det spelar ingen roll om du använder Java, Python, C++, Go, Ruby, JavaScript eller något av de otaliga programmeringsspråken. Koden du skriver kallas källkod. I början, speciellt när du arbetar ensam, är det förmodligen ok att lägga allt i en lokal katalog. Men när projektet blir större och du bjuder in andra människor att samarbeta, behöver du ett sätt att förhindra konflikter samtidigt som du effektivt delar ändringar. Du behöver också ett sätt att återställa tidigare versioner, eftersom att skapa säkerhetskopior och kopiera/klistra in i dem börjar bli föråldrat. Du (och dina lagkamrater) behöver något bättre.
Det är här källkodskontroll blir nästan en nödvändighet. Det här verktyget lagrar din kod i arkiv, håller reda på versioner och koordinerar projektdeltagarnas arbete.
Även om det finns många källkontrollverktyg där ute, är Git standarden, och det med rätta. Jag rekommenderar starkt att du använder Git, även om det finns andra alternativ med öppen källkod om du föredrar det.
Git: GPLv2 och LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Så här ser en DevOps-pipeline ut med tillägg av källkodskontroller.
Ett CI/CD-verktyg kan automatisera processerna för granskning, källkodsinhämtning och samarbete mellan medlemmar. Inte dåligt? Men hur gör man det till en fungerande applikation så att miljarder människor kan använda och uppskatta det?
Steg 3: Skapa ett Build Automation Tool
Bra! Du kan granska koden och göra ändringar i källkontrollen och bjuda in dina vänner att samarbeta i utvecklingen. Men du har inte skapat en applikation än. För att göra en webbapplikation måste den kompileras och paketeras i ett distribuerbart batchformat eller köras som en körbar fil. (Observera att ett tolkat programmeringsspråk som JavaScript eller PHP inte behöver kompileras).
Använd ett verktyg för byggautomatisering. Oavsett vilket byggautomatiseringsverktyg du väljer att använda, har de alla samma mål: bygga in källkoden till ett önskat format och automatisera uppgiften att rengöra, kompilera, testa och distribuera till en specifik miljö. Byggverktygen varierar beroende på ditt programmeringsspråk, men här är några vanliga alternativ för öppen källkod.
namn
Licens
Programmeringsspråk
Maven
Apache 2.0
java
Ant
Apache 2.0
java
Gradle
Apache 2.0
java
Bazel
Apache 2.0
java
Fabrikat
GNU
N / A
grunt
MIT
JavaScript
Gulp
MIT
JavaScript
Byggare
Apache
Rubin
Räfsa
MIT
Rubin
AAP
GNU
Python
scons
MIT
Python
BitBake
GPLv2
Python
Kaka
MIT
C#
AsDF
Expat (MIT)
LÄSPA
Kabal
BSD
Haskell
Bra! Du kan lägga in konfigurationsfilerna för byggautomationsverktyget i ditt källkontrollsystem och låta ditt CI/CD-verktyg sätta ihop allt.
Allt är bra, eller hur? Men var ska du distribuera din applikation?
Steg 4: Web Application Server
För närvarande har du en paketerad fil som antingen kan vara körbar eller installeras. För att någon applikation verkligen ska vara användbar måste den tillhandahålla någon form av tjänst eller gränssnitt, men du behöver en behållare för din applikation.
En webbapplikationsserver är just en sådan behållare. Servern tillhandahåller en miljö där logiken för paketet som distribueras kan definieras. Servern tillhandahåller också ett gränssnitt och erbjuder webbtjänster genom att exponera sockets för omvärlden. Du behöver en HTTP-server, samt någon miljö (som en virtuell maskin) för att installera den. För nu, låt oss anta att du kommer att lära dig mer om detta (även om jag kommer att täcka behållare nedan).
Det finns flera webbapplikationsservrar med öppen källkod.
namn
Licens
Programmeringsspråk
hankatt
Apache 2.0
java
brygga
Apache 2.0
java
JBoss
GNU Lesser Public
java
Glasfisk
CDDL & GNU Mindre offentlig
java
Django
3-klausul BSD
Python
Tornado
Apache 2.0
Python
gunicorn
MIT
Python
Python
MIT
Python
Skenor
MIT
Rubin
node.js
MIT
Javascript
Din DevOps-pipeline är nästan klar att användas. Bra jobbat!
Även om du kan stanna där och hantera integrationen själv, är kodkvalitet en viktig sak för en apputvecklare att oroa sig för.
Steg 5: Täckning för kodtestning
Att implementera tester kan vara ett annat besvärligt krav, men utvecklare måste fånga eventuella buggar i applikationen tidigt och förbättra kodens kvalitet för att säkerställa att slutanvändarna är nöjda. Lyckligtvis finns det många open source-verktyg för att testa din kod och ge rekommendationer för att förbättra dess kvalitet. Vad som är ännu bättre är att de flesta CI/CD-verktyg kan ansluta till dessa verktyg och automatisera processen.
Kodtestning består av två delar: ramverk för kodtestning som hjälper dig att skriva och köra tester, och förslagsverktyg som hjälper dig att förbättra kvaliteten på din kod.
Kodtestsystem
namn
Licens
Programmeringsspråk
JUnit
Eclipse Public License
java
EasyMock
Apache
java
mockito
MIT
java
PowerMock
Apache 2.0
java
Pytest
MIT
Python
Hypotes
Mozilla
Python
Tox
MIT
Python
Rekommendationssystem för kodförbättring
namn
Licens
Programmeringsspråk
Täckning
GNU
java
CodeCover
Eclipse Public (EPL)
java
Coverage.py
Apache 2.0
Python
emma
Gemensam offentlig licens
java
JaCoCo
Eclipse Public License
java
Hypotes
Mozilla
Python
Tox
MIT
Python
Jasmin
MIT
JavaScript
Karma
MIT
JavaScript
Mocka
MIT
JavaScript
det finns
MIT
JavaScript
Observera att de flesta av de verktyg och ramverk som nämns ovan är skrivna för Java, Python och JavaScript, eftersom C++ och C# är proprietära programmeringsspråk (även om GCC är öppen källkod).
Nu när du har implementerat testtäckningsverktyg bör din DevOps-pipeline se ut som i diagrammet som visas i början av denna handledning.
Ytterligare steg
behållare
Du kan som sagt hosta din server på en virtuell maskin eller en server, men containrar är en populär lösning.
Vad är behållare? Den korta förklaringen är att en virtuell maskin behöver en enorm mängd operativsystemminne, som överstiger applikationens storlek, medan en behållare bara behöver några få bibliotek och konfigurationer för att köra applikationen. Uppenbarligen finns det fortfarande viktiga användningsområden för en virtuell maskin, men en behållare är en lätt lösning för att vara värd för en applikation, inklusive en applikationsserver.
Medan det finns andra containeralternativ är de mest populära Docker och Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Mellanliggande automationsverktyg
Vår DevOps-pipeline är främst inriktad på att skapa och distribuera applikationer i samarbete, men det finns många andra saker som kan göras med DevOps-verktyg. En av dem är användningen av Infrastructure as Code (IaC)-verktyg, som också är kända som middleware-automatiseringsverktyg. Dessa verktyg hjälper till att automatisera installation, hantering och andra uppgifter för mellanprogram. Så till exempel kan ett automationsverktyg extrahera applikationer som en webbapplikationsserver, en databas och ett övervakningsverktyg med rätt konfigurationer och distribuera dem till applikationsservern.
Här är några verktyg för automatisering av mellanprogram med öppen källkod:
Ansible: GNU Public
SaltStack: Apache 2.0
Kock: Apache 2.0
Docka: Apache eller GPL
Ta reda på detaljer om hur du får ett eftertraktat yrke från grunden eller Level Up när det gäller kompetens och lön genom att ta betalda onlinekurser från SkillFactory:
- (12 månader)
fler kurser
- (12 veckor)
- (12 månader)
- (9 månader)
- (9 månader)
användbar
Källa: will.com