Välkommen till ytterligare en artikel från vår serie dedikerad till utveckling och drift. I den föregående skrev vi om hur olika DevOps-synsätt fungerar när vi genomför IT-projekt. En av dem, som jag kallar helhets-synsättet, innebär att en arbetsmetod där ett enda team skapar nya funktioner och löser incidenter. På Craftware utövar vi den här metoden – det är så vi genomför projekt för våra kunder.

DevOps – varför lönar det sig?

Vi är inte bara utövare utan också entusiaster av DevOps-tillvägagångssättet som nämns ovan. Men när vi rekommenderar det till klienter måste vi ofta utgå ifrån grunderna, det vill säga från att förklara vad denna metod exakt handlar om. Vad betyder det exakt att vi kombinerar utveckling och driftstöd med ett enda team och arbetar parallellt inom båda områdena?

Innan vi utforskar DevOps olika delar, låt mig förklara vad den används till och i vilket syfte. Enligt vår mening är denna aspekt inte mindre betydelsefull än den tekniska bakgrunden, och svaret är mycket tydligare än det kan tyckas. DevOps ökar teamets effektivitet och det hjälper till att lösa det eviga problemet som vi står inför i IT-projekt: produktionsmiljöns beroende av nya utgåvor. När processen fungerar smidigt släpper vi en ny version till produktionen eftersom vi inte väntar på att incidenterna ska åtgärdas tills det att arbetet med de nya funktionerna är över. Om vi ​​får in några rapporter, reagerar vi på dem och åtgärdar dem fortlöpande.

Det är möjligt tack vare användningen av datalagring med en kontinuerlig integration. Det gör det möjligt att hantera tillhandahållandet av ytterligare funktioner för att minimera manuellt arbete och därmed minska risken för misstag och skillnader mellan de olika miljöerna. Alla som har erfarenhet av att arbeta med ett IT-projekt vet hur det här jobbet ofta ser ut: olika miljöer där du implementera förändringar som inte syns i de andra miljöerna och något går förlorat på vägen.

När ett projekt genomförs enligt kontinuerlig integrationsstrategi behöver vi inte vänta tills det att en utvecklare trycker in koden på en server. Det är vad verktygen är för (till exempel Jenkins-server). Automation ger oss en driftskontinuitet och full kontroll över projekten.

Det låter kanske ganska tekniskt. Men låt mig fråga om fördelarna med att implementera DevOps bara känns av för utvecklare och administratörer? Nej, och detta är något vi påpekar under samtal med kunder: fördelarna syns också i verksamheten i stort. När vi presenterar kundantaganden om att arbeta i DevOps-modellen är meddelandet tydligt: ​​inom IT är vi flexibla, vi skapar inte konstgjorda hinder eller driftsregler. Det finns inga saker och saker som “måste vänta då vi är upptagna med något annat.” DevOps tar bort spärrar, säkerställer smidig drift och snabb respons. Det ökar transparensen – klienten vet vad teamen för närvarande arbetar med. Fördelarna med DevOps-implementering är ett omfattande ämne och jag kommer att återkomma till frågan i följande artiklar.

 

DevOps i praktiken steg för steg

Vad betyder DevOps i praktiken? Hur fungerar DevOps-teamen på Craftware? Jag kommer att diskutera de viktiga tekniska aspekterna av att arbeta enligt detta synsätt.

  • Versionskontroll

Teoretiskt sett är det här något som är ganska uppenbart i projekt, men inte så uppenbart i förhållande till Salesforce. På Craftware håller vi oss till principen: om det inte finns något arkiv finns det ingen kontroll. Dessutom finns det inget DevOps utan en lagringsplats för koden. Att arbeta med en lagringsplats är grunden för detta tillvägagångssätt.

Ett viktigt inslag i versionskontroll är regeln om åtminstone en acceptans. Vad betyder det? När det finns mer än bara en utvecklare i ett projekt rekommenderar vi ömsesidig verifiering av ändringar i koden innan den lagras i förvaret. Ju mer omfattande acceptanssystemet är, desto bättre.

Vi rekommenderar också att du tar med ytterligare ett steg för godkännande: att starta enhetstester innan koden placeras i lagring, åtminstone i integrationsmiljön och de efterföljande.

  • GIT Flow

Det är vår rekommenderade metod för att arbeta med datalagringen, vilket speglar vad koden måste gå igenom innan den hamnar i produktionssystemet. Diagrammet nedan förklarar det. Mastergrenen representerar produktionssystemet, Develop-grenen – koden för en ny release. Som du kan se, efter efterföljande ändringar på utvecklingsnivån, går koden inte direkt till produktion utan måste gå igenom Release-nivån först.

GIT-Flow

Bild – GIT Flow

  • Sandbox-hierarki och kontinuerlig integration

Det är inget annat än sekvensen av kodtestning i linje med kontinuerliga integrationsstandarder. Sandbox i Salesforces värld avser testmiljön. Det är värt att nämna att det är mycket enklare att skapa dessa miljöer i Salesforce än i andra program. En kopia av produktionsmiljön kan klickas ut på några minuter. Vårt föreslagna testschema för mer komplicerade Salesforce-instanser som presenteras i figuren nedan.

Sandbox-hierarchy

Bild för Sandbox-hierarkin

Det är uppenbart att när det gäller flera parallella projekt har var och en sin egen testmiljö. Den som heter Integration är den första där vi kan upptäcka fel, exakt negativ inverkan av ett misstag i ett av projekten på resten av dem.

Integrationsmiljön är en fungerande miljö; det rekommenderas inte för officiella tester eftersom det kan bli många förändringar i projekt, under en och samma dag. En version släpps till nästa steg i testningen först efter en stabilisering i denna arbetsmiljö. Ofta är verksamheten också inbjuden att testa det senare steget.

Jag uppmärksammar Hotfix-miljön. Vad är dess roll? Förberedelserna för en ny release kan ta månader. Det finns ingen garanti för att det inte kommer att finnas några produktionsfel under denna tid. Tack vare Hotfix-miljön kan funktionsstörningar repareras effektivt och säkert utan att vänta på en ny funktion. Den innehåller produktionskoden (men inga versioner), så att du kan testa den satta versionen utan risk.

Vi betonar innebörden av kontinuerlig integration i varje teststeg. Anledningen är att ju mer komplicerat projekt är, desto mer framträdande roll spelar CI-processen (Continuous Integration). Vi pratar om många kodövergångar mellan olika miljöer med många förändringar i var och en av dem, eftersom det kan vara många av dem under en dag. I en sådan situation är processautomatisering en viktig förenkling.

  • Release management goals – en medveten strategi för lanseringar

I DevOps-metoden är det en avgörande aspekt. En ny release i ett IT-projekt är inte något som händer varje dag, och det här är något du behöver komma ihåg. Oavsett om det händer om tre veckor eller tre månader – att vänta på det ska inte stoppa förbättringar i själva produktionsmiljön. Jag fortsätter att berätta detta (och förmodligen inte för sista gången), men det är DevOps natur: utveckling och stöd utesluter inte varandra; de kan vara – och borde – utföras samtidigt.

Naturligtvis måste du vara säker på att allt som kom i lanseringen testades tillräckligt och fungerar bra. Korrekt konfiguration av den kontinuerliga integrationsprocessen eliminerar de flesta problem relaterade till den. Och det problem som utvecklare ofta kämpar med är att det finns en gammal kod i den produktionsmiljön.

En sådan sunt förnuftstänkande påverkar teamets arbete – det gör det möjligt att hantera tillgångar mer effektivt. Att förbereda nya funktioner är dock inte lika tidskrävande; en viss lansering kräver mer arbete och en annan mindre. Så det är möjligt att planera arbetet i god tid i samband med semestrar eller helgdagar.

Automatiserade tester kan tyckas vara dyra och olönsamma. Och i själva verket finns det inga betydande fördelar med att genomföra dem. Men ju mer komplicerat systemet är, desto mer användbara är sådana tester.

I systemet finns det till exempel redan några grundläggande sökvägar som följs av en användare. Att skriva ett automatiskt test kommer troligen att ta mycket tid, och om systemet inte utvecklas kanske den tid som spenderas på testförberedelserna inte returneras.

Men om nya funktioner regelbundet läggs till i systemet, betalar den tid som investeras i att skriva dessa tester många gånger. Betydelsen av automatiserade tester är synligt särskilt i samband med regressionstest. Vi antar ofta att om vi bara ändrar ett visst fragment av koden, kommer det inte att påverka fel i andra delar av programvaran. Men praxis bevisar att vi inte kan förutsäga det.

Tack vare lanseringen av automatiska tester kan vi verifiera att ett bredare utbud av kodbesparande manuella testare fungerar. Och det har en inverkan på att minska tiden till marknaden (time to market).

 

Sammanfattning

Implementering av DevOps i Salesforce-projekt behöver inte vara komplicerat. Ibland är det svåraste att börja, men det kräver en attitydförändring för att genomföra ett projekt. Våra kunder som följer våra rekommendationer övertygar sig allt oftare om att detta tillvägagångssätt är effektivt, även bland de största företagen.

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.