🥇Nybörjarguide: Skapa en DevOps-pipeline

Om du är ny inom DevOps, ta en titt på denna guide för att skapa din första pipeline i fem steg.

DevOps har blivit den standardlösning som åtgärdar långsamma, isolerade eller defekta mjukvaruutvecklingsprocesser. Problemet är att om du är ny inom DevOps och inte vet var du ska börja kan det saknas en förståelse för dessa metoder. I denna artikel kommer vi att definiera en DevOps-pipeline samt ge en guide för hur man skapar en i fem steg. Även om denna handledning inte är uttömmande, bör den ge dig en grund för att börja din resa och för att utöka dina kunskaper i framtiden. Men först, låt oss börja med historien.

Min resa inom DevOps

Tidigare arbetade jag i cloud-teamet på Citi Group, där jag utvecklade en Infrastructure-as-a-Service (IaaS) webbapplikation för att hantera Citis molninfrastruktur, men jag har alltid varit intresserad av hur man kan effektivisera utvecklingsprocessen och föra in positiva kulturella förändringar i utvecklarteamet. Svaret fann jag i en bok rekommenderad av Greg Lavender, teknisk direktör för Citis molnarkitektur och infrastruktur. Boken hette "The Phoenix Project" (The Phoenix Project), och den förklarar principerna för DevOps, samtidigt som den läses som en roman.

I tabellen på baksidan av boken visas hur ofta olika företag distribuerar sina system i en release-miljö:

Amazon: 23 000 per dag
Google: 5 500 per dag
Netflix: 500 per dag
Facebook: En gång per dag
Twitter: Tre gånger i veckan
Typiskt företag: En gång var nio månad

Hur är det ens möjligt för Amazon, Google och Netflix att ha sådana frekvenser? Det beror på att dessa företag har kommit på hur man kan skapa 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 endast tillgång till en utvecklingsserver baserad på IBM WebSphere Application Server Community Edition. Problemet var att servern stängdes av varje gång flera användare försökte distribuera samtidigt, så utvecklarna var tvungna att meddela varandra om sina avsikter, vilket var ganska smärtsamt. Dessutom fanns det problem med låg testtäckning av koden, besvärliga processer för manuell distribution och bristen på möjlighet att spåra koddistribution kopplad till en specifik uppgift eller användarhistoria.

Jag insåg att något behövde göras och hittade en kollega som tänkte som jag. Vi beslutade att samarbeta för att skapa den ursprungliga DevOps-pipelinen - han installerade en virtuell maskin och en Tomcat-applikationsserver medan jag arbetade med Jenkins, integrerade Atlassian Jira och BitBucket, samt arbetade med testtäckning av koden. Det här sidoprojektet var mycket framgångsrikt: vi automatiserade nästan helt många processer, nådde nära 100 % tillförlitlighet på vår utvecklingsserver, säkerställde spårbarhet och förbättrade testtäckningen av koden, samt lade till möjligheten att koppla grenar i Git med uppgifter i Jira eller distribution. De flesta verktyg som vi använde för att bygga vår DevOps-pipeline hade ö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 tack vare Paretoprincipen (även känd som 80/20-regeln).

En kort introduktion till DevOps och CI/CD-pipelines

Om du frågar flera personer: "Vad är DevOps?", får du förmodligen flera olika svar. DevOps, precis som Agile, har utvecklats för att omfatta många olika discipliner, men de flesta håller med om några saker: DevOps är en programvaruutvecklingspraxis eller livscykel för programvaruutveckling (SDLC), där en central princip är att förändra kulturen där utvecklare och icke-utvecklare existerar i en miljö där:

Operationer som tidigare utfördes manuellt är automatiserade;
Alla gör det de är bäst på;
Antalet implementeringar under en viss tidsperiod ökar; Genomströmningen ökar;
Utvecklingsflexibiliteten ökar.

Även om rätt programvaruverktyg inte är det enda som krävs för att skapa en DevOps-miljö, är vissa verktyg nödvändiga. Ett nyckelverktyg är kontinuerlig integration och kontinuerlig distribution (CI/CD). I denna pipeline har miljöerna olika faser (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ög distributionsfrekvens.

I den här artikeln beskrivs en femstegsmetod för att skapa en DevOps-pipeline liknande den som visas i följande diagram, med användning av verktyg med öppen källkod.

Steg 1: CI/CD-metoder

Det första du behöver är ett verktyg för CI/CD. Jenkins, ett verktyg med öppen källkod baserat på Java och distribuerat under MIT-licensen, är det verktyg som har populariserat DevOps-riktningen och blivit de facto-standard.

Vad är då Jenkins? Tänk på det som en slags magisk universalfjärrkontroll som kan kommunicera med olika tjänster och verktyg och organisera dem. Själva CI/CD-verktyget, som Jenkins, är värdelöst, men det blir mer kraftfullt när det kopplas till olika verktyg och tjänster.

Jenkins är bara ett av många verktyg med öppen källkod för CI/CD som du kan använda för att bygga DevOps-pipelines.

Jenkins: Creative Commons och MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Så här ser DevOps-processerna ut med CI/CD-verktyget:

Du har ett CI/CD-verktyg som körs på din lokala värd, men just nu kan du göra lite eller inget. Låt oss gå vidare till nästa steg i resan in i DevOps-världen.

Steg 2: Hantering av versionskontrollsystem

Det bästa (och kanske enklaste) sättet att kontrollera att ditt CI/CD-verktyg kan göra magi är att integrera det med ett versionskontrollsystem (VCS). Varför behöver du kontroll över källkoden? Anta att du utvecklar en applikation. Varje gång du bygger en applikation skriver du kod, oavsett om du använder Java, Python, C++, Go, Ruby, JavaScript eller någon av de miljontals programmeringsspråken. Koden du skriver kallas källkod. I början, särskilt när du arbetar ensam, är det förmodligen okej att lagra allt i en lokal katalog. Men när projektet växer och du bjuder in andra att samarbeta, behöver du ett sätt att förhindra konflikter vid effektiv delning av modifieringar. Du behöver också ett sätt att återställa tidigare versioner, eftersom att göra backuper och kopiera/klistra in dem redan är föråldrat. Du (och dina teamkamrater) behöver något bättre.

Här blir ett versionskontrollsystem nästan en nödvändighet. Detta verktyg lagrar din kod i repositorier, håller reda på versioner och koordinerar arbetet mellan projektets deltagare.

Även om det finns många versionskontrollsystem är Git standarden, och det är sant. Jag rekommenderar starkt att använda Git, även om det finns andra alternativ som är öppen källkod.

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 DevOps-pipelinen ut med tillägg av versionskontrollsystem.

CI/CD-verktyget kan automatisera processerna för testning, hämtning av källkod och samarbetet mellan medlemmar. Inte illa? Men hur omvandlar man detta till en fungerande applikation som miljarder människor kan använda och värdera?

Steg 3: Skapa automatiseringsverktyget för byggprocessen

Bra! Du kan kontrollera koden och göra ändringar i versionshanteringssystemet, samt bjuda in dina vänner att samarbeta i utvecklingen. Men du har ännu inte skapat en applikation. För att skapa ett webbprogram måste det kompileras och paketeras i ett distribuerbart format eller köras som en körbar fil. (Observera att tolkade programmeringsspråk som JavaScript eller PHP inte behöver kompileras).

Använd automatiseringsverktyget för byggande. Oavsett vilket automatiseringsverktyg för byggande du väljer att använda, syftar de alla mot samma mål: att sammanställa koden till ett önskat format och automatisera uppgifter som städning, kompilering, testning och distribution i en viss miljö. Byggverktyg kan variera beroende på ditt programmeringsspråk, men här är några vanliga open source-alternativ.

Namn
Licens
Programmeringsspråk

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
(Gnu’s Not Unix), som syftar till att utveckla systemkomponenter för att skapa ett fritt alternativ till Unix, vilket gör det möjligt att helt undvika proprietär programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som rör sig mot ett gemensamt mål och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
(Gnu’s Not Unix), som syftar till att utveckla systemkomponenter för att skapa ett fritt alternativ till Unix, vilket gör det möjligt att helt undvika proprietär programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som rör sig mot ett gemensamt mål och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Bra! Du kan placera konfigurationsfilerna för automatiseringsverktyget i versionshanteringssystemet och låta ditt CI/CD-verktyg sätta ihop allt.

Allt ser bra ut, eller hur? Men var ska du distribuera din applikation?

Steg 4: Server för webbapplikationer

Så långt har du en paketerad fil som kan vara antingen körbar eller installerbar. För att en applikation ska vara verkligt nyttig måste den erbjuda någon form av tjänst eller gränssnitt, och du behöver en behållare för att hysa din applikation.

En server för webbapplikationer är just en sådan behållare. Servern tillhandahåller en miljö där logiken för den distribuerade paketet kan definieras. Den erbjuder också ett gränssnitt och webb tjänster, vilket öppnar upp för externa kontakter. Du behöver en HTTP-server och också en viss miljö (till exempel en virtuell maskin) för att installera den. Och för nu, låt oss anta att du får veta mer om det senare (även om jag kommer att berätta om containrar nedan).

Det finns flera open source-servrar för webbapplikationer.

Namn
Licens
Programmeringsspråk

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

Din DevOps-pipeline är nästan klar att använda. Bra jobbat!

Även om man kan stanna här och integrera själv, är kodens kvalitet en viktig aspekt för applikationsutvecklare, och detta behöver uppmärksammas.

Steg 5: Täckning av kodtestning

Implementering av tester kan vara ett annat tungt krav, men utvecklare bör fånga alla fel i applikationen tidigt och förbättra kodens kvalitet för att säkerställa att slutanvändarna kommer att vara nöjda. Lyckligtvis finns det många verktyg med öppen källkod för att testa din kod och ge rekommendationer för att förbättra dess kvalitet. Ännu bättre är att de flesta CI/CD-verktyg kan kopplas till dessa verktyg och automatisera processen.

Kodtestning består av två delar: testningsramverk som hjälper till att skriva och köra tester, samt verktyg för att generera förslag som hjälper till att förbättra kodens kvalitet.

Kodtestningssystem

Namn
Licens
Programmeringsspråk

JUnit
Eclipse Public License
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Rekommendationssystem för kodförbättring

Namn
Licens
Programmeringsspråk

Cobertura
(Gnu’s Not Unix), som syftar till att utveckla systemkomponenter för att skapa ett fritt alternativ till Unix, vilket gör det möjligt att helt undvika proprietär programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som rör sig mot ett gemensamt mål och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Eclipse Public License
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Observera att de flesta verktyg och ramverk som nämns ovan är skrivna för Java, Python och JavaScript, medan C++ och C# är proprietära programmeringsspråk (även om GCC har öppen källkod).

Nu när du har implementerat verktygen för kodtäckning bör din DevOps-pipeline se ut som diagrammet som visas i början av denna guide.

Extra steg

Containrar

Som jag redan nämnt kan du hosta din server på en virtuell maskin eller server, men containrar är en populär lösning.

Vad är containrar? En kort förklaring är att en virtuell maskin behöver en enorm mängd minne från operativsystemet, vilket överstiger storleken på applikationen, medan en container bara behöver några bibliotek och konfigurationer för att köra applikationen. Det är uppenbart att virtuella maskiner fortfarande har viktiga användningsområden, men en container är en lätt lösning för att hosta applikationen, inklusive applikationsservrar.

Även om det finns andra alternativ för containrar, är de mest populära Docker och Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Mellanautomatiseringsverktyg

Vår DevOps-pipeline är främst inriktad på samarbete för skapande och distribution av applikationer, men det finns många andra saker som kan göras med hjälp av DevOps-verktyg. En av dem är användningen av verktyg för Infrastruktur som Kod (IaC), som också är kända som mellanautomatiseringsmedel. Dessa verktyg hjälper till att automatisera installation, hantering och andra uppgifter för mellanprogramvara. Till exempel kan ett automatiseringsverktyg extrahera applikationer som webbapplikationsservrar, databaser och övervakningsverktyg, med rätt konfigurationer och distribuera dem på applikationsservern.

Här är några mellanautomatiseringsverktyg med öppen källkod:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache eller GPL

Lär dig mer om hur du kan skaffa en eftertraktad yrkesroll från grunden eller Level Up dina färdigheter och din lön genom att ta betalda onlinekurser från SkillFactory: