VÅRA ARBETSFLÖDEN GENOM TIDERNA

by Olof Johansson - 24/08/2016 - 13:38

När jag började på Odd Hill var vi fyra personer, mig inkluderat. Och med tanke på att vår kära VD inte bidrog med kod (men säkerligen med mycket annat bra) så var vi bara tre personer som var involverade i våra arbetsflöden från start. När vi nu består av 25 personer så skvallrar det om en process som ständigt har varit i behov av förändring för att anpassa oss till våra högt ställda krav.

Häng med på resan för att få en inblick i vår vardag, och kanske lära dig ett och annat ifall du inte känner dig helt tillfreds med arbetsflödet på din arbetsplats.

DE DÅLIGA METODERNA

Gemensam kodbas på lokal server

Den första tiden på Odd Hill körde vi helt utan versionshantering. Vi hade en server lokalt på kontoret som vi alla anslöt till likt en nätverksdisk, och på denna disk fanns webbplatserna som vi arbetade med. Dessa filer jobbade vi med rakt upp och ner utan konstigheter. Om några av någon anledning jobbade i samma fil så skrevs den andres ändringar över, så det var helt enkelt något vi inte kunde göra. När det var dags för lansering av våra förändringar så fanns det bara en möjlighet: Manuell uppladdning via FTP.

Detta är självklart ett helt värdelöst arbetssätt, även för den ensamme utvecklaren.

Gemensamt GIT-repo på lokal server 

Första steget mot att bli en lite mer vuxen arbetsplats började med införandet av versionshistorik genom Git. Vi var alla extremt gröna inom detta, så till en början såg vi inte nyttan med att använda en tjänst som GitHub för att hantera våra repon, utan vi implementerade helt enkelt Git på vår befintliga server.

Förändringarna jämfört med tidigare tillvägagångssätt var små eftersom vi fortfarande kunde skriva över varandras ändringar. Men vi fick i alla fall en historik över våra ändringar, vilket gjorde det lättare att identifiera vilka filer som skulle laddas upp när ändringar skulle lanseras, och vi fick möjlighet att backa tillbaka ifall det uppstod oväntade fel.

Gemensamt GIT-repo i dropbox 

Vi upplevde att den största nackdelen med att ha ett gemensamt repo på vår lokala server var att vi inte kunde arbeta på projekt från andra ställen än just kontoret. Vi hade precis börjat använda Dropbox till våra övriga dokument med gott resultat, så vi beslöt oss för att flytta våra webbplatser inklusive repon till Dropbox.

Gör. Inte. Detta. Dropbox må vara en fantastisk tjänst när det kommer till hantering av ”vanliga” filer, men man ska aldrig någonsin lägga ett repo här. Konflikterna uppstod till höger och vänster, inte bara bland webbplatsens filer utan även hos repot, vilket gjorde att situationen blev ohållbar.

DE BRA METODERNA 

Distribuerat repo 

Vi insåg ganska snabbt att det enda vettiga sättet att arbeta med versionshantering var genom att skaffa en tjänst för att hantera våra repon. Jag hade tidigare erfarenhet av Unfuddle, men var inte övertygad om dess förträfflighet. Efter lite grävande stötte vi på Beanstalk, som förutom att hantera repon faktiskt kunde utföra deployment av kod automatiskt.

Några enklare tester visade på hur enkelt Beanstalk var att använda sig av, och äntligen blev vi av med våra manuella uppladdningar via FTP! Detta är faktiskt en lösning vi använder oss av än idag, så man kan med all säkerhet påstå att vi hittade rätt.

Jag kommer inte gå in på detaljer för hur vi arbetar här, men jag har tidigare gått djupt in på ämnet i en serie blogginlägg. Vill du läsa mer om det så kan du göra det på www.oddhill.se/blogg/our-git-workflow-introduction.

Nästa steg 
Trots att Beanstalk med sina deployments via FTP har fungerat utmärkt för oss i många år, så finns det nackdelar som gör att vi har börjat titta på nästa steg. Vi har bland annat behov av att kunna köra automatiserade tester när vi utvecklar nya funktioner, och vi har ett behov av tätare integration mellan kod och ärendehanteringssystem. Dessutom är deployments via FTP alldeles för långsamt, vilken kan orsaka onödig nedtid vid stora förändringar.

Så, vilket system kan leverera detta? Det svåra här är att välja rätt bland den uppsjö av lösningar som finns, då det finns enklare open source-verktyg, men också färdigpaketerade lösningar med bra support. Ett av de mest använda är Bamboo som är en produkt av Atlassian, vilka vi redan använder för vår ärendehantering och dokumentation.

De initiala testerna av Bamboo lovar minst sagt gott. Integrationen mellan de andra systemen fungerar utmärkt vilket löser vårt krav på en tätare integration, hela vägen från dokumentation till kod. Deployments går bra mycket snabbare, och det är enkelt att utöka med vilka automatiska tester som nu finns utvecklade för projektet i fråga. Nackdelen jämfört med vår nuvarande lösning i Beanstalk är främst att det är en högre tröskel för att sätta upp ett helt flöde, då alla projekt är unika. Detta är inget konstigt med tanke på att flexibiliteten är enorm, men eftersom vi idag består av en hel uppsjö kompetenta utvecklare så är det inga problem.

Vad vi även märkte vid de första testerna av Bamboo var att vårt nuvarande arbetsflöde i Git behövde få sig en översyn. Vi hade kunnat använda precis samma flöde som vi gör idag, men för att öka flexibiliteten och stödja flera olika projekttyper så kändes det bäst att titta efter alternativ. Eftersom vi idag använder ett arbetsflöde baserat på feature-branches och branches för varje miljö, så har kunskapen inom Git blivit hög hos samtliga på företaget. Därför behöver vi inte vara rädda för att göra justeringar som gör att vi får ut mer av Bamboo än vad vi hade fått med vårt nuvarande flöde. En stark kandidat till detta är ett flöde som kallas Gitflow. Detta inlägg kommer inte gå in på detaljer kring Gitflow, men vill du läsa mer om det så rekommenderar jag Atlassians genomgång.

Nästa steg är att testa Bamboo och Gitflow i ett skarpt projekt så att vi får en chans att utvärdera det på allvar. Skulle det visa sig vara det rätta så väntar en övergång till detta för samtliga av våra projekt. Tidsplanen är satt till ”under året” så att vi får bra med tid till att utvärdera alla valmöjligheter innan vi implementerar nästa lösning. Valet av Beanstalk visade på vilken effekt ett bra val kan göra och hur många år detta kan hjälpa oss i vardagen, så det är viktigt att säkerställa nästa steg innan man tar det.

TIPS FRÅN COACHEN 
- Det första du bör göra om du inte redan gör det, är att lära dig Git och använda det i alla dina projekt. Oavsett om du är ensam utvecklare eller arbetar på ett större företag, så är detta någonting som säkerställer att din kod går att arbeta med under lång tid. Har du ingen versionshistorik så blir det omöjligt att se varför en viss ändring har gjorts, och det blir onödigt svårt för framtida utvecklare att kopplas in på ditt projekt. Dessutom är Git grunden i en mängd tjänster, till exempel om man vill ha automatiska deployments eller om man vill att någon annan utvecklare ska granska sin kod.
- Implementera inte ett krångligare flöde än vad du har behov för. Det kanske räcker alldeles utmärkt att enbart arbeta på en master-branch. Utöka först när behoven dyker upp...
- ... och när de gör det, så finns det en hel uppsjö artiklar om ämnet. Det är bara att googla sig fram för att hitta en best-practice som passar för just dig. Du är långt ifrån ensam om att arbeta i Git, och det finns många hjul att välja mellan beroende på dina behov. Best-practises har blivit best-practises av en anledning, det finns ingen mening med att uppfinna ett nytt arbetsflöde. Dessutom blir det lättare för andra att hjälpa dig om du kan peka på en viss metod som du använder dig av.

Har du frågor eller vill prata vidare om arbetsflöden går det utmärkt att kontakta mig på olof.johansson@oddhill.se eller @colofjohansson på Twitter.

written by

Odd Hill