INSIGHT
Agila team behöver agil infrastruktur
Agila processer, DevOps och Continuous Delivery skapar en ny dynamik i förhållandet mellan mjukvaruutveckling, livscykelhantering av applikationer och IT-förvaltning (så kallad ITSM eller IT Service Management). De här innovationerna ställer därför nya krav på både infrastrukturen och berörda IT-förvaltningsteam. Agila team behöver nämligen agil infrastruktur.
Den uppsättning mjukvara som krävs för att uppnå Continuous Delivery är numera väldigt komplex. Den innehåller allt från källkodshantering via build-system och artefakt-lagring till automatiserad testning och leverans, från utvecklings- och testmiljöer till produktion. Varje element måste kontrolleras på bästa möjliga vis.
Om utvecklare själva får hantera de här utmaningarna kommer lösningen ofta att anpassas efter ett specifikt projekt eller team. För att skapa lösningar som kan återanvändas i hela din portfölj måste IT-förvaltningsexperter vara involverade redan i ett tidigt skede.
Faktum är att mjukvarusviter alltmer utgör egna små infrastruktur-universum. Om utvecklare paketerar applikationer i Docker-containrar kommer IT-förvaltningen att påverkas av det. Effekten blir ännu större om man implementerar containrarna via en Cluster Management-lösning som exempelvis Kubernetes. Man får då automatisk skalning (auto-scaling), service discovery (sökning efter olika enheter och tjänster på ett nätverk), belastningsbalansering (load balancing), rullande uppgraderingar (uppdateringar som inte kräver att systemet ligger nere) och så vidare, och automatiserar på vis det som tidigare krävde manuell IT-förvaltning.
För att stödja sådana processer måste man skapa en väloljad och finjusterad produktionslinje – som kan säkerställa automatiserad kvalitetssäkring från de första stadierna av systemutvecklingen till de sista stadierna av leveransfasen. Det går inte att uppnå om inte ditt IT-förvaltningsteam arbetar nära dina utvecklare. Utan ett välinformerat och aktivt involverat förvaltningsteam kommer en agil process sällan att nå sin fulla potential.
Det handlar om människor och organisation – utöver teknik
Uppgraderingen till Continuous Delivery påverkar inte bara dina utvecklare och IT-förvaltare, utan hela IT-området: från management-nivån till databasadministratörerna, affärsanalytikerna, era UX-designers och QA-experter – med andra ord alla olika kompetenser som är involverade i produktionen av er lösning. Om er nuvarande utveckling, kvalitetssäkring och operativa verksamhet arbetar i egna silos kommer det även att uppstå problem däremellan. Utvecklare fokuserar gärna på att ta fram nya funktioner – alltså för att uppnå förändring – medan operativ verksamhet strävar efter att systemen ska fungera stabilt, och vill därför helst undvika förändringar.
Målet med er interna revolution är att uppnå repeterbara processer som kan återanvändas gång på gång, och att förkorta de cykler som krävs för att implementera nya funktioner i produktionen.
Från Continuous Integration till Continuous Delivery
Agila processer med Continuous Integration och testdriven och agil mjukvaruutveckling växte fram på 90-talet. Genom att skapa backloggar med listor på olika uppgifter strävar det agila arbetssättet efter att lansera nya funktionella versioner av mjukvaran i slutet av varje sprint. Sprintarna varar normalt i en eller två veckor, ibland längre än så. Det här innebär att ert utvecklingsteam i slutet av varje sprint kan leverera en ny version av mjukvaran till era QA-experter och er operativa personal.
Så småningom utvecklades Continuous Integration och blev allt en mer automatiserad process. Med hjälp av build-system som Jenkins och TeamCity kunde utvecklare automatisera enhets- och funktionstester. Vid det laget kändes drömmen om Continuous Delivery som realistisk.
De flesta organisationer var dock, och är än idag, inte redo för den här förändringen. Hittills har bara den första delen, utvecklingsfasen, blivit agil på riktigt. De flesta organisationer har fortfarande vattentäta skott mellan utveckling, kvalitetssäkring och operativ verksamhet. Det här leder till att man fortfarande använder vattenfallsmodellen mellan utvecklings- och produktionsfaserna. Varje fel som påträffas under integrationstesterna kräver sedan ytterligare en sprint på en eller flera veckor.
Release management är fortfarande viktigt
Continuous Delivery innebär i teorin att du kan släppa nya versioner varje dag, när utvecklarna implementerar sina kodändringar. Det är dock sällan vad man vill försöka uppnå.
En ny release måste nämligen uppfylla även andra kriterier. Du måste väga in organisationens marknadsföringsstrategier, eventuella avtalsmässiga begränsningar och andra icke-tekniska aspekter av releasen. Continuous Delivery betyder helt enkelt att du har möjlighet att släppa nya releaser varje gång utvecklare implementerar ny kod.
För att uppnå en perfekt fungerande Continuous Delivery måste du dessutom samla in data och mätvärden för att optimera ditt flöde av nya funktioner. Bra kvalitetsdata och tillräckligt med metadata hjälper dina icke-tekniska team att avgöra när en levererad mjukvara är redo att släppas.
På Ductus har vi lyckats synkronisera våra systemutvecklings- och IT-förvaltningsteam för att uppnå en snabbare och säkrare leverans av tjänster. Vi delar gärna med oss av våra erfarenheter. Läs mer om våra DevOps-infrastrukturtjänster och låt våra experter hjälpa dig med dina DevOps- och Continuous Delivery-kanaler.