Git är i de flesta fall känt som ett versionshanteringssystem men väldigt få använder Git till dess fulla potential.

I denna korta guide så går vi genom hur du som CTO eller Team Lead kan få ökad produktivitet och arbetsglädje samtidigt som ni snabbare kan leverera ny funktionalitet till era kunder / slutanvändare.

Dessa metoder kan tillämpas oavsett vilken remote tjänst (Github, Gitlab, Bitbucket) man använder.

Flöde 1 - One Way Road

Ett flöde som används i vissa av våra projekt är att man deployar mindre fixar i klumpar stegvist men för varje steg så testas hela klumpen av olika stakeholders.

1. development - Testas av utvecklare

2. test - Testas av QA / Projektledare / Produktionsledare

3. staging - Testas av Produktägare hos kund

4. master - Testas av slutkund / slutanvändare

5. stable - Lagrar en "Point in time" version av koden, den senaste versionen som ligger i master och har godkänts

All kod går enbart åt ett håll i flödet. Alla så kallade "Pull Requests" går från Development till Stable. Detta medför att man i varje steg har vissa personer som tar ansvar för att koden granskas, godkänns och går vidare till nästa steg.

I detta fall så skulle man kunna säga att en bugg kan göra att hela releasen stannar upp och behöver gå tillbaka till development branchen.

Denna flöde påminner om när man bygger bilar. Man kan inte leverera bilen innan alla delar i bilen har testats och godkänts i varje del av bygget. Man kan t ex inte leverera bilen även om högtalaren och hjulen funkar prima.

Fördelar

• Funkar bra när man ska deploya saker som har beroenden

• All kod godkänns av stakeholders och kan aldrig gå ut i produktion utan att alla i kedjan har godkänt kodbasen som ska ut. Vissa godkänner koden ur ett kodperspektiv och andra godkänner leveransen utifrån funktionalitet och utseende.

• Man kan ha väldigt enkla miljöer som inte behöver kunna deploya kod automatiskt och köra migreringar och andra build-skript

Nackdelar

• Viss kod som funkar kanske inte kan deployas då det sitter ihop med annan kod som skall debuggas, fixas och testas innan det kan gå ut

• Deployments sker inte så ofta

GIT SHIT DONE

Flöde 2 - Micro Deploy

Ett annat flöde som vi testat i omgångar är att enskilda ändringar flödar från development till stable, vilket innebär att man kan följa en viss specifik ändring ut till produktions-miljön oberoende av den kod som finns i de olika branches. I Flöde 1 är man väldigt strikt med att kod alltid flödar åt ett håll (från development till master) medan i detta flöde så kan kod flöda in i olika branches beroende på vem som behöver kunna verifiera och testa koden.

Vissa ändringar kanske enbart kan godkännas av en Team Lead eller Produktägare och andra delar av koden kan inte en Produktägare se skillnad på eftersom den ändringen ligger långt inne i någon del av backend.

Låt oss anta att vi har en ny feature som vår utvecklare Baddar knåpar ihop som går ut på att vi vill ha en Like-knapp på blogginlägg. Baddar döper sin branch till add-like-button och den branchen vill vi t ex låta vår utvecklarkollega Samuel testa i development då han behöver kunna merga sin kod efter att Baddars kod har testats och godkänts.

Samtidigt så fixar Andreas HTTPS för siten och denna har hög prio och får ligga i branchen hotfix-https-on-nginx. Andreas ändring godkänns av de stakeholders som finns och kan gå ut ända till master men samtidigt så hittar Samuel en bugg som gör att Baddars ändring i add-like-button kan hindra databasen från att serva anrop tillräckligt snabbt då Baddar glömt att paginera listan som visar vilka användare som Like:at ett visst inlägg. Detta medför att Baddars kod stannar i development branchen till att han har fixat paginering på listvyn.

Fördelar

• Man kan sjösätta små ändringar åt gången och göra snabba tweaks

• Detta lämpar sig väl i större team där man har många utvecklare och rörliga delar som behöver gå deployas oberoende

• Man behöver inte testa samma features flera gånger utan testar en feature åt gången

• Man påverkar inte någon annans förmåga att kunna deploya sin kod

• Det finns en tydlig "ägare" av buggen / buggarna

Nackdelar

• Man behöver investera tid och resurser på att hantera en eller flera miljöer som kan hantera små deploys, där man t ex

  1. Tar en snapshot av produktionsdatabasen samt cache lagret och spinner upp en ny miljö med en snapshot av koden

  2. Alla tester som finns i projektet körs

  3. Ifall testerna går igenom så hostas koden på en unik domän som t ex en Produktägare kan testa

  4. När kodbasen godkänts så mergas den in i master och då utförs migreringarna på databasen i produktion

• Man behöver investera tid i att skriva och underhålla tester

• Varje utvecklare behöver ha koll på att de har ändringarna från master mergade med sin nuvarande branch som man jobbar på "just nu"

• Sannolikheten i att det uppstår konflikter i kod eller migreringar ökar

Hur gör man rollbacks på ett bra sätt?

När man gjort en framgångsrik deploy av koden i produktionsmiljön kan man skapa en ny branch som t ex heter stable-release-20191128-1337, vilket innebär att man alltid kan rulla tillbaka till denna branch ifall en produktionssättning går snett i framtiden.

Kom ihåg att migreringar också behöver rullas tillbaka ifall du har ändringar i din databas. Det innebär att du behöver först gå tillbaka i din migreringshistorik som är i synk med den koden som ligger i stable-release-20191128-1337