streamalism.org

1. Oversigt

I denne artikel vil vi forstå det grundlæggende i DevOps-principper og praksis. Vi ser, hvorfor dette er relevant og nyttigt i softwareudvikling. Vi forstår også, hvordan vi kan vedtage DevOps meningsfuldt, og hvilke værktøjer der er der til at hjælpe os på denne rejse.

2. Historisk kontekst

Vi vil ikke være i stand til at sætte pris på DevOps, som det står i dag uden at se lidt tilbage på historien. De tidlige dage med softwareudvikling var for det meste præget af det, vi kalder vandfaldsmetode. Hvad dette effektivt betyder er, at software blev konceptualiseret, designet, udviklet, testet og distribueret efter hinanden.

Hvert trin var så detaljeret som muligt gå tilbage var meget dyrt. Hvad dette effektivt betød var en langt højere ventetid mellem tanke og handling. Dette var dog ikke et sådant problem, da teknologilandskabet var meget mindre ustabilt og forstyrrelser alt for spredte.

Interessant nok varede denne model ikke længe. Da tempoet i teknologi ændrede sig, og forstyrrelser begyndte at ske ofte, begyndte virksomhederne at føle varmen. De havde brug for det nye ideer til at blive testet hurtigere. Dette betød hurtigere ændringer i alle aspekter af virksomheden, inklusive software.

Dette fødte en helt ny verden af ​​softwareudviklingsmetoder, der løst ses under paraplyen Agile. Det smidige manifest indeholder et sæt principper, der skal følges software levering i små intervaller med en hurtigere feedback loop. Der er flere smidige rammer som Scrum og Kanban i praksis.

3. Hvad er? DevOps?

Vi har set, at inkrementel udvikling med hurtigere feedback er blevet hjørnestenen i softwarelevering i dag. Men hvordan opnår vi det? Mens traditionelle smidige metoder fører os til et rimeligt punkt, er det stadig ikke ideelt.

Agile metoder fortsætter med at raffinere sig selv, da de konstant stræber efter at bryde siloer.

Traditionelt havde vi altid forskellige hold, der var ansvarlige for at udvikle og levere software. Disse hold opererede ofte i deres siloer. Dette oversættes effektivt til en meget længere feedbackcyklus, hvilket ikke er noget, vi ønsker med agile metoder.

Så det kræver ikke meget ræsonnement at forstå, at velintegrerede, tværfunktionelle agile teams er meget bedre egnet til at nå deres mål. DevOps er den praksis, der tilskynder til kommunikation, samarbejde, integration og automatisering mellem softwareudvikling og driftsteams. Dette giver os bedre mulighed for at realisere trinvis udvikling med hurtigere feedback.

Følgende diagram forklarer en mulig arbejdsgang til at øve DevOps:

Mens vi gennemgår detaljerne i disse trin senere i vejledningen, lad os forstå nogle af de vigtigste principper i DevOps:

• Værdicentreret tilgang (som realiseret af slutbruger)
• Samarbejdskultur (med effektiv kommunikation, processer og værktøjer)
• Automatisering af processer (for at øge effektiviteten og reducere fejl)
• Målbare resultater (at måle mod målene)
• Kontinuerlig feedback (med en tendens til hurtig forbedring)

4. Hvordan starter jeg rejsen?

Mens teorien er ligetil og tiltalende, ligger de virkelige udfordringer i at øve DevOps meningsfuldt. Som vi har samlet indtil videre, DevOps handler mest om mennesker, snarere end hold.

Fælles mål, effektiv kommunikation og tværfunktionelle færdigheder er kendetegnende for sådanne teams. Da en stor del af denne ændring er kulturel, er den ofte langsom og ikke uden friktion.

4.1. Motivering

Bare fordi der er en populær praksis derude, gør det ikke nødvendigvis det passende for os. Vi er nødt til at forstå vores motivation for ethvert skift - mere hvis vi foretager en ændring mod adræt. Det er det nyttigt at angive ved at definere de mål, vi ønsker at nå.

Målene for DevOps i enhver organisation er afhængige af organisationens ambition, kultur og modenhed. Her er nogle af de mere almindelige DevOps-mål:

• Bedre oplevelse for slutbrugere
• Hurtigere tid til markedet
• Forbedret gennemsnitstid til bedring

4.2. Adoption

Husk, at DevOps ikke er en sluttilstand, men en kontinuerlig forbedringsproces for at nå målene. Derfor skal alle på holdet stræbe for at identificere hindringer og fjerne dem hurtigt. Her er et par aktiviteter, der kan hjælpe os med at komme i gang:

• Forstå klart den nuværende tankegang for produktionscyklussen
• Saml nogle af de åbenlyse flaskehalse og brug metrics til at træffe faktiske beslutninger
• Prioriter de flaskehalse, der tilføjer mest værdi, når de fjernes
• Definer en iterativ plan for at levere værdi trinvist for prioriterede varer
• Følg de korte cyklusser af Develop-Deploy-Measure for at nå målene

5. DevOps-praksis

Der er flere fremgangsmåder at følge, men ideen bør ikke bruge nogen som en guldstandard. Vi bør nøje undersøge enhver praksis i baggrunden for vores tilstand og mål og derefter træffe informerede beslutninger. Imidlertid har næsten alle fremgangsmåder tendens til at fokusere på automatisering af processer så meget som muligt.

5.1. Agil planlægning

Agil planlægning er praksis med at definere arbejdet i korte intervaller. Mens det endelige mål skal være klart, er det ikke nødvendigt at definere og specificere hele applikationen på forhånd. Nøglen her er at prioritere arbejde baseret på den værdi, det kan levere.

Derefter skal det brydes i en iteration af korte, men fungerende intervaller.

5.2. Infrastruktur-som-kode (IaC)

Dette er praksis med at administrere og klargøre infrastruktur gennem maskinlæsbare konfigurationsfiler. Vi administrerer også disse konfigurationer i et versionskontrolsystem ligesom vi administrerer vores codebase. Der er mange domænespecifikke sprog tilgængelige for at oprette disse konfigurationsfiler erklærende.

5.3. Test automatisering

Softwaretestning har traditionelt været en manuel indsats, der ofte udføres i siloer. Dette gifter sig ikke godt med smidige principper. Derfor er det bydende nødvendigt, at vi prøver at automatisere softwaretest på alle niveauer, såsom enhedstest, funktionstest, sikkerhedstest og performance-test.

5.4. Kontinuerlig integration (CI)

Kontinuerlig integration er praksis med at flette arbejdskode oftere i små intervaller til et delt lager. Normalt er der automatiske builds og checks, der ofte kører på dette delte lager for at advare os om eventuelle kodepauser så hurtigt som muligt.

5.5. Kontinuerlig levering / implementering (CD)

Kontinuerlig levering er praksis med at frigive software i små trin, så snart den består alle kontroller. Dette praktiseres ofte sammen med kontinuerlig integration og kan drage fordel af en automatiseret frigivelsesmekanisme (kaldet kontinuerlig implementering).

5.6. Kontinuerlig overvågning

Overvågning - måske centrum for DevOps - muliggør hurtigere feedback-sløjfer. Identificere de rigtige målinger til at overvåge alle aspekter af softwaren, herunder infrastruktur, er afgørende. At have de rigtige målinger kombineret med realtids og effektiv analyse kan hjælpe med at identificere og løse problemer hurtigere. Desuden føder det direkte ind i den agile planlægning.

Denne liste er langt fra komplet og er under konstant udvikling. Hold, der praktiserer DevOps, finder løbende bedre måder at nå deres mål på. Nogle af de andre værdier, der er værd at nævne, er Containerization, Cloud-Native Development og Microservices, for at nævne nogle få.

6. Handelsværktøjer

Ingen diskussion om DevOps kan være komplet uden at tale om værktøjerne. Dette er et område, hvor der har været en eksplosion de sidste par år. Der kan være et nyt værktøj derude, når vi er færdige med at læse denne vejledning! Selvom dette er fristende og overvældende på samme tid, er det nødvendigt at udvise forsigtighed.

Vi må ikke starte vores DevOps-rejse med værktøjer som den første ting i vores sind. Vi skal udforske og etablere vores mål, mennesker (kultur) og praksis, inden vi finder de rigtige værktøjer. Når vi er klare på det, lad os se, hvad der er nogle af de tidstestede værktøjer, der er tilgængelige for os.

6.1. Planlægning

Som vi har set starter en moden DevOps altid med agil planlægning. Selvom målene er klare, er det kun nødvendigt at prioritere og definere arbejde til få korte iterationer. Feedbacken fra disse tidlige iterationer er uvurderlig til at forme de fremtidige og hele softwaren til sidst. Et effektivt værktøj her vil hjælpe os med at udøve denne proces med lethed.

Jira er et top-rated produkt til sporing af problemer udviklet af Atlassian. Det har mange indbyggede agile planlægnings- og overvågningsværktøjer. Stort set er det et kommercielt produkt, som vi enten kan køre på stedet eller bruge som en hostet applikation.

6.2. Udvikling

Ideen bag agile er at prototype hurtigere og søge feedback på den aktuelle software. Udviklere skal foretage ændringer og fusionere hurtigere i en delt version af softwaren. Det er endnu vigtigere for kommunikationen mellem teammedlemmer at være flydende og hurtig.

Lad os se på nogle af de allestedsnærværende værktøjer i dette domæne.

Git er et distribueret versionskontrolsystem. Det er ret populært, og der er adskillige hostede tjenester, der leverer git-arkiver og værditilvækkede funktioner. Oprindeligt udviklet af Linus Torvalds, gør det samarbejde mellem softwareudviklere ret praktisk.

Confluence er et samarbejdsværktøj udviklet af Atlassian. Samarbejde er nøglen til succes for ethvert agilt hold. Den egentlige semantik ved samarbejde er temmelig sammenhængende, men et værktøj, der gør en indsats problemfri, er ikke desto mindre uvurderlig. Sammenløb passer nøjagtigt til dette sted. Desuden integreres det godt med Jira!

Slack er en platform til instant messaging udviklet af Slack Technologies. Som vi diskuterede, adræt hold skal være i stand til at samarbejde og kommunikere, helst i realtid. Bortset fra instant messaging tilbyder Slack mange måder at kommunikere med en enkelt bruger eller en gruppe brugere - og det integreres godt med andre værktøjer som Jira og GitHub!

6.3. Integration

Ændringer, der flettes af udviklere, bør løbende inspiceres for overholdelse. Hvad der udgør overholdelse er specifikt for team og anvendelse. Det er dog almindeligt at se statiske og dynamiske kodeanalyser såvel som funktionelle og ikke-funktionelle metriske målinger som komponenter i overensstemmelse.

Lad os se kort på et par populære integrationsværktøjer.

Jenkins er en overbevisende, open source og gratis automatiseringsserver. Det har været i branchen i årevis og har modnet nok til at servicere et stort spektrum af automatiseringsanvendelsessager. Det giver en deklarativ måde at definere en automatiseringsrutine på og en række måder at udløse den automatisk eller manuelt. Desuden har den et stort sæt plugins, der tjener flere ekstra funktioner til at skabe kraftige automatiseringsrørledninger.

SonarQube er en open source-platform til kontinuerlig inspektion udviklet af SonarSource. SonarQube har et rigt sæt statiske analyseregler for mange programmeringssprog. Dette hjælper med at opdage kodelugt så tidligt som muligt. Desuden tilbyder SonarQube et dashboard, der kan integrere andre målinger som kodedækning, kodekompleksitet og mange flere. Og det fungerer godt med Jenkins Server.

6.4. Levering

At levere ændringer og nye funktioner til software hurtigt er vigtigt. Så snart vi har konstateret, at de ændringer, der er slået sammen i arkivet, overholder vores standarder og politikker, skal vi kunne levere det til slutbrugerne hurtigt. Dette hjælper os med at samle feedback og forme softwaren bedre.

Der er flere værktøjer her, der kan hjælpe os med at automatisere nogle aspekter af levering til det punkt, hvor vi opnår kontinuerlig implementering.

Docker er et udbredt værktøj til hurtigt at containerisere enhver applikationstype. Det udnytter virtualisering på OS-niveau til at isolere software i pakker kaldet containere. Containerisering har en umiddelbar fordel med hensyn til mere pålidelig levering af software. Docker Containere taler med hinanden gennem veldefinerede kanaler. Desuden er dette ret let i forhold til andre måder at isolere på som virtuelle maskiner.

Chef / Puppet / Ansible er konfigurationsstyringsværktøjer. Som vi ved, er en faktisk kørende forekomst af en softwareapplikation en kombination af codebase-build og dens konfigurationer. Og mens codebase-build ofte er uforanderlig på tværs af miljøer, er konfigurationer ikke. Det er her vi har brug for et konfigurationsstyringsværktøj til at implementere vores applikation let og hurtigt. Der er flere populære værktøjer i dette rum, der hver især har deres særheder, men Chef, Puppet og Ansible dækker stort set baserne.

HashiCorp Terraform kan hjælpe os med tilvejebringelse af infrastruktur, som har været en kedelig og tidskrævende opgave siden private datacenters dage. Men med mere og mere vedtagelse af sky betragtes infrastruktur ofte som en engangs og gentagelig konstruktion. Dette kan dog kun opnås, hvis vi har det et værktøj, som vi kan definere enkel til kompleks infrastruktur med angivelse af og oprette den med et klik på en knap. Det lyder måske som en drømmesekvens, men Terraform forsøger aktivt at bygge bro over dette hul!

6.5. Overvågning

Endelig er det vigtigt at kunne observere implementeringen og måle den mod målene. Der kan være en række målinger, vi kan indsamle fra systemer og applikationer. Disse inkluderer nogle af de forretningsmålinger, der er specifikke for vores ansøgning.

Ideen her er at kunne samle, kurere, gemme og analysere disse målinger næsten i realtid. Der er flere nye produkter, både open source og kommercielle, der er tilgængelige i dette rum.

Elastic-Logstash-Kibana (ELK) er en stak af tre open source-projekter - Elasticsearch, Logstash og Kibana. Elasticsearch er en meget skalerbar søge- og analysemotor. Logstash giver os en serverbehandlingspipeline, der er i stand til at forbruge data fra en lang række kilder. Endelig hjælper Kibana os med at visualisere disse data. Sammen kan denne stak være bruges til at samle data som logfiler fra alle applikationer og analysere dem i realtid.

Prometheus er et open source-systemovervågnings- og alarmværktøj oprindeligt udviklet af SoundCloud. Den leveres med en flerdimensionel datamodel, et fleksibelt forespørgselssprog og kan trække tidsseriedata over HTTP. Grafana er en anden open source-analyse- og overvågningsløsning der fungerer med flere databaser. Sammen kan Prometheus og Grafana give os et realtidshåndtag på stort set alle målinger, som vores systemer er i stand til at producere.

7. DevOps-udvidelser (eller er de virkelig!)

Vi har set, at DevOp grundlæggende er en kontinuerlig indsats for at fjerne hindringer mod hurtigere og iterativ værdibaseret levering af software. Nu er en af ​​de umiddelbare konklusioner, at der ikke kan være en sluttilstand her.

Hvad folk indså som friktion mellem udviklings- og driftsteam er ikke den eneste friktion. At bryde siloer i en organisation for at øge samarbejdet er den centrale idé. Nu begyndte folk snart at indse det lignende friktioner findes mellem udviklings- og testteam og mellem udviklings- og sikkerhedsteams. Mange traditionelle opsætninger har dedikerede sikkerheds- og præstationshold.

DevOps fulde potentiale kan aldrig realiseres, før vi kan bryde næsten alle grænser mellem hold og hjælpe dem med at samarbejde meget mere effektivt. Dette iboende betyder at bringe hold som test, sikkerhed og ydeevne i folden.

Forvirringen er stort set i dens nomenklatur. DevOps får os til at forstå, at det mest handler om udvikling og driftsteam. Derfor er der over tid kommet nye vilkår, der omfatter andre hold. Men stort set er det bare DevOps, der bliver realiseret mere effektivt!

7.1. DevTestOps

Hjørnestenen i DevOps er levere software af høj kvalitet i små intervaller og oftere. Der er mange aspekter af vægt på kvalitet her. På en måde antager vi ofte, at DevOps-praksis, vi anvender, hjælper os med at opnå dette. Og det er også rigtigt, at mange af de fremgangsmåder, vi diskuterede tidligere, fokuserer på at sikre høj kvalitet til enhver tid.

Men funktionel test af software har et meget bredere anvendelsesområde. Ganske ofte har vi tendens til at beholde test af højere ordre som end-to-end-test mod slutningen af ​​softwarelevering. Endnu vigtigere er dette ofte ansvaret for et separat team, der engagerer sig sent i processen. Det er her ting begynder at afvige fra DevOps-principperne.

Hvad vi snarere skal gøre er at integrere softwaretest på alle niveauer lige fra starten. Lige fra planlægningsfasen skal softwaretest betragtes som et integreret aspekt ved levering. Desuden skal det samme hold være ansvarligt for at udvikle og teste softwaren. Dette er, hvad praksis med DevTestOps er almindeligt kendt som. Dette omtales ofte også som kontinuerlig test og skift til venstre.

7.2. DevSecOps

Sikkerhed er en integreret del af enhver softwareudvikling og har sin andel af kompleksitet. Dette betyder ofte, at vi har et separat team af sikkerhedsspecialister, som vi samarbejder med lige når vi er klar til at sende produktet. De sårbarheder, de identificerer på dette tidspunkt, kan være dyre at løse. Dette stemmer igen ikke godt overens med DevOps principper.

På dette tidspunkt skal vi allerede have den løsning, vi har brug for, og det er, at vi skal bringe sikkerhedsproblemer og personale tidligt i spillet. Vi bør motivere hold til at tænke på sikkerhed i alle faser. Sikkerhed er uden tvivl et meget specialiseret domæne, og derfor kan det være nødvendigt at hente en specialist inden for holdet. Men ideen her er at overveje nogle af de bedste fremgangsmåder lige fra starten.

Når vi bevæger os videre, er der flere tilgængelige værktøjer, der kan automatisere scanning efter størstedelen af ​​sårbarheder. Vi kan også tilslutte dette til vores kontinuerlige integrationscyklusser for at få hurtig feedback! Nu kan vi ikke integrere alt i den kontinuerlige integration, da vi skal holde det let, men der kan altid være andre periodiske scanninger, der kører separat.

8. Konklusion

I denne artikel gennemgik vi det grundlæggende i DevOps-principper, praksis og værktøjer, der er tilgængelige til brug. Vi forstod den sammenhæng, hvor DevOps er relevant, og årsagerne til, at det kan være til nytte for os. Vi diskuterede også kort, hvor vi skulle begynde i rejsen med at vedtage DevOps.

Desuden berørte vi nogle af de populære fremgangsmåder og værktøjer, der er tilgængelige for os til at bruge på denne rejse. Vi forstod også nogle af de andre populære udtryk omkring DevOps som DevTestOps og DevSecOps.

Endelig skal vi forstå, at DevOps ikke er en sluttilstand, men snarere en rejse, der måske aldrig bliver færdig! Men den sjove del her er selve rejsen. Hele tiden må vi aldrig miste vores mål af syne, og vi bør fokusere på nøgleprincipperne. Det er ret let at falde for glansen af ​​et populært værktøj eller udtryk i branchen. Men vi skal altid huske, at alt kun er nyttigt, hvis det hjælper os med at levere værdi til vores publikum mere effektivt.