streamalism.org

1. Oversikt

I denne artikkelen vil vi forstå det grunnleggende om DevOps-prinsipper og praksis. Vi får se hvorfor dette er relevant og nyttig i programvareutvikling. Vi vil også forstå hvordan vi kan bruke DevOps meningsfullt og hvilke verktøy som er der for å hjelpe oss på denne reisen.

2. Historisk kontekst

Vi vil ikke kunne sette pris på DevOps slik det står i dag uten å se litt tilbake på historien. De første dagene av programvareutvikling var for det meste preget av det vi kaller fossefallmetodikk. Hva dette effektivt betyr er at programvaren ble konseptualisert, designet, utviklet, testet og distribuert etter hverandre.

Hvert trinn var så detaljert som mulig, som å gå tilbake var veldig kostbart. Hva dette effektivt betydde var en mye høyere ventetid mellom tanke og handling. Dette var imidlertid ikke et slikt problem, da teknologilandskapet var mye mindre ustabilt og forstyrrelser altfor spredte.

Interessant, denne modellen varte ikke lenge. Da teknologitempoet endret seg og forstyrrelser begynte å skje ofte, begynte bedriftene å føle varmen. De trengte nye ideer som skal testes raskere. Dette betydde raskere endringer i alle aspekter av virksomheten, inkludert programvare.

Dette fødte en helt ny verden av programvareutviklingsmetoder som løst sees under paraplyen Agile. Det smidige manifestet angir et sett med prinsipper som skal følges for programvarelevering i små trinn med en raskere tilbakemeldingssløyfe. Det er flere smidige rammer som Scrum og Kanban i praksis.

3. Hva er? DevOps?

Vi har sett at trinnvis utvikling med raskere tilbakemelding har blitt hjørnesteinen i programvarelevering i dag. Men hvordan oppnår vi det? Selv om tradisjonelle smidige metoder tar oss til et fornuftig punkt, er det fortsatt ikke ideelt.

Agile metoder fortsetter å raffinere seg mens de kontinuerlig prøver å bryte siloer.

Tradisjonelt hadde vi alltid forskjellige team som hadde ansvar for å utvikle og levere programvare. Disse lagene opererte ofte i siloene sine. Dette oversettes effektivt til en mye lengre tilbakemeldingssyklus, som ikke er noe vi ønsker med smidige metoder.

Så det krever ikke mye resonnement for å forstå at godt integrerte, tverrfunksjonelle smidige team er mye bedre egnet til å levere sine mål. DevOps er praksis som oppmuntrer til kommunikasjon, samarbeid, integrasjon og automatisering mellom programvareutvikling og driftsteam. Dette gjør oss bedre i stand til å realisere trinnvis utvikling med raskere tilbakemelding.

Følgende diagram forklarer en mulig arbeidsflyt for å praktisere DevOps:

Mens vi vil gå gjennom detaljene i disse trinnene senere i opplæringen, la oss forstå noen av hovedprinsippene til DevOps:

• Verdisentrert tilnærming (som realisert av sluttbruker)
• Samarbeidskultur (med effektiv kommunikasjon, prosesser og verktøy)
• Automatisering av prosesser (for å øke effektiviteten og redusere feil)
• Målbare resultater (for å måle mot målene)
• Kontinuerlig tilbakemelding (med en tendens til å bli rask)

4. Hvordan starte reisen?

Mens teorien er grei og tiltalende, ligger de virkelige utfordringene i å praktisere DevOps meningsfullt. Som vi har samlet så langt, DevOps handler mest om mennesker, snarere enn team.

Felles mål, effektiv kommunikasjon og tverrfunksjonelle ferdigheter er kjennetegn på slike team. Siden en stor del av denne endringen er kulturell, er den ofte treg og ikke uten friksjon.

4.1. Motivasjon

Bare fordi det er en populær praksis der ute, gjør det ikke nødvendigvis det passende for oss. Vi må forstå vår motivasjon for ethvert skifte - mer hvis vi gjør en endring mot smidig. Det er nyttig å sette opp ved å definere målene vi ønsker å oppnå.

Målene for DevOps i enhver organisasjon er avhengig av organisasjonens ambisjon, kultur og modenhet. Her er noen av de vanligste DevOps-målene:

• Bedre opplevelse for sluttbrukere
• Raskere tid å markedsføre
• Forbedret gjennomsnittlig tid til utvinning

4.2. Adopsjon

Husk at DevOps ikke er en slutttilstand, men en kontinuerlig forbedringsprosess for å nå målene. Derfor må alle på laget strebe for å identifisere hindringer og fjerne dem raskt. Her er noen aktiviteter som kan hjelpe oss i gang:

• Forstå den nåværende tankegangen til produksjonssyklusen
• Samle noen av de åpenbare flaskehalsene og bruk beregninger for å ta faktiske avgjørelser
• Prioriter flaskehalsene som gir mest verdi når de fjernes
• Definer en iterativ plan for å levere verdi trinnvis for prioriterte varer
• Følg de korte syklusene til Develop-Deploy-Measure for å nå målene

5. DevOps-praksis

Det er flere måter å følge, men ideen bør ikke bruke noen som en gullstandard. Vi bør nøye undersøke hver praksis i bakgrunnen for vår tilstand og mål og deretter ta informerte beslutninger. Imidlertid har nesten all praksis en tendens til å fokusere på å automatisere prosesser så mye som mulig.

5.1. Agil planlegging

Agil planlegging er praksisen med å definere arbeidet i korte trinn. Selv om det endelige målet skal være klart, er det ikke nødvendig å definere og detaljere hele applikasjonen på forhånd. Nøkkelen her er å prioritere arbeid ut fra verdien det kan levere.

Deretter bør den brytes i en iterasjon av korte, men fungerende trinn.

5.2. Infrastruktur-som-kode (IaC)

Dette er praksis for å administrere og klargjøre infrastruktur gjennom maskinlesbare konfigurasjonsfiler. Vi administrerer også disse konfigurasjonene i et versjonskontrollsystem som vi administrerer kodebasen vår. Det er mange domenespesifikke språk tilgjengelig for å opprette disse konfigurasjonsfilene erklærende.

5.3. Test automatisering

Testing av programvare har tradisjonelt vært en manuell innsats ofte utført i siloer. Dette gifter seg ikke godt med smidige prinsipper. Derfor er det viktig at vi prøver for å automatisere programvaretesting på alle nivåer, for eksempel enhetstesting, funksjonstesting, sikkerhetstesting og ytelsestesting.

5.4. Kontinuerlig integrasjon (CI)

Kontinuerlig integrasjon er praksis med å slå sammen arbeidskode oftere i små trinn til et delt lager. Vanligvis er det automatiserte bygg og sjekker som ofte kjører på dette delte depotet for å varsle oss om eventuelle kodepauser så snart som mulig.

5.5. Kontinuerlig levering / distribusjon (CD)

Kontinuerlig levering er praksis med å gi ut programvare i små trinn så snart den går gjennom alle kontroller. Dette praktiseres ofte sammen med kontinuerlig integrasjon og kan dra nytte av en automatisert frigjøringsmekanisme (referert til som kontinuerlig distribusjon).

5.6. Kontinuerlig overvåking

Overvåking - kanskje sentrum for DevOps - muliggjør raskere tilbakemeldingsløkker. Identifisere de riktige beregningene for å overvåke alle aspekter av programvaren, inkludert infrastruktur, er avgjørende. Å ha de riktige beregningene, kombinert med sanntid og effektiv analyse, kan bidra til å identifisere og løse problemer raskere. Videre mates den direkte inn i den smidige planleggingen.

Denne listen er langt fra komplett og er i stadig utvikling. Team som praktiserer DevOps finner kontinuerlig ut bedre måter å nå sine mål på. Noen av de andre metodene som er verdt å nevne er Containerization, Cloud-Native Development og Microservices, for å nevne noen.

6. Handelsverktøy

Ingen diskusjon om DevOps kan være komplett uten å snakke om verktøyene. Dette er et område der det har vært en eksplosjon de siste årene. Det kan være et nytt verktøy der ute når vi er ferdig med å lese denne opplæringen! Selv om dette er fristende og overveldende på samme tid, er det nødvendig å være forsiktig.

Vi må ikke starte DevOps-reisen vår med verktøy som det første vi tenker på. Vi må utforske og etablere våre mål, mennesker (kultur) og praksis før vi finner de riktige verktøyene. Når vi er klare på det, la oss se hva som er noen av de tidstestede verktøyene vi har tilgjengelig.

6.1. Planlegger

Som vi har sett starter en moden DevOps alltid med smidig planlegging. Selv om målene er klare, er det bare nødvendig å prioritere og definere arbeid for få korte iterasjoner. Tilbakemeldingene fra disse tidlige iterasjonene er uvurderlige for å forme de fremtidige og hele programvaren til slutt. Et effektivt verktøy her vil hjelpe oss med å utøve denne prosessen med letthet.

Jira er et topprangerte emisjonssporingsprodukt utviklet av Atlassian. Den har mange innebygde smidige planleggings- og overvåkingsverktøy. I det store og hele er det et kommersielt produkt som vi enten kan kjøre på stedet eller bruke som et vert program.

6.2. Utvikling

Ideen bak smidig er å prototype raskere og søke tilbakemelding på selve programvaren. Utviklere må gjøre endringer og slå seg sammen raskere til en delt versjon av programvaren. Det er enda viktigere at kommunikasjonen mellom teammedlemmene er flytende og rask.

La oss se på noen av de allestedsnærværende verktøyene i dette domenet.

Git er et distribuert versjonskontrollsystem. Det er ganske populært, og det er mange hostede tjenester som gir git-arkiver og verdiskapende funksjoner. Opprinnelig utviklet av Linus Torvalds, gjør det samarbeid mellom programvareutviklere ganske praktisk.

Confluence er et samarbeidsverktøy utviklet av Atlassian. Samarbeid er nøkkelen til suksess for ethvert smidig team. Selve semantikken i samarbeid er ganske kontekstuell, men et verktøy som gjør en innsats sømløs er likevel uvurderlig. Samløp passer nøyaktig til dette stedet. Dessuten integreres det godt med Jira!

Slack er en direktemeldingsplattform utviklet av Slack Technologies. Som vi diskuterte, smidig team skal kunne samarbeide og kommunisere, helst i sanntid. Bortsett fra direktemeldinger, tilbyr Slack mange måter å kommunisere med en enkelt bruker eller en gruppe brukere - og det integreres godt med andre verktøy som Jira og GitHub!

6.3. Integrering

Endringer som er slått sammen av utviklere, bør kontrolleres kontinuerlig for samsvar. Hva som er samsvar er spesifikt for team og applikasjon. Imidlertid er det vanlig å se statiske og dynamiske kodeanalyser, så vel som funksjonelle og ikke-funksjonelle metriske målinger, som komponenter i samsvar.

La oss se kort på et par populære integrasjonsverktøy.

Jenkins er en overbevisende server med åpen kildekode og gratis automatisering. Det har vært i bransjen i årevis og har modnet nok til å betjene et stort spekter av automatiseringsbrukstilfeller. Det gir en deklarativ måte å definere en automatiseringsrutine på og en rekke måter å utløse den automatisk eller manuelt. Videre har den et rikt sett med plugins som tjener flere tilleggsfunksjoner for å lage kraftige automatiseringsrørledninger.

SonarQube er en kontinuerlig inspeksjonsplattform med åpen kildekode utviklet av SonarSource. SonarQube har et rikt sett med statiske analyseregler for mange programmeringsspråk. Dette hjelper med å oppdage kodelukt så tidlig som mulig. Videre tilbyr SonarQube et dashbord som kan integrere andre beregninger som kodedekning, kodekompleksitet og mange flere. Og det fungerer bra med Jenkins Server.

6.4. Leveranse

Det er viktig å levere endringer og nye funksjoner til programvaren raskt. Så snart vi har slått fast at endringene som er slått sammen i depotet, overholder våre standarder og retningslinjer, bør vi kunne levere det til sluttbrukerne raskt. Dette hjelper oss med å samle inn tilbakemeldinger og forme programvaren bedre.

Det er flere verktøy her som kan hjelpe oss med å automatisere noen aspekter ved levering til det punktet hvor vi oppnår kontinuerlig distribusjon.

Docker er et vanlig verktøy for å containerisere alle typer applikasjoner raskt. Den benytter virtualisering på OS-nivå for å isolere programvare i pakker som kalles containere. Containerisering har en umiddelbar fordel når det gjelder mer pålitelig levering av programvare. Docker Containers snakker med hverandre gjennom veldefinerte kanaler. Dessuten er dette ganske lett sammenlignet med andre måter å isolere på, som Virtual Machines.

Chef / Puppet / Ansible er konfigurasjonsadministrasjonsverktøy. Som vi vet, er en faktisk kjørende forekomst av et program en kombinasjon av kodebasebyggingen og dens konfigurasjoner. Og mens kodebasebyggingen ofte er uforanderlig i miljøer, er det ikke konfigurasjoner. Dette er hvor vi trenger et konfigurasjonsadministrasjonsverktøy for å distribuere applikasjonen vår med letthet og hastighet. Det er flere populære verktøy i dette rommet, som hver har sine særegenheter, men Chef, Puppet og Ansible dekker stort sett basene.

HashiCorp Terraform kan hjelpe oss med infrastrukturforsyning, som har vært en kjedelig og tidkrevende oppgave siden dagene med private datasentre. Men med mer og mer adopsjon av sky, blir infrastruktur ofte sett på som en disponibel og repeterbar konstruksjon. Dette kan imidlertid bare oppnås hvis vi har det et verktøy som vi kan definere enkel til kompleks infrastruktur deklarativt med og lage den ved å klikke på en knapp. Det kan høres ut som en drømmesekvens, men Terraform prøver aktivt å bygge bro over det gapet!

6.5. Overvåkning

Endelig er det viktig å kunne observere distribusjonen og måle den mot målene. Det kan være en rekke beregninger vi kan samle inn fra systemer og applikasjoner. Disse inkluderer noen av forretningsberegningene som er spesifikke for søknaden vår.

Tanken her er å kunne samle, kuratere, lagre og analysere disse beregningene i nesten sanntid. Det er flere nye produkter, både åpen kildekode og kommersielle, som er tilgjengelige i dette området.

Elastic-Logstash-Kibana (ELK) er en stabel med tre open source-prosjekter - Elasticsearch, Logstash og Kibana. Elasticsearch er en svært skalerbar søke- og analysemotor. Logstash gir oss en databehandlingsrørledning på serversiden som kan konsumere data fra et bredt utvalg av kilder. Til slutt hjelper Kibana oss med å visualisere disse dataene. Sammen kan denne stakken være brukes til å samle data som logger fra alle applikasjonene og analysere dem i sanntid.

Prometheus er et open source-systemovervåking- og varslingsverktøy opprinnelig utviklet av SoundCloud. Den leveres med en flerdimensjonal datamodell, et fleksibelt spørrespråk og kan trekke tidsseriedata over HTTP. Grafana er en annen analyse- og overvåkingsløsning med åpen kildekode som fungerer med flere databaser. Sammen kan Prometheus og Grafana gi oss et sanntids håndtak på stort sett alle beregninger som systemene våre kan produsere.

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

Vi har sett at DevOp i utgangspunktet er et kontinuerlig forsøk på å fjerne hindringer mot raskere og iterativ verdibasert levering av programvare. Nå er en av de umiddelbare konklusjonene at det ikke kan være en sluttstat her.

Det folk skjønte som friksjon mellom utviklings- og driftsteam er ikke den eneste friksjonen. Å bryte siloer i en organisasjon for å øke samarbeidet er den sentrale ideen. Nå begynte folk snart å innse det lignende friksjoner eksisterer mellom utviklings- og testteam, og mellom utviklings- og sikkerhetsteam. Mange tradisjonelle oppsett har dedikerte sikkerhets- og ytelsesteam.

Det fulle potensialet til DevOps kan aldri realiseres før vi kan bryte nesten alle grenser mellom lag og hjelpe dem å samarbeide mye mer effektivt. Dette iboende betyr å bringe team som testing, sikkerhet og ytelse inn i folden.

Forvirringen er i stor grad i nomenklaturen. DevOps får oss til å forstå at det mest handler om utviklings- og driftsteam. Over tid har det derfor dukket opp nye vilkår som omfatter andre lag. Men stort sett er det bare DevOps som blir realisert mer effektivt!

7.1. DevTestOps

Hjørnesteinen i DevOps er levere programvare av høy kvalitet i små trinn og oftere. Det er mange aspekter ved vektlegging av kvalitet her. På en måte antar vi ofte at DevOps-praksisene vi bruker vil hjelpe oss med å oppnå dette. Og det er også sant at mange av praksisene vi diskuterte tidligere fokuserer på å sikre høy kvalitet til enhver tid.

Men funksjonell testing av programvare har et mye bredere omfang. Ganske ofte har vi en tendens til å beholde testing av høyere ordre som end-to-end-testing mot slutten av programvarelevering. Enda viktigere, dette er ofte ansvaret til et eget team som engasjerer sent i prosessen. Det er her ting begynner å avvike fra DevOps-prinsippene.

Det vi heller burde gjøre er å integrere programvaretesting på alle nivåer helt fra begynnelsen. Helt fra planleggingsfasen bør testing av programvare betraktes som et integrert aspekt ved levering. Videre bør det samme teamet være ansvarlig for å utvikle og teste programvaren. Dette er hva praksis med DevTestOps er allment kjent som. Dette blir ofte også referert til som kontinuerlig testing og skifting til venstre.

7.2. DevSecOps

Sikkerhet er en integrert del av programvareutvikling og har sin andel av kompleksitet. Dette betyr ofte at vi har et eget team av sikkerhetsspesialister som vi samarbeider med rett når vi er klare til å sende produktet. Sårbarhetene de identifiserer på dette stadiet kan være kostbart å fikse. Dette stemmer igjen ikke godt overens med prinsippene til DevOps.

På dette tidspunktet skal vi allerede ha den løsningen vi trenger å bruke, og det er det vi burde få med deg sikkerhetsproblemer og personell tidlig i spillet. Vi bør motivere team til å tenke på sikkerhet på alle trinn. Sikkerhet er uten tvil et veldig spesialisert domene, og derfor kan det hende vi trenger å hente inn en spesialist i teamet. Men ideen her er å vurdere noen av de beste metodene helt fra begynnelsen.

Når vi beveger oss, er det flere tilgjengelige verktøy som kan automatisere skanning etter en stor del av sårbarhetene. Vi kan også koble dette til kontinuerlige integrasjonssykluser for å få rask tilbakemelding! Nå kan vi ikke integrere alt i den kontinuerlige integrasjonen, ettersom vi må holde det lett, men det kan alltid være andre periodiske skanninger som kjører separat.

8. Konklusjon

I denne artikkelen gikk vi gjennom det grunnleggende om DevOps-prinsipper, praksis og verktøy som er tilgjengelige for bruk. Vi forsto konteksten der DevOps er relevant og årsakene det kan være til nytte for oss. Vi diskuterte også kort hvor du skal begynne i reisen med å adoptere DevOps.

Videre berørte vi noen av de populære metodene og verktøyene som er tilgjengelige for oss å bruke på denne reisen. Vi forsto også noen av de andre populære begrepene rundt DevOps som DevTestOps og DevSecOps.

Til slutt må vi forstå at DevOps ikke er en sluttstat, men snarere en reise som kanskje aldri blir ferdig! Men den morsomme delen her er selve reisen. Hele tiden må vi aldri miste målene våre, og vi bør fokusere på de viktigste prinsippene. Det er ganske enkelt å falle for glansen av et populært verktøy eller begrep i bransjen. Men vi må alltid huske at alt bare er nyttig hvis det hjelper oss å levere verdi til publikum mer effektivt.