Hur kan team samarbeta utan pull requests?

Continuous Integration och Code Review har ett starkt samband med framgång. Många använder Pull Requests för code review, men för samlokaliserade team kan det vara ett hinder för CI. Finns det ett bättre sätt?

Det finns tre utvecklare i det (fiktiva) teamet: Annika, Boris och Carol. Annika är nyanställd och kommer direkt från universitetet, Boris är teamledare och Carol har varit med längst. Var och en arbetar med en egen uppgift. När de kom till kontoret i dag synkroniserade de sitt arbete med den gemensamma master-branchen, och nu börjar det närma sig förmiddagsfika. Alla har gjort ändringar i koden som de vill dela med resten av teamet.

Annika arbetar på en lokal branch som heter ”red”. Hon kontrollerar att den är uppdaterad med master och pushar den till en remote branch med namnet ”ready/red”. Boris och Carol gör på liknande sätt. De arbetar på brancherna blue respektive orange och pushar sina ändringar till ready/blue och ready/orange.

Build Server är konfigurerad för att upptäcka nya brancher på Version Control Server som följer en namngivningskonvention. Alla brancher som börjar med ”ready/” schemaläggs för integration, och endast ett av dessa integrationsbyggen körs åt gången. Build Server delegerar byggen till en eller flera agenter, och eftersom agenten för ready-jobbet är ledig tar den direkt hand om ändringen i ”ready/red” och lämnar byggena för de andra två ready-brancherna i kön.

Build-jobbet har flera steg. Först mergar agenten ready-branchen med en lokal kopia av master-branchen. Annikas ändringar mergas med en enkel fast-forward. Agenten genomför ett fullständigt bygge, statisk analys, kontroll av kodstil och enhetstester. Allt går bra, så agenten pushar resultatet av mergen till Version Control Server och publicerar ett meddelande på teamets meddelandetavla.

Det börjar på liknande sätt för Boris ready/blue-branch. Build-agenten hämtar en kopia av master från git-servern och mergar in ready-branchen. Det här är inte en fast-forward-merge, eftersom det finns en ny commit i master med ändringarna för ”red”, men det fungerar ändå. Så länge agenten kan genomföra mergen utan att hitta några konflikter kan bygget fortsätta.

Agenten går sedan vidare till nästa steg i bygget. Tyvärr hade Boris inte märkt att en av hans ändringar orsakade ett testfel. Teamet har tidigare kommit överens om att koden i master alltid ska klara testerna, så Boris ändringar bör därför inte delas. Build-agenten skickar ett meddelande till Boris om de misslyckade testerna, kasserar sin mergade branch och går vidare. Carols ready/orange-branch står näst på tur. Build-agenten börjar om med en ny kopia av den senaste master från git-servern. Carols ändringar mergas också utan problem, och den här gången klarar både bygget och testerna. Build-agenten pushar merge-commiten till servern och meddelar teamet.

Boris och Carol tar en kopp kaffe medan de väntar på att build-servern ska integrera deras ändringar. Annika pratar med Product Owner om den nya funktionen ”cyan”, som hon planerar att arbeta med härnäst. När de kommer tillbaka till sina skrivbord ser de meddelandena från build-servern.

Annika är glad över att se att hennes ändringar har integrerats utan problem. Hon hämtar den senaste master från den remote git-servern. Hon har nu slutfört arbetet med uppgiften ”red”, och hennes ändringar ska genomgå en code review. Hon markerar uppgiften ”red” som klar i ärendehanteringssystemet och lägger till en punkt på agendan för teamets nästa schemalagda code review-möte, som äger rum senare samma vecka. Annika väljer en ny uppgift att arbeta med och checkar ut en lokal branch från master som heter ”cyan”. Boris ser meddelandet om de misslyckade testerna och inser direkt vad han hade missat. Han är lite generad över sitt misstag, men glad över att hans teamkollegor inte påverkas. De kanske inte ens märker vad som har hänt. Boris passar på att mergera de senaste ändringarna från master till sin ”blue”-branch. Han kan snabbt lösa problemet med testerna och pushar en uppdatering till ready/blue. Build-agenten sätter genast igång.

Carol är inte klar med uppgiften ”orange”, men är glad över att se att hennes första ändringar har integrerats utan problem. Hon hämtar master och mergar den med ”orange” innan hon fortsätter arbeta där. Hon har lagt märke till en designändring som skulle göra hennes uppgift enklare. Hon planerar refaktoreringen i steg så att hon kan pusha små ändringar ofta medan hon slutför den nya designen. Genom att ofta dela sina ändringar med teamet blir det enklare för alla att undvika kostsamma merger. Senare samma vecka, på code review-mötet, tittar teamet på Annikas ändringar för uppgiften ”red”. De omfattar ett par dagars arbete. Code review-verktyget visar en sammanfattning av alla berörda commits, och teamet diskuterar alla ändringar som gjorts under utvecklingen av funktionen ”red”.

Tyvärr är Boris och Carol inte nöjda med en del av designen som Annika har gjort, och kodformateringen behöver förbättras på vissa ställen. Mötet resulterar i att de kommer överens om att parprogrammera med Annika för att refaktorera designen, och uppmuntrar henne att oftare initiera informella designdiskussioner under utvecklingen. Tanken är att de mer erfarna utvecklarna, Boris och Carol, ska hjälpa Annika att lära sig bättre designprinciper. Teamet tycker att problemen med kodformateringen är lite irriterande eftersom den här typen av detaljer inte bör stå i fokus under ett code review-möte. De skapar en uppgift för att förbättra kodstilskontrollen i bygget för pre-tested integration, så att liknande problem med kodformatering kan fångas upp i framtiden.

Kommentar

Den här utvecklingsprocessen fungerar väldigt bra för Annika, Boris och Carol, och förtestad integration är en liten men viktig del. De använder inte pull requests, men de har kontroller för vilken kod som får komma in i master-branchen och en god kultur för code review. Integrering till master sker oftare än arbetsobjekten flödar genom processen. Det är viktigt. Ju oftare du integrerar, desto mindre smärtsam blir integreringen, och du kanske inte vill dela upp dina arbetsobjekt i samma små detaljeringsgrad som är bäst för kodändringar. Du vill inte heller nödvändigtvis fördröja integreringen genom att vänta på att en teammedlem ska granska din pull request.

Strikt sett är den här processen inte Trunk-Based development, eftersom fler grenar än bara trunk används. Men så länge integreringen sker ofta i praktiken går den inte att skilja från Trunk-Based development. Fördelen jämfört med Trunk-Based development är förstås att Boris eller någon annan utvecklare inte oavsiktligt kan förstöra master för resten av teamet.

Om du använder Jenkins kan du enkelt automatisera integreringsprocessen med vår Pretested Integration plugin. Det är inte svårt att implementera den här funktionen själv för andra build-servrar. Oavsett vilket tillvägagångssätt ditt team väljer rekommenderar jag att ni enas om en process som leder till frekvent integrering tillsammans med gemensamma och konstruktiva code reviews.