Software-deployment med plads til forbedring!
Når det kommer til deployment af software til test- og produktionsmiljøer, er der temmelig stor forskel på, hvordan forskellige firmaer gennemfører det og temmelig stor forskel på både indsats og succesrate.
Hos Openminds har vi gennem tiden set mange forskellige måder at deploye software på. Nogle bedre end andre.
De mest udbredte årsager til problemer er:
- Deploymentprocessen er en tung manuel proces, som tager lang tid.
- Deploymentprocessen er for kompliceret og svær at gennemføre.
- Deployment foretages direkte fra udviklingsværktøjerne (IDE’er).
- IT-systemer omkring deployment er manglefulde eller forældede.
Det fører til disse uønskede konsekvenser:
- Deployment foretages sjældent, fordi det er vanskeligt og fejlbehæftet.
- Deployment fejler tit, fordi det er svært at huske og følge deploymentprocessen.
- Den deployede software indeholder fejl, fordi softwaren ikke er testet godt nok (manglende regressionstest).
- Deployment kan kun udføres af nøglepersoner i virksomheden.
- Det er ikke muligt at sige præcist, hvilken software, der er blevet deployet.
- Det er ikke muligt at sige præcist, hvem der har foretaget et deployment.
- Det er ikke muligt at rulle tilbage til en tidligere version, hvis det nyeste deployment indeholder kritiske fejl.
Automatisering, automatisering og automatisering
Der er heldigvis bedre måder at gennemføre deployments på, så vi fjerner mange af problemerne helt.
Deploymentprocessen skal automatiseres, og det gør vi ved at etablere en bygge- og deployment-pipeline, også kaldt Continuous Integration eller Continuous Delivery (CI / CD).
Der findes forskellige produkter til at understøtte disse pipelines. Figuren nedenfor illustrerer det generelle princip for en pipeline med en byggeserver og en deploymentserver.
- Udviklerne committer kode til version control systemet (VCS).
- Byggeserveren trækker automatisk den nye kode ud og forsøger at bygge og teste softwarekomponenten. Hvis det fejler, modtager udvikleren automatisk en mail om fejlen. Det gentages, hver gang vi committer ny kode.
- Vi ”tagger” koden i VCS, så der er fuld sporbarhed fra kode til deployment.
- Hvis komponenten kan bygges og testes, gøres den tilgængelig for deploymentserveren, og en test eller release manager kan nu vælge at gennemføre deployment til de ønskede miljøer. Deployment gennemføres meget enkelt med et klik eller to.
- Deploymentserveren foretager nu automatisk deploy til de ønskede miljøer.
Ved at bruge en bygge- og deployment-pipeline opnår du en lang række fordele:
- Bygge- og deploymentprocessen er automatiseret og kan gentages igen og igen med samme resultat.
- Der foretages kontinuerligt test af den kode, udviklerne laver, og du kan opdage fejl tidligt.
- Softwarepakker er versionerede, og du kan deploye tidligere versioner.
Hos Openminds bruger vi ofte Octopus som deploymentserver. Det gør vi fordi
- Octopus understøtter roller og er rettighedsbaseret. Dermed kan vi give selve rettigheden til at foretage et deployment til udvalgte personer.
- Octopus kan ændre en softwarepakke og rette følsomt indhold som fx kodeord, certifikater mm. Følsomme data som kodeord kan krypteres i Octopus, så kun drift eller DevOps personale har adgang.
Så tag fat i os nu.