Tidligere har vi Continuous Integration (CI). Vi fortsetter med Continuous Delivery. Dette er et sett med metoder for programvareutvikling. Det hjelper med å sikre at koden er klar for distribusjon.
/ Pixabay / /
Historie
Uttrykket continuous delivery kunne allerede sees i fra 2001 i begynnelsen av listen over grunnleggende prinsipper: «Prioritet er å løse kundens problemer gjennom kontinuerlig levering av relevant programvare».
I 2010 ga Jez Humble og David Farley ut om Continuous Delivery. Forfatterne mente at CD supplerer tilnærmingen og gjør det lettere å forberede koden for distribusjon.
Etter publiseringen av boken begynte tilnærmingen å få fotfeste, og på bare noen få år ble den nesten allment akseptert. Ifølge , utført blant mer enn 600 utviklere og IT-ledere i 2014, var 97 % av tekniske ledere og 84 % av utviklerne kjent med Continuous Delivery.
For øyeblikket forblir denne tilnærmingen en av de mest populære. Ifølge en studie fra 2018, som involverte IT-fellesskapet DevOps and Jenkins Community, halvparten av mer enn tusen respondenter.
Hvordan Continuous Delivery fungerer
Grunnlaget for CD er at koden er klar for distribusjon. For å oppnå dette brukes automatisering av programvareforberedelsesprosessen før utgivelse. Det må være standardisert for ulike utviklingsmiljøer, noe som kan hjelpe med å oppdage svakheter raskere og optimalisere dem. For eksempel ved å akselerere testing.
Et eksempel på en Continuous Delivery-prosess ser slik ut:

Hvis de første to trinnene automatiseres av tilnærmingen Continuous Integration, så er de neste to – Continuous Delivery. Stabiliteten i prosessen sikres også gjennom De overvåker endringer i infrastruktur, databaser og avhengigheter. Selve distribusjonen kan være automatisert, eller den kan utføres manuelt.
Prosessen stiller følgende krav:
- Tilgjengelighet av informasjon om beredskapen for å gå inn i produksjonsmiljøet og beredskap for umiddelbar utgivelse (CD-verktøy tester koden og gir mulighet til å vurdere effekten av endringene i utgivelsen).
- Felles ansvar for det endelige produktet. Produktteamet — ledere, utviklere, testere — fokuserer på resultatet, og ikke bare på sine egne ansvarsområder (resultatet er en fungerende utgivelse som er tilgjengelig for produktets brukere).
I CD brukes vanligvis , og for å samle tilbakemeldinger fra kunder — prinsippet om . En ny funksjon slippes først til en liten gruppe brukere — deres erfaring med produktet hjelper med å finne svakheter og feil som ikke ble oppdaget under intern testing.
Hva er fordelene med
Continuous Delivery forenkler distribusjonen av kode, noe som har en positiv effekt på produktiviteten og reduserer risikoen for emosjonell utmattelse blant ansatte. Til slutt reduserer dette også de totale utviklingskostnadene. For eksempel hjalp CD et av HPs team med å disse kostnadene med 40%.
I tillegg — ifølge en undersøkelse fra 2016 (side 28 ) — var selskaper som implementerte CD, 50% raskere til å løse problemer med IT-sikkerhet sammenlignet med de som ikke bruker tilnærmingen. I viss grad kan dette forskjellen forklares med bruken av automatiseringsverktøy.
En annen fordel er akselerasjon av utgivelsene. I det finske utviklingsstudioet hjalp kontinuerlig levering øke kodesamlingen med 25%.
Potensielle utfordringer
Det første og viktigste problemet er behovet for å omstrukturere vante prosesser. For å vise fordelene med den nye tilnærmingen, bør overgangen til CD skje gradvis, og starte med de minst ressurskrevende applikasjonene.
Det andre potensielle problemet er det store antallet kodegrener. Følgene av "branching" er hyppige konflikter og tap av tid. En mulig løsning er tilnærmingen .
. I noen selskaper oppstår hovedproblemene med testing — det tar for lang tid. Testresultatene må ofte analyseres manuelt, men en mulig løsning kan være å kjøre tester parallelt i de tidlige fasene av CD-implementeringen.
Det er også viktig å lære de ansatte å bruke de nye verktøyene — et tidlig kurs vil spare utviklerne for krefter og tid.

/ Flickr / /
Tools
La oss se på noen åpne verktøy for Continuous Delivery:
- — server for continuous delivery on Java and JRuby on Rails. Allows you to control the entire application delivery process: build—test—release. The tool is distributed under the Apache 2.0 license. You can find .
- — framework for creating scripts that automate the deployment of applications on Ruby, Java, or PHP. Capistrano is capable of executing commands on a remote machine by connecting through SSH. It works with other continuous integration and delivery tools, such as the CI server Integrity.
- — multiplatform tool that automates the entire application development cycle. Gradle works with Java, Python, C/C++, Scala, and more. It has integration with Eclipse, IntelliJ, and Jenkins.
- — a platform for CD written in Go. Drone can be deployed on-premise or in the cloud. The tool is built on containers and uses YAML files for managing them.
- — platform for continuous code delivery in multicloud systems. Developed at Netflix, with significant contributions from Google engineers. You can find the installation guide on the .
What to read in our corporate blog:
Kilde: habr.com
