Tidligere vi om kontinuerlig integrasjon (CI). La oss fortsette med Kontinuerlig levering. Dette er et sett med programvareutviklingsmetoder. Det bidrar til å sikre at koden din er klar for distribusjon.
/Pixabay/ /
Story
Uttrykket kontinuerlig levering kunne sees tilbake i fra 2001 i begynnelsen av listen over grunnleggende prinsipper: "Prioriteten er å løse kundeproblemer gjennom kontinuerlig levering av oppdatert programvare."
I 2010 ga Jez Humble og David Farley ut ved kontinuerlig levering. I følge forfatterne utfyller CD tilnærmingen og lar deg forenkle forberedelsen av kode for distribusjon.
Etter utgivelsen av boken begynte tilnærmingen å få popularitet, og på bare et par år ble den nesten universelt akseptert. I følge , utført blant mer enn 600 utviklere og IT-ledere i 2014, var 97 % av tekniske ledere og 84 % av programmererne kjent med Continuous Delivery.
Nå er denne tilnærmingen fortsatt en av de mest populære. I følge en studie fra 2018 som involverer IT-fellesskapet DevOps og Jenkins Community, er det halvparten av de over tusen respondentene som ble spurt.
Hvordan fungerer kontinuerlig levering?
CD-grunnlaget er klarheten til koden for distribusjon. For å utføre denne oppgaven brukes automatisering av prosessen med å forberede programvare for utgivelse. Det bør være standard på tvers av ulike utviklingsmiljøer, noe som vil bidra til å raskt finne svake punkter og optimalisere dem. For eksempel fremskynde testingen.
Et eksempel på en kontinuerlig leveringsprosess ser slik ut:
Hvis Continuous Integration-tilnærmingen er ansvarlig for å automatisere de to første stadiene, er Continuous Delivery ansvarlig for de to neste. Prosessstabilitet sikres blant annet av systemer . De overvåker endringer i infrastruktur, databaser og avhengigheter. Selve distribusjonen kan automatiseres eller gjøres manuelt.
Følgende krav stilles til prosessen:
- Tilgjengelighet av informasjon om beredskap til å gå inn i produksjonsmiljøet og beredskap for umiddelbar utgivelse (CD-verktøy tester koden og gjør det mulig å evaluere effekten av endringer i utgivelsen).
- Overordnet ansvar for sluttproduktet. Produktteamet - ledere, utviklere, testere - tenker på resultatet, og ikke bare på deres ansvarsområde (resultatet er en fungerende utgivelse som er tilgjengelig for brukere av produktet).
I CD-er brukes det vanligvis , og for å samle kunders meninger - prinsippet . En ny funksjon er først utgitt til et lite segment av brukere - deres opplevelse av å samhandle med produktet hjelper til med å finne mangler og feil som ikke ble lagt merke til under intern testing.
Hva er fordelen
Kontinuerlig levering bidrar til å forenkle kodedistribusjon, noe som har en positiv innvirkning på produktiviteten og reduserer sannsynligheten for utbrenthet hos ansatte. Til syvende og sist reduserer dette de totale utviklingskostnadene. For eksempel hjalp CD et av HP-teamene slike kostnader med 40 %.
I tillegg, ifølge en studie fra 2016 (side 28 ) - selskaper som har implementert CD løser informasjonssikkerhetsproblemer 50 % raskere enn de som ikke bruker tilnærmingen. Til en viss grad kan denne forskjellen forklares med ytelsen til prosessautomatiseringsverktøy.
Et annet pluss er akselerasjonen av utgivelser. Kontinuerlig leveranse ved finsk utviklingsstudio øke kodemonteringshastigheten med 25 %.
Potensielle vanskeligheter
Det første og hovedproblemet er behovet for å gjenoppbygge kjente prosesser. For å vise fordelene med den nye tilnærmingen, er det verdt å bytte til CD gradvis, og starter ikke med de mest arbeidskrevende applikasjonene.
Det andre potensielle problemet er det store antallet kodegrener. Konsekvensen av "forgrening" er hyppige konflikter og ytterligere tap av mye tid. Mulig løsning - tilnærming .
Spesielt i noen selskaper oppstår hovedvanskene med testing - det tar for mye tid. Testresultater må ofte analyseres manuelt, men en mulig løsning kan være å parallellisere testene i de tidlige stadiene av CD-implementering.
Du bør også lære opp ansatte til å jobbe med nye verktøy - et foreløpig utdanningsprogram vil spare utviklere for krefter og tid.
/flickr/ /
Verktøy
Her er noen åpne verktøy for kontinuerlig levering:
- — server for kontinuerlig levering i Java og JRuby on Rails. Lar deg kontrollere hele applikasjonsleveringsprosessen: bygg – test – utgivelse. Verktøyet er distribuert under Apache 2.0-lisensen. Du finner den på den offisielle nettsiden .
- — et rammeverk for å lage skript som automatiserer distribusjonen av applikasjoner i Ruby, Java eller PHP. Capistrano er i stand til å utføre kommandoer på en ekstern maskin ved å koble til den via SSH. Fungerer med andre kontinuerlige integrerings- og leveringsverktøy, for eksempel Integrity CI-serveren.
- er et multiplattformverktøy som automatiserer hele applikasjonsutviklingssyklusen. Gradle jobber med Java, Python, C/C++, Scala osv. Det er integrasjon med Eclipse, IntelliJ og Jenkins.
- - CD-plattform på Go-språk. Drone kan distribueres på stedet eller i skyen. Verktøyet er bygget på toppen av containere og bruker YAML-filer for å administrere dem.
- — en plattform for kontinuerlig kodelevering i multiskysystemer. Utviklet av Netflix, spilte Google-ingeniører en stor rolle i utviklingen av verktøyet. Installasjonsveiledning .
Hva du kan lese på bedriftsbloggen vår:
Kilde: www.habr.com