Referens: vad Àr Continuous Delivery

Tidigare berÀttade vi om vilka studier som ligger bakom de populÀra rÄden om hur man 'lÀr sig att lÀra sig'. om Continuous Integration (CI). Vi gÄr vidare med Continuous Delivery. Det hÀr Àr en uppsÀttning metoder för mjukvaruutveckling. Den hjÀlper till att sÀkerstÀlla att koden Àr redo för distribution.

Referens: vad Àr Continuous Delivery
/ Pixabay / bluebudgie / PL

Historien

Uttrycket continuous delivery kunde ses redan i agile-manifestet frÄn 2001 i början av listan över grundlÀggande principer: "Prioritet Àr att lösa kundens problem genom kontinuerlig leverans av aktuell mjukvara."

År 2010 publicerade Jez Humble och David Farley bok om Continuous Delivery. Enligt författarna kompletterar CD-ansatsen Continuous Integration och möjliggör en enklare förberedelse av koden för distribution.

Efter publiceringen av boken började ansatsen vinna popularitet och pÄ bara nÄgra Är blev den i princip allmÀnt accepterad. Enligt en undersökning, som genomfördes bland mer Àn 600 utvecklare och IT-chefer Är 2014, var 97% av tekniska chefer och 84% av programmerarna bekanta med Continuous Delivery.

Idag förblir denna ansats en av de mest populÀra. Enligt en studie frÄn 2018, dÀr det IT-specialistiska samhÀllet DevOps och Jenkins Community deltog, var dess anvÀnder hÀlften av mer Àn tusen tillfrÄgade respondenter.

Hur Continuous Delivery fungerar

Grunden för CD Àr att koden Àr redo för distribution. För att uppnÄ detta anvÀnds automatisering av processen för att förbereda mjukvara för release. Den ska vara standardiserad för olika utvecklingsmiljöer, vilket hjÀlper till att snabbare identifiera svagheter och optimera dem. Till exempel, att snabba upp testningen.

Ett exempel pÄ processen för Continuous Delivery ser ut pÄ följande sÀtt:

Referens: vad Àr Continuous Delivery

Om de första tvÄ stegen automatiseras genom Continuous Integration, sÄ ansvarar Continuous Delivery för de följande tvÄ. Stabiliteten i processen sÀkerstÀlls delvis genom konfigurationshanteringssystem. De övervakar förÀndringar i infrastrukturen, databaser och beroenden. SjÀlv distributionen kan automatiseras eller ske manuellt.

Kraven pÄ processen Àr följande:

  • TillgĂ„ng till information om beredskapen för att gĂ„ till produktionsmiljö och beredskap för omedelbar release (CD-verktyg testar koden och möjliggör att bedöma effekten av förĂ€ndringar i releasen).
  • Övergripande ansvar för den slutliga produkten. Produktteamet – chefer, utvecklare, testare – fokuserar pĂ„ resultatet, inte bara pĂ„ sitt eget ansvarsomrĂ„de (resultatet Ă€r en fungerande version som Ă€r tillgĂ€nglig för produktens anvĂ€ndare).

I CD tillĂ€mpas vanligtvis code review, och för att samla in kunders Ă„sikter – principen dark launching. En ny funktion slĂ€pps först för en liten anvĂ€ndarsegment – deras interaktion med produkten hjĂ€lper till att upptĂ€cka brister och buggar som inte noterades under intern testning.

Vilken fördel ger

Continuous Delivery hjÀlper till att förenkla distributionen av kod, vilket positivt pÄverkar produktiviteten och minskar risken för anstÀlldas utbrÀndhet. Slutligen minskar detta ocksÄ de totala kostnaderna för utveckling. Till exempel har CD hjÀlpt ett av HP:s team att minska dessa kostnader med 40%.

Dessutom – enligt en studie frĂ„n 2016 (sida 28 Inkomststrukturen för PhD-studenter och Post-Docs pĂ„ EPFL) – löser företag som implementerat CD problem med IT-sĂ€kerhet 50% snabbare jĂ€mfört med dem som inte anvĂ€nder metoden. Till viss del kan denna skillnad förklaras av arbete med automatiseringsverktyg.

En annan fördel Àr att release-processen gÄr snabbare. I en finsk utvecklingsstudio har kontinuerlig leverans ökat hastigheten pÄ kodkompilering med 25%.

Potentiella svÄrigheter

Det första och viktigaste problemet Àr behovet av att omstrukturera befintliga processer. För att visa nyttan av den nya metoden bör man gradvis övergÄ till CD, börja inte med de mest tidskrÀvande applikationerna.

Det andra potentiella problemet Àr det stora antalet kodgrenar. Följden av «grenning» Àr frekventa konflikter och bortslösad tid. En möjlig lösning Àr metoden no branches.

. I vissa företag uppstĂ„r de största svĂ„righeterna med testning – det tar för mycket tid. Testresultat mĂ„ste ofta analyseras manuellt, men en möjlig lösning kan vara att parallellisera tester i de tidiga stegen av CD-implementeringen.

Man bör ocksĂ„ utbilda anstĂ€llda i hur man arbetar med de nya verktygen – en grundlig utbildning kan spara utvecklarnas kraft och tid.

Referens: vad Àr Continuous Delivery
/ Flickr / h.ger1969 / CC BY-SA

Verktyg

LÄt oss titta pÄ nÄgra öppna verktyg för Continuous Delivery:

  • GoCD — en server för kontinuerlig leverans pĂ„ Java och JRuby on Rails. Den möjliggör kontroll av hela leveransprocessen: build—test—release. Verktyget distribueras under Apache 2.0-licensen. PĂ„ den officiella webbplatsen kan man hitta en installationsguide.
  • Capistrano — ett ramverk för att skapa skript som automatiserar distribution av applikationer pĂ„ Ruby, Java eller PHP. Capistrano kan utföra kommandon pĂ„ en fjĂ€rrmaskin genom att ansluta via SSH. Det fungerar med andra verktyg för kontinuerlig integration och leverans, som CI-servern Integrity.
  • Gradle — ett plattformsoberoende verktyg som automatiserar hela apputvecklingscykeln. Gradle fungerar med Java, Python, C/C++, Scala och andra. Det finns integration med Eclipse, IntelliJ och Jenkins.
  • Drone — en plattform för CD skriven i Go. Drone kan distribueras on-premise eller i molnet. Verktyget Ă€r byggt pĂ„ containrar och anvĂ€nder YAML-filer för att hantera dem.
  • Spinnaker — en plattform för kontinuerlig leverans av kod i multicloud-system. Utvecklad pĂ„ Netflix, spelade ingenjörerna frĂ„n Google en stor roll i utvecklingen av verktyget. Installationsanvisningarna hittar du pĂ„ den officiella webbplatsen.

Vad att lÀsa pÄ vÄr företagsblogg:

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster