Miten tiimit voivat tehdä yhteistyötä ilman Pull Requesteja?

Continuous Integration ja code review korreloivat vahvasti onnistumisen kanssa. Monet käyttävät Pull Requesteja code review -tarkastuksiin, mutta samassa toimipisteessä työskenteleville tiimeille ne voivat olla este CI:lle. Onko parempaa tapaa?

(Kuvitteellisessa) tiimissä on kolme kehittäjää: Annika, Boris ja Carol. Annika on vastikään yliopistosta valmistunut uusi työntekijä, Boris on tiimin vetäjä ja Carol on ollut mukana pisimpään. Jokainen heistä työskentelee eri tehtävän parissa. He kaikki synkronoivat työnsä yhteiseen master-haaraan saapuessaan tänään toimistolle, ja nyt aamukahviaika lähestyy. He ovat kaikki tehneet koodiin muutoksia, jotka he haluaisivat jakaa muun tiimin kanssa.

Annika työskentelee paikallisessa haarassa nimeltä ”red”. Hän varmistaa, että se on ajan tasalla masterin kanssa, ja pushaa sen etähaaraan nimeltä ”ready/red”. Borisilla ja Carolilla tilanne on samanlainen. He työskentelevät vastaavasti blue- ja orange-haaroissa ja pushaavat muutoksensa haaroihin ready/blue ja ready/orange.

Build Server on määritetty tunnistamaan Version Control Serverissä uudet haarat, jotka noudattavat nimeämiskäytäntöä. Jokainen ready/-alkuinen haara ajoitetaan integroitavaksi, ja näistä integraatiobuildeista suoritetaan vain yksi kerrallaan. Build Server delegoi buildit yhdelle tai useammalle agentille, ja koska ready-job-agentti on vapaana, se ottaa ”ready/red”-muutoksen käsittelyyn heti ja jättää kaksi muuta ready-haaran buildia jonoon.

Build-työhön kuuluu useita vaiheita. Ensin agentti yhdistää ready-haaran master-haaran paikalliseen kopioon. Annikan muutokset yhdistyvät yksinkertaisella fast-forwardilla. Agentti suorittaa täydellisen buildin, staattisen analyysin, koodityylitarkistuksen ja yksikkötestit. Kaikki sujuu hyvin, joten agentti pushaa yhdistämisen tuloksen Version Control Serveriin ja julkaisee viestin tiimin viestitaululla.

Borisin ready/blue-haaran kohdalla alku sujuu samalla tavalla. Build-agentti ottaa git-palvelimelta masterin kopion ja yhdistää siihen ready-haaran. Kyseessä ei ole fast-forward-yhdistäminen, koska masterissa on uusi commit red-muutoksille, mutta se ei haittaa. Build voi jatkua, kunhan agentti voi tehdä yhdistämisen ilman konflikteja.

Agentti siirtyy sitten seuraaviin build-vaiheisiin. Valitettavasti Boris ei ollut huomannut, että yksi hänen muutoksistaan aiheutti testivirheen. Tiimi on aiemmin sopinut, että masterin koodin tulee aina läpäistä testit, joten Borisin muutoksia ei pidä jakaa. Build-agentti lähettää Borisille viestin epäonnistuneista testeistä, hylkää yhdistetyn haaransa ja jatkaa seuraavaan. Seuraavana vuorossa on Carolin ready/orange-haara. Build-agentti aloittaa jälleen git-palvelimelta otetulla tuoreella kopioilla uusimmasta masterista. Carolin muutoksetkin yhdistyvät ongelmitta, ja tällä kertaa sekä build että testit onnistuvat. Build-agentti pushaa merge commitin palvelimelle ja ilmoittaa siitä tiimille.

Boris ja Carol juovat kahvia odottaessaan, että build server integroi heidän muutoksensa. Annika keskustelee Product Ownerin kanssa seuraavasta ominaisuudesta, cyanista, jonka parissa hän aikoo työskennellä. Palattuaan työpöytiensä ääreen he näkevät build serverin viestit.

Annika ilahtuu nähdessään, että hänen muutoksensa on integroitu onnistuneesti. Hän hakee uusimman masterin etägit-palvelimelta. Hän on saanut red-tehtävän työn valmiiksi, ja hänen muutoksensa pitäisi käydä läpi code review. Hän merkitsee red-tehtävän valmiiksi issue trackerissa ja lisää sen tiimin seuraavan, myöhemmin samalla viikolla pidettävän code review -tapaamisen asialistalle. Annika valitsee uuden tehtävän ja checkouttaa masterista paikallisen haaran nimeltä cyan. Boris näkee viestin epäonnistuneista testeistään ja ymmärtää heti, mitä häneltä jäi huomaamatta. Hän on hieman nolostunut virheestään, mutta iloinen siitä, etteivät hänen tiimikaverinsa kärsi siitä. He eivät välttämättä edes huomaa, mitä tapahtui. Boris käyttää tilaisuuden hyväkseen ja yhdistää uusimmat masterin muutokset blue-haaraansa. Hän korjaa testiongelman nopeasti ja pushaa päivityksen ready/blue-haaraan. Build-agentti ryhtyy töihin heti.

Carol ei ole vielä saanut orange-tehtävää valmiiksi, mutta on tyytyväinen nähdessään, että hänen ensimmäiset muutoksensa on integroitu onnistuneesti. Hän hakee masterin ja yhdistää sen orange-haaraan ennen kuin jatkaa työskentelyä siinä. Hän on huomannut suunnittelumuutoksen, joka helpottaisi hänen tehtäväänsä. Hän suunnittelee refaktoroinnin vaiheittain, jotta voi pushata pieniä muutoksia usein tehdessään uudelleensuunnittelua valmiiksi. Muutosten jakaminen tiimin kanssa usein helpottaa kaikkia välttämään kalliita yhdistämisiä. Myöhemmin samalla viikolla tiimi käy code review -tapaamisessa läpi Annikan red-tehtävän muutokset. Ne edustavat parin päivän työtä. Code review -työkalu esittää yhteenvedon kaikista mukana olevista commiteista, ja tiimi keskustelee kaikista red-ominaisuuden kehityksen aikana tehdyistä muutoksista.

Valitettavasti Boris ja Carol eivät ole tyytyväisiä osaan Annikan tekemästä suunnittelusta, ja koodin muotoilua pitää paikoin parantaa. Tapaamisen lopputuloksena he sopivat pariohjelmoivansa Annikan kanssa suunnittelun refaktoroinnin parissa ja kannustavat häntä aloittamaan epävirallisia suunnittelukeskusteluja useammin kehitystyön aikana. Tarkoitus on, että kokeneemmat kehittäjät Boris ja Carol auttavat Annikkaa oppimaan parempia suunnittelutaitoja. Tiimi pitää koodin muotoiluongelmia hieman ärsyttävinä, koska tällaisten yksityiskohtien ei pitäisi olla code review -tapaamisen keskiössä. He luovat tehtävän parantaa pre-tested integration buildin code-style checkeriä, jotta se tunnistaa vastaavat koodin muotoiluongelmat jatkossa.

Kommentti

Tämä kehitysprosessi toimii erittäin hyvin Annikalle, Borisille ja Carolille, ja esitestattu integraatio on pieni mutta tärkeä osa sitä. He eivät käytä pull requesteja, mutta heillä on käytössään tarkistuksia sille, mitä koodia master-haaraan hyväksytään, sekä hyvä koodikatselmointikulttuuri. Integrointi master-haaraan tapahtuu tiheämmässä tahdissa kuin työtehtävien virta. Se on tärkeää. Mitä useammin integroit, sitä vähemmän kivuliasta se on. Työtehtäviä ei myöskään välttämättä kannata pilkkoa yhtä pieniin osiin kuin koodimuutosten kannalta olisi parasta. Et myöskään välttämättä halua viivästyttää integraatiota odottamalla, että tiimikaveri katselmoi pull requestisi.

Tarkasti ottaen tämä prosessi ei ole Trunk-Based developmentia, koska mukana on trunkin lisäksi muitakin haaroja. Käytännössä se on kuitenkin erottamaton siitä, kunhan integraatio tapahtuu usein. Etuna Trunk-Based developmentiin verrattuna on tietysti se, ettei Boris tai kukaan muukaan kehittäjä voi vahingossa rikkoa master-haaraa muulta tiimiltä.

Jos käytät Jenkinsiä, voit automatisoida integraatioprosessin helposti Pretested Integration -pluginillamme. Saman toiminnallisuuden toteuttaminen itse muille build-palvelimille ei ole vaikeaa. Valitsipa tiimisi minkä lähestymistavan tahansa, suosittelen sopimaan prosessista, joka johtaa tiheään integraatioon sekä yhteistyöhön perustuvaan ja rakentavaan koodikatselmointiin.