Om du jobbar i IT-branschen eller samarbetar med den, som professionell, är du säkert redan bekant med termen DevOps, både i praktiken och i teorin. DevOps är förkortning för den IT-relaterade utvecklingsverksamheten. Men vet du vad termen kommer ifrån?

DevOps – En förkortning med många betydelser

Även om DevOps blir mer och mer erkänt över värden, är förkortningens innebörd fortfarande inte lika uppenbar som den borde vara för den breda massan. I den här artikeln kommer vi presentera flera synsätt kring ämnet.

Den här artikel fungerar som en introduktion i ämnet. I kommande artiklar kommer vi fokusera på hur ser på DevOps på Craftware och förklara hur vi arbetar enligt denna metod. Vad innebär förkortningen för oss i praktiken ur en rent teknisk synvinkel? Viken affärsnytta ger den våra kunder? Varmt välkommen till DevOps-världen.

 

DevOps är en kombination av drifttekniker och systemutvecklare

Vi kallar ett av våra synsätt det verktygsfokuserade. Men hur fungerar det? I sin enkelhet så finns det en anställd på företaget som är ansvarig för de verktyg som utvecklarna använder sig av i. Men, om de istället använder koden som lagringsplats, blir en DevOps-specialists uppdrag är att förbereda och konfigurera den. En person i denna position är vanligtvis hälften UNIX-specialist och hälften utvecklare (UNIX: Uniplexed Information and Computing System).

Vad syftar detta tillvägagångssätt till? Uppenbarligen, att avlasta utvecklare. Om de har en DevOps specialistsupport, kan de ta hand om bara vad de ska göra mot bakgrund av detta tillvägagångssätt, det vill säga att skriva en kod och förbereda efterföljande versioner av en app.

Var kom denna praxis i från? Främst, från det faktum att den bredare synen på DevOps, den vi använder på Craftware (läs mer om det nästa artiklar), är en kombination av systemutvecklare och drifttekniker, är mer utmanande att genomföra. Varje företag har inte resurser att tillgå de båda typerna inhouse. Därför är externa DevOps-specialister ofta en bekväm lösning. De gör livet enklare för de utvecklare som finns på plats, så att de får färre ansvarsområdet och inte behöver utvidga räckvidden för sina kompetenser. Och de verkliga fördelarna förklarar i detalj härnäst.

 

DevOps — mer än ett verktyg

Som vi tidigare berättade finns det ytterligare ett synsätt på DevOps – den mer holistiska, vilket främst avser arbetsmetoden. Den innebär den kontinuerliga utvecklingen av nya funktioner och effektivisering av det som tidigare implementerats.

Innan företag förstod innebörden av detta tillvägagångssätt, låg utveckling och drift ofta på separata enheter: på ena sidan arbetade de med nya utgåvor och på den andra fanns stöd för produktionsmiljön, problemlösning och åtgärdandet av buggar. Med tiden visade det sig att ett sådant tillvägagångssätt orsakar problem. Att utvecklare behövde ge sitt stöd till supportteamen var form av överföring av kunskap, vilket är logiken i utformningen och driften av dessa moment. Men risken att något missas på vägen är oundviklig. Det finns också en annan fråga: hur garanterar du att korrigeringar som gjorts i processen hamnar på rätt utvecklare i tid? Och att den rätta informationen hamnar på rätt utvecklare i första hand? Att samordna båda teamens uppgifter blev mer och mer komplicerat.

Utifrån dessa erfarenheter skapades DevOps-idén: ett enda team som tar hand om utveckling och drift samtidigt, genom att utveckla nya funktioner och åtgärdandet av buggar.

 

DevOps — fördelar för teamen blir fördelar för verksamheten

Hur drar teamen, det vill säga DevOps-teamen, nytta av genomförandet av detta tillvägagångssätt? Om kontinuiteten i kommunikationen bibehålls behöver du naturligtvis inte fokusera på samordning och att hålla ett öga på saker och ting för att inte missa relevanta detaljer. Du arbetar snabbare och mer effektivt. Vi ser vad vi behöver implementerar och hur, och detta säkerställer en full kontroll över projekten, förbättring av arbetsflöden och slutligen en högre produktkvalitet.

Hur ser kunden fördelarna? Först och främst blir de bara exponerade mot ett team, vilket är en viktig signal om att arbetet går smidigt. Men det finns andra vinster i DevOps-metoden, som att företaget inte behöver duplicera roller. Om du till exempel har en testare som behövs både i utvecklingen och i driften av verksamheten (om de fungerar som separata team) innebär det fler arbetstimmar som genererar högre kostnader. I DevOps-metoden kombinerar en anställd detta ansvar för båda områdena.

Ovanstående exempel visar att DevOps arbetsmetod inte endast berör utvecklare som många tidigare trodde. Den gäller för olika anställda som arbetar i projekten. Craftwares DevOps-teams som genomför projekt för kunder inom Salesforce är därför sådana ”multitaskingteam”, som ansvarar för både utveckling och drift i ett.

 

DevOps — en för alla, allt för en

Ibland möter vi en uppfattning som gör gällande att DevOps-konceptet innebär full utbytbarhet. Det anses då att, särskilt inom ”agile thinking”, alla teammedlemmar i ett DevOps-teamen är kapabla att ta över rollerna som någon annan har.

Enligt vår mening är detta alltför långsökt, fastän det är möjligt att uppnå det – men bara i viss mån. En utvecklare kan hantera testning, men kan en testare ersätta en utvecklare? Inte nödvändigtvis. Och hur är det med förfrågningar från användare som rör olika versioner av de produkter som finns i verksamheten? Återigen, i teorin kan en utvecklare ta hand om den begärda tjänsten. Men kommer de bästa utvecklarna och ta del av den kommunikationen med användarna? Alla utvecklare har inte personliga egenskaper som gör dem kvalificerade till denna position. Låt oss komma ihåg att specialiseringen är det som idag värderas högst. Renodlade experter inom vissa specifika områden är det som mest eftersöks. Vi förväntar oss helt enkelt inte att alla ska vet allt.

Så, hur bygger vi våra DevOps-teams på Craftware? Hur organiserar vi arbetet i dessa team? Vi kombinerar utveckling och drift, men skapar ändå roller i teamen baserat på medlemmarnas egna kompetensområden. Stödet som nämnts tidigare kan tjäna som exempel – vi delegerar dem som har mjuka färdigheter som god kundkontakt till dessa exakta uppgifter. Naturligtvis kan vår supportspecialist efter att ha fått en förfrågan från en användare göra en enkel förändring i systemet, men behöver för det inte vara en utvecklare.

Vill du ta reda på mer om våra DevOps-teams på Craftware kan ge fördelar till din organisation? Läs mer om det snart här på vår blogg.

Författare

  • Łukasz
  • Co-founder Craftware, Co-CEO Craftware
  • Łukasz har en examen från fakulteten inom elektronik- och informationsteknik vid Warszawas tekniska universitet. Han började sin karriär som utvecklare, och senare blev han chef för ett team av Java-utvecklare. Han är en av grundarna av Craftware, som grundades 2009. Sedan dess har han haft många olika roller – som analytiker, IT-arkitekt, utvecklare, managing partner. Sedan 2011 har han varit engagerad i utvecklingen av system baserade på Salesforce-plattformen som han värdesätter för sin förmåga att snabbt leverera fullskaliga lösningar. Han har också ett nära samarbete med affärspartnerna. Han brinner för Salesforce-tekniken och har deltagit flera gånger i Dreamforce i San Francisco, en av de största tech-konferenserna i världen. Han innehar flera certifikat som bekräftar hans kunskaper om Salesforce. Han har samarbetat både med företag och nystartade företag.

    Utanför sitt arbete brinner han för lagsporter och MMO-spel.

Redaktionell studie
Ania
Textrevision
Ola
Korrekturläsning
Olof
Översättningar
Gillade du min artikel?

I så fall bjuder jag gärna in dig till gruppen med de bäst informerade bloggläsarna. Gå med i vårt nyhetsbrev så kommer du inte att missa några nyheter.