LFCA: Lær de grunnleggende konseptene til DevOps – Del 21

DevOps har vært et populært tema i en stund nå og har klart å trekke oppmerksomheten til både teknologifagfolk og bedrifter. Som nybegynner kan det være utfordrende å legge hodet rundt konseptet DevOps, og i dette emnet vil vi utdype de grunnleggende konseptene til dette internett-buzzwordet.

Til å begynne med er DevOps en samling av to ord: utvikling og drift. Det er et sett med praksiser og verktøy som fremmer samarbeid mellom utviklingsteam (Devs) og operasjoner (Ops). Målet med DevOps er å effektivisere livssyklusen for programvareutvikling, minimere feilfrekvensen, skalere opp frekvensen av distribusjoner og oppnå programvare av høy kvalitet.

For å få en bedre forståelse av DevOps i dagens moderne IT-miljø, la oss ta en titt på hvordan distribusjonsmodellen var før DevOps kom.

Tradisjonell IT-praksis

Før DevOps brukte utviklingsteam og QA-ingeniører den klassiske fossefallsmodellen. Arbeidslandskapet var stort sett tullet og testing og distribusjon av applikasjoner skjedde i fullstendig isolasjon. Dette resulterte i pliktoverlappinger, hull, forsinkelser i tilbakemeldinger og annen ineffektivitet som krevde ekstra tid for å fullføre prosjektet. Begrensede og forsinkede tilbakemeldinger gjorde at kvaliteten på programvaren ikke ble grundig revidert før i siste utviklingsfase.

I tillegg ble manuell distribusjon av kode forårsaket av menneskelige feil og krevde derfor mer tid i å feilsøke applikasjoner. Dessuten hadde forskjellige team forskjellige tidslinjer for å fullføre oppgavene sine, og det var ikke uvanlig at tidslinjene falt ut av synkronisering, noe som førte til ytterligere forsinkelser i realiseringen av det endelige produktet.

Konseptet med DevOps ble unnfanget en gang mellom 2007 og 2010 av to utviklere: Andrew Shafer og Patrick Debois. Siden oppstarten har det fremmet jevnt samarbeid mellom drifts- og utviklingsteam i hvert trinn av programvareutviklingens livssyklus. Dette varslet nye konsepter som Continuous Integration (CI) & Continuous Delivery (CD) og mange andre som bidrar til rask programvarelevering.

DevOps-modell og -praksis

DevOps handler ikke bare om samarbeid og å ha den rette tankegangen for å nå et mål. Den omfatter beste praksis som er rettet mot å levere kvalitets- og markedsklar programvare på kortest mulig tid. La oss ta en titt på noen av disse beste fremgangsmåtene som vil hjelpe deg med å øke effektiviteten og rask levering av kode.

Kontinuerlig integrasjon er en programvareutviklingspraksis der utviklere slår sammen kodeendringer til ett sentralt depot. Deretter utføres automatiserte tester og bygg på koden. Målet med kontinuerlig integrasjon er å øke hastigheten på feilsøking av applikasjoner, redusere tiden det tar å slippe nye programvareoppdateringer og forbedre programvarekvaliteten.

Kontinuerlig levering (CD) er nok en praksis der endringer i kode bygges automatisk og distribueres for kraftig testing. Senere blir automatiserte tester utført mot den distribuerte koden for å la utviklerne identifisere og fikse feilene. Vanligvis blir koden gradvis utsatt for flere testmiljøer hvor koden oppnår det høyeste kvalitetsmerket gjennom en standard automatisert prosedyre.

Populære CI/CD-verktøy inkluderer Jenkins, Travis CI, Circle CI, Azure DevOps og AWS Code build.

Målet med kontinuerlig testing er å identifisere feil og potensielle risikoer i de tidlige stadiene av programvareutviklingens livssyklus for å minimere feil som vil manifestere seg i sluttproduktet. Når koden mislykkes i de kraftige testene, sendes den vanligvis tilbake til utvikleren for revisjon før den sendes videre til kvalitetssikringsavdelingen for evalueringer og funksjonstesting. Mye brukte kontinuerlige testverktøy inkluderer Travis og Selenium.

Som du forventer, krever applikasjoner og den underliggende infrastrukturen kontinuerlig overvåking for å sjekke ytelsesidentiteten deres, eventuelle feil eller mangler, og sikre samsvar med ulike industristandarder. Et bredt utvalg av beregninger overvåkes, inkludert:

• Minne og CPU-bruk
• Diskplassbruk
• Båndbreddeutnyttelse
• Kundeinteraksjon

Ved å overvåke og analysere data og logger generert av applikasjoner, kan utviklere enkelt få innsikt i hvordan funksjoner eller konfigurasjoner påvirker brukerne. I tillegg vil konfigurering av varsler hjelpe deg med å identifisere feil eller uønskede endringer hvert trinn på veien. Til syvende og sist sikrer kontinuerlig overvåking den høye tilgjengeligheten av applikasjoner og inspirerer til tillit til at ting fungerer som forventet.

Populære overvåkingsverktøy inkluderer Prometheus, Netdata for å nevne noen.

Forkortet til IaC, er Infrastructure as Code beskrevet som distribusjon og administrasjon av ressurser som virtuelle servere og lastbalansere ved bruk av maskinlesbare konfigurasjonsfiler i motsetning til interaktive konfigurasjonsverktøy. Dette er spesielt viktig i skymiljøer som AWS hvor du enkelt kan spinne opp databehandlingsforekomster ved å definere detaljene til forekomsten i en konfigurasjonsfil og bruke verktøy som Terraform for å distribuere ressursene.

For eksempel tilbyr Amazon AWS API-er som lar brukere programmere samhandle med Cloud-plattformen fra kommandolinjen. Dette letter rask distribusjon av ressurser ved å eliminere manuelle prosesser og slakk. Enkelt sagt, IaC får gjort mer arbeid på kort tid.

Mikrotjenester-arkitektur er der en enkelt applikasjon er en integrasjon eller en sammenslåing av forskjellige mindre løst koblede tjenester. Hver tjeneste kjører uavhengig og kommuniserer med resten av applikasjonene ved hjelp av HTTP-baserte APIer. Mikrotjenester kan distribueres som en gruppe tjenester eller en enkelt tjeneste

Microservices-arkitektur er mye forskjellig fra tradisjonell monolittisk arkitektur. I den tradisjonelle arkitekturen er applikasjonene enkeltlagde og alle komponenter, inkludert koden og brukergrensesnittet, er samlet i ett enkelt program.

Mikrotjenester forenkler uavhengig distribusjon og administrasjon av ressurser. De sikrer også høy tilgjengelighet ved å forhindre et enkelt feilpunkt. når et enkelt program krasjer, vil resten fortsette å kjøre.

Fordeler med DevOps-modellen

Etter å ha sett på DevOps beste praksis, la oss nå fokusere på fordelene ved å ta i bruk DevOps-modellen.

Samarbeid mellom utviklings- og driftsteam oversettes til felles ansvar, som til slutt øker produktiviteten og fremmer teamengasjement.

Samarbeid gjør det også mulig for team å enkelt feilsøke kode på alle trinn før de kommer til sluttfasen. Dette gir høykvalitets og markedsklar programvare.

Applikasjonsdistribusjon er mer strømlinjeformet og mye raskere takket være automatiseringsverktøyene som DevOps tilbyr (som Ansible, Chef og Puppet) og avansert kontinuerlig integrasjon (CI).

Siden produktkunnskapen er spredt på tvers av ulike avdelinger, er det et klart mål og en visjon om produktet, noe som betyr bedre beslutningstaking i alle utviklingsstadier

Den inngrodde troen på at utviklings- og driftsteam for alltid må jobbe hver for seg er lenge utdatert og mangler. Den siled filosofien kan fortsatt være levende i noen bransjer, men dette har resultert i grelle ineffektivitet underveis.

DevOps søker å integrere utviklings- og driftsteam og fremme et kulturskifte fra den gamle måten å jobbe i siloer til å jobbe i tandem for å redusere feil i kode, forbedre kvaliteten på programvaren, raskere leveringstider og øke den generelle produktiviteten. Til syvende og sist ender sluttbrukeren opp med et produkt av høy kvalitet i tide.