Det optimala IT-utvecklingsteamet 9 - DevOps

Jag kom också in på de agila principerna och Scrum och hur du kan komma igång med att använda det i praktiken. Sen pratade jag lite om kommunikation, samarbete och hur viktigt det är att lära känna varandra. Efter det kom jag in på hur du kan implementera CI/CD-tänket i ditt team och hur det kan bidra till att teamets leveranser alltid är uppdaterade. Sen publicerade jag en artikel som handlade om konflikthantering och stressiga situationer, vad man kan göra för att förbereda sig på det och hur man kan hantera det på lite olika sätt. Efter det skrev jag lite om om hur du kan inventera ansvars- och kompetensområden på ett enkelt, men effektivt sätt. Och till sist skrev jag lite om hur du kan bedöma kunskapsnivåer inom olika kompetensområden. Nu har det blivit dags för den sista artikeln i serien där jag tänkte beskriva hur du kan implementera DevOps i teamet som på sätt och vis är ett sätt att knyta ihop säcken i den här serien.

Som jag tidigare har tjatat om i den här artikelserien är en av de viktigaste byggstenarna att skapa ett arbetsklimat där alla känner att de kan komma till tals utan att förlöjligas eller negligeras och en arbetsmiljö där det är högt i tak och där alla både kan ge och ta feedback. Om du lyckas med det konststycket i ditt team har du kommit väldigt långt på vägen. Så mitt råd till dig som läser den här artikeln är att öppna ditt sinne och testa mina enkla tips och metoder även om det kan kännas konstigt ibland. Så ta dig tid att gå tillbaka till artiklarna som handlar om teamwork och hur man enkelt kan få personer att skapa förtroende mellan varandra.

En viktig del i DevOps är att automatisera monotona, återkommande arbetsuppgifter som inte riktigt är lämpade för människor utan snarare för maskiner. Detta är inget nytt på något sätt... Strategiskt arbete i automatiseringens anda blomstrade redan under senare hälften av 1700-talet i samband med den industriella revolutionen där arbete inleddes med att automatisera textilindustrin med ”Spinning Jenny” som det första tydliga, konkreta exemplet.

Jag har ju tidigare skrivit lite om hur du kan automatisera stora delar av arbetet i ett IT-utvecklingsteam i samband med att jag var inne på CI/CD-processerna, men jag tycker det är viktigt att lyfta fram vikten av det här arbetet eftersom det är en grundläggande byggsten i samband med implementeringen av DevOps.

Två viktiga saker när du ska implementera DevOps är att du kan hantera versioner av olika saker som t.ex. dokument, konfigurationer, källkod, brandväggsregler med mera. Och för att lyckas med det kan du använda något av de smidiga verktyg som finns tillgängliga och som jag beskrivit i tidigare artiklar. Fördelen med att checka in och ut dokument är att du simulerar en väldigt förenklad databasmotor där du ständigt kan ha kontroll på incheckade versioner, vem som gjorde det och hur du enkelt kan backa tillbaka. I DB-världen är det inga konstigheter, transaktionsloggar har funnits länge, men i infrastrukturområdet är det fortfarande ganska nytt som koncept.

Infrastruktur har traditionellt bestått av hårda saker som t.ex. hubbar, switchar, routrar, servrar, lagringsnätverk, brandväggar, lastbalanserare och så vidare. Men med dagens tekniker finns det möjlighet att virtualisera stora delar av infrastrukturen så att du slipper tänka på den i termer av hårdvara utan i stället kan fokusera på tjänsten som erbjuds och vilken affärsnytta den erbjuder.

Verktyg för att abstrahera infrastruktur och omvandla den från hårdvara till text finns tillgängliga redan idag och rekommenderas varmt till dig som vill komma ifrån hårdvaruberoendet. Jag har tidigare nämnt produkter som Kubernetes och OpenShift och hur de kan underlätta din vardag som Team Leader eller Product Owner. Plötsligt kan du slippa bry dig om hur hårdvara ska dimensioneras och fokusera på vilka tjänster som ska erbjudas och vilka krav de ska uppfylla.

En viktig sak att tänka på är att många kommer från en mer traditionell bakgrund inom IT-branschen. Med tanke på det blir det väldigt viktigt att förklara varför DevOps ska anammas överhuvudtaget i teamet och vad vi har att vinna på det. Det finns en fara med att börja låta utvecklare ta över mer och mer från systemadministratörerna och lära upp dem hur de ska konfigurera system, skapa utvecklingsmiljöer, administrera rättigheter mm Faran är nämligen att utvecklarna drunknar i administrativa arbetsuppgifter när de egentligen borde lägga resurser på att utveckla produkten. Jag har sett flera exempel på att utvecklare överutnyttjas som systemadministratörer när de egentligen borde fokusera på det de gör bäst, nämligen att skriva kod.

Med det sagt så vill jag bara att du är uppmärksam på faran med att driva DevOps alltför långt och att det har en tendens att tippa över på aningen för mycket Ops…

Traditionella systemadministratörer kommer ändå alltid att behövas för den bakomliggande hårdvaran där allting ska köras. Även om du lägger alla dina applikationer i publika molntjänster finns det ju fortfarande människor som sköter om den hårdvaran även om du kanske inte har dessa resurser i ditt team.

Ytterligare ett sätt att abstrahera och virtualisera hårdvarunivån är att nyttja molntjänster i olika former. Du kan t.ex. välja att lägga alla företagets applikationer i en publik molntjänst som t.ex. AWS, GCP eller Azure, men det finns ju också andra varianter som att köra ett private cloud där du håller allting inom företaget eller en hybridvariant där en del ligger hos dig och en annan del i en publik molntjänst.

Oavsett vad du väljer att göra är detta också en viktig komponent i DevOps-tänket och underlättar samverkan mellan ’DEVelopment’ och ’OPerations’. Traditionellt har det varit lite av olika världar det här med utvecklarmiljöer och systemadministratörer där bägge läger har haft en tendens att skylla på varandra så fort något går fel. DevOps är ett sätt för dessa områden att närma sig varandra och få en bättre förståelse för de krav/behov/önskemål som finns inom respektive område. Med en molntjänst blir det också enklare att behandla betydligt mer saker som kod som kan checkas in och versionshanteras på olika sätt.

Denna artikel är den sista i min serie som handlar om att sätta upp det optimala IT-utvecklingsteamet och jag hoppas verkligen att den har gett dig värdefulla tips, råd och insikter i vad som kan vara viktigt att tänka på när du ska samla ihop ett team och försöka få ut så mycket som möjligt av det. Jag har också en del idéer om framtida artikelserier, men jag tar gärna emot tips, idéer och önskemål om vilka ämnen som kan vara intressanta. Skicka gärna iväg en blänkare via vårt kontaktformulär så lovar jag att återkoppla så snart som möjligt.