GitHub Flow

Issues with git-flow

Kiertelen ympäriinsä opettamassa ihmisille Gitiä, ja lähes jokaisella viime aikoina pitämälläni kurssilla ja työpajassa on kysytty, mitä mieltä olen git-flowsta. Vastaan aina, että mielestäni se on hieno – siinä on otettu järjestelmä (Git), jossa on miljoona mahdollista työnkulkua, ja dokumentoitu hyvin testattu, joustava työnkulku, joka toimii monille kehittäjille melko suoraviivaisesti. Siitä on tullut jonkinlainen standardi, joten kehittäjät voivat siirtyä projekteista tai yrityksistä toiseen ja tuntea tämän standardoidun työnkulun.

Tässä on kuitenkin omat ongelmansa. Olen kuullut useita mielipiteitä ihmisiltä, jotka eivät pidä siitä, että uudet ominaisuushaarat aloitetaan develop:stä eikä master:sta, tai tavasta, jolla se käsittelee hotfixejä, mutta nämä ovat melko vähäisiä.

Yksi suuremmista ongelmista minulle on se, että se on monimutkaisempi kuin uskon, että useimmat kehittäjät ja kehitystiimit todellisuudessa tarvitsevat. Se on sen verran monimutkainen, että kehitettiin iso apuskripti auttamaan virtauksen valvomisessa. Vaikka tämä on siistiä, ongelmana on se, että sitä ei voi pakottaa Gitin graafisessa käyttöliittymässä, vain komentorivillä, joten ainoat ihmiset, jotka joutuvat oppimaan monimutkaisen työnkulun todella hyvin, koska heidän täytyy tehdä kaikki vaiheet manuaalisesti, ovat samoja ihmisiä, jotka eivät tunne järjestelmää tarpeeksi hyvin käyttääkseen sitä komentoriviltä. Tämä voi olla valtava ongelma.

Kumpikin näistä ongelmista voidaan ratkaista helposti vain paljon yksinkertaisemmalla prosessilla. GitHubissa emme käytä git-flowta. Käytämme ja olemme aina käyttäneet paljon yksinkertaisempaa Git-työnkulkua.

Sen yksinkertaisuus antaa sille useita etuja. Yksi on se, että ihmisten on helppo ymmärtää sitä, mikä tarkoittaa, että he oppivat sen nopeasti ja he harvoin, jos koskaan, sotkevat sen tai joutuvat perumaan väärin tekemänsä vaiheet. Toinen on se, että emme tarvitse wrapper-skriptiä auttamaan sen toteuttamisessa tai seuraamisessa, joten graafisten käyttöliittymien ja vastaavien käyttäminen ei ole ongelma.

GitHub Flow

Miksi emme käytä git-flowta GitHubissa? No, suurin ongelma on se, että otamme käyttöön koko ajan. git-flow-prosessi on suunniteltu pitkälti ”julkaisun” ympärille. Meillä ei oikeastaan ole ”julkaisuja”, koska otamme käyttöön tuotantoon joka päivä – usein useita kertoja päivässä. Voimme tehdä sen chat-robottimme kautta, joka on sama paikka, jossa CI-tuloksemme näkyvät. Yritämme tehdä testauksesta ja lähettämisestä mahdollisimman yksinkertaista, jotta jokainen työntekijä viihtyy siinä.

Näin säännöllisellä käyttöönotolla on useita etuja. Jos otat käyttöön muutaman tunnin välein, on lähes mahdotonta ottaa käyttöön suuria määriä isoja virheitä. Pieniä ongelmia voidaan ottaa käyttöön, mutta sitten ne voidaan korjata ja ottaa uudelleen käyttöön hyvin nopeasti. Normaalisti pitäisi tehdä ”hotfix” tai jotain normaalin prosessin ulkopuolista, mutta se on yksinkertaisesti osa normaalia prosessiamme – GitHub-virtauksessa ei ole mitään eroa hotfixin ja hyvin pienen ominaisuuden välillä.

Toinen etu, joka liittyy koko ajan tapahtuvaan käyttöönottoon, on se, että kaikenlaisiin ongelmiin voidaan puuttua nopeasti. Voimme reagoida tietoisuuteemme tulleisiin tietoturvaongelmiin tai toteuttaa pieniä mutta mielenkiintoisia ominaisuuspyyntöjä uskomattoman nopeasti, mutta voimme silti käyttää täsmälleen samaa prosessia näiden muutosten käsittelyyn kuin normaaliin tai jopa suurten ominaisuuksien kehittämiseen. Kyse on samasta prosessista, ja se on hyvin yksinkertainen.

Miten teemme sen

Mitä on siis GitHub Flow?

• Kaikki master-haarassa oleva on käyttöönotettavissa
• Työstääksesi jotain uutta, luo kuvaavasti nimetty haara master:sta (esim: new-oauth2-scopes)
• Kirjoita tuohon haaraan paikallisesti ja työnnä työsi säännöllisesti samannimiseen haaraan palvelimella
• Kun tarvitset palautetta tai apua, tai kun uskot haaran olevan valmis yhdistettäväksi, avaa pull request
• Kun joku muu on tarkistanut ja hyväksynyt ominaisuuden, voit sulauttaa sen masteriin
• Kun se on sulautettu ja työnnetty ’masteriin’, voit ja sinun pitäisi ottaa se käyttöön välittömästi

Tässä on koko virtaus. Se on hyvin yksinkertainen, hyvin tehokas ja toimii melko suurissa tiimeissä – GitHubissa on nyt 35 työntekijää, joista ehkä 15-20 työskentelee saman projektin (github.com) parissa samaan aikaan. Luulen, että useimmat kehitystiimit – ryhmät, jotka työskentelevät samaan aikaan saman loogisen koodin parissa, mikä voi aiheuttaa ristiriitoja – ovat suunnilleen tämän kokoisia tai pienempiä. Etenkin ne, jotka ovat tarpeeksi edistyksellisiä tehdäkseen nopeita ja johdonmukaisia käyttöönottoja.

Katsotaanpa siis kutakin näistä vaiheista vuorollaan.

#1 – kaikki master-haarassa oleva on käyttöönotettavissa

Tämä on periaatteessa järjestelmän ainoa kova sääntö. On vain yksi haara, jolla on jokin erityinen ja johdonmukainen merkitys, ja nimesimme sen master. Meille tämä tarkoittaa, että se on otettu käyttöön tai pahimmillaan otetaan käyttöön tuntien sisällä. On uskomattoman harvinaista, että tämä käännetään takaisin (haara siirretään takaisin vanhempaan komitukseen työn palauttamiseksi) – jos on ongelma, komitukset käännetään takaisin tai otetaan käyttöön uusia komituksia, jotka korjaavat ongelman, mutta haaraa itsessään ei käännetä takaisin melkein koskaan.

Haaraa master pidetään vakaana, ja siitä on aina, aina turvallista ottaa käyttöön tai luoda uusia haaroja siitä. Jos työnnät masteriin jotain, jota ei ole testattu tai joka rikkoo buildin, rikot kehitystiimin yhteiskuntasopimusta ja siitä tulee yleensä aika paha mieli. Jokaiseen haaraan, jonka työnnämme, on ajettu testit ja niistä on raportoitu keskustelupalstalle, joten jos et ole ajanut testejä paikallisesti, voit yksinkertaisesti työntää palvelimella olevaan aihehaaraan (jopa haaraan, jossa on vain yksi sitoutuminen) ja odottaa Jenkinsin kertovan, läpäiseekö se kaiken.

Voisit pitää deployed-haaraa, joka päivitetään vain silloin, kun teet käyttöönoton, mutta emme tee niin. Me yksinkertaisesti paljastamme tällä hetkellä käyttöönotetun SHA:n itse verkkosovelluksen kautta ja curl sen, jos tarvitsemme vertailun tekemistä.

#2 – luo kuvailevia haaroja masterista

Kun haluat aloittaa työskentelyn minkä tahansa asian parissa, luot kuvailevan nimisen haaran stabiilista master haarasta. Joitakin esimerkkejä GitHubin koodipohjassa tällä hetkellä olisivat user-content-cache-key, submodules-init-task tai redis2-transition. Tästä on useita etuja – yksi on, että kun haet, näet aiheet, joiden parissa kaikki muut ovat työskennelleet. Toinen on se, että jos hylkäät haaran joksikin aikaa ja palaat siihen myöhemmin, on melko helppo muistaa, mikä se oli.

Tämä on mukavaa, koska kun menemme GitHubin haaralista-sivulle, näemme helposti, mitä haaroja on viime aikoina työstetty ja kuinka paljon niissä on suunnilleen töitä.

Se on melkein kuin lista tulevista ominaisuuksista, joissa on tämänhetkinen karkea tila. Tämä sivu on mahtava, jos et käytä sitä – se näyttää sinulle vain oksat, joissa on ainutlaatuista työtä suhteessa tällä hetkellä valitsemaasi oksaan, ja se lajittelee ne niin, että viimeksi työstetyt oksat ovat ylimpänä. Jos tulen todella uteliaaksi, voin klikata ’Vertaa’-painiketta nähdäkseni, mikä on todellinen yhtenäinen diff- ja commit-luettelo, joka on ainutlaatuinen kyseiselle haaralle.

Tätä kirjoittaessani tätä kirjoittaessani meillä on arkistossamme 44 haaraa, joissa on merkitsemätöntä työtä, mutta näen myös, että vain noin 9 tai 10 niistä on siirretty viimeisen viikon aikana.

#3 – työnnä nimettyihin haaroihin jatkuvasti

Toinen suuri ero git-flow’hun verrattuna on se, että työnnämme nimettyihin haaroihin palvelimella jatkuvasti. Koska ainoa asia, josta meidän on oikeasti huolehdittava, on master käyttöönoton kannalta, palvelimelle työntäminen ei sotke ketään tai sekoita asioita – kaikki, mikä ei ole master, on yksinkertaisesti jotain, jota työstetään.

Se myös varmistaa, että työmme on aina varmuuskopioitu kannettavan tietokoneen katoamisen tai kiintolevyn vikaantumisen varalta. Vielä tärkeämpää on se, että kaikki ovat jatkuvasti yhteydessä toisiinsa. Yksinkertainen ’git fetch’ antaa periaatteessa TODO-listan siitä, minkä parissa kaikki työskentelevät tällä hetkellä.

$ git fetchremote: Counting objects: 3032, done.remote: Compressing objects: 100% (947/947), done.remote: Total 2672 (delta 1993), reused 2328 (delta 1689)Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.Resolving deltas: 100% (1993/1993), completed with 213 local objects.From github.com:github/github * charlock-linguist -> origin/charlock-linguist * enterprise-non-config -> origin/enterprise-non-config * fi-signup -> origin/fi-signup 2647a42..4d6d2c2 git-http-server -> origin/git-http-server * knyle-style-commits -> origin/knyle-style-commits 157d2b0..d33e00d master -> origin/master * menu-behavior-act-i -> origin/menu-behavior-act-i ea1c5e2..dfd315a no-inline-js-config -> origin/no-inline-js-config * svg-tests -> origin/svg-tests 87bb870..9da23f3 view-modes -> origin/view-modes * wild-renaming -> origin/wild-renaming

Sen avulla kaikki näkevät myös GitHubin Branch List -sivulta, minkä parissa kaikki muut työskentelevät, jotta he voivat tarkastaa ne ja katsoa, haluavatko he auttaa jossakin.

#4 – avaa pull request milloin tahansa

GitHubissa on mahtava koodin tarkistusjärjestelmä nimeltä Pull Requests, jota pelkäänpä, etteivät tarpeeksi monet tunne. Monet ihmiset käyttävät sitä avoimen lähdekoodin työhön – haarukoivat projektin, päivittävät projektia, lähettävät pull requestin ylläpitäjälle. Sitä voidaan kuitenkin helposti käyttää myös sisäisenä koodin tarkistusjärjestelmänä, mitä me teemme.

Tosiasiassa käytämme sitä enemmänkin haarakeskustelunäkymänä kuin pull requestina. GitHubissa voi lähettää pull request -pyyntöjä yhdestä haarasta toiseen yksittäisessä projektissa (julkisessa tai yksityisessä), joten niillä voi sanoa ”Tarvitsen apua tai tarkistusta tähän” sen lisäksi, että voi sanoa ”Ole hyvä ja yhdistä tämä”.

Tässä näet, että Josh cc’ing Brianille tarkistusta varten ja Brian tulee antamaan neuvoja yhdestä koodirivistä. Alempana näemme Joshin kuittaavan Brianin huolenaiheet ja työntävän lisää koodia niiden ratkaisemiseksi.

Loppujen lopuksi näet, että olemme vielä kokeiluvaiheessa – tämä ei ole vielä käyttöönottovalmis haara, vaan käytämme Pull Requests -pyyntöjä koodin tarkistamiseen jo kauan ennen kuin varsinaisesti haluaisimme sulauttaa sen master:een käyttöönottoa varten.

Jos olet jumissa ominaisuuden tai haaran etenemisessä ja tarvitset apua tai neuvoja, tai jos olet kehittäjä ja tarvitset suunnittelijan tarkistamaan työsi (tai päinvastoin), tai jopa jos sinulla on vain vähän tai ei lainkaan koodia, mutta joitakin kuvakaappauksia tai yleisiä ideoita, avaat pull requestin. Voit ccata ihmisiä GitHub-järjestelmässä lisäämällä @-käyttäjätunnuksen, joten jos haluat tiettyjen ihmisten arvostelun tai palautteen, voit yksinkertaisesti ccata heidät PR-viestissä (kuten näit Joshin tekevän edellä).

Tämä on siistiä, koska Pull Request -ominaisuus antaa sinun kommentoida yksittäisiä rivejä yhdistetyssä diffissä, yksittäisiä kommitteja tai itse vetopyyntöä, ja se vetää kaiken linjassa yhteen keskustelunäkymään.Sen avulla voit myös jatkaa työntämistä haaraan, joten jos joku kommentoi, että unohdit tehdä jotain tai koodissa on virhe, voit korjata sen ja työntää haaraan, GitHub näyttää uudet kommitit keskustelunäkymässä ja voit jatkaa iterointia haarassa näin.

Jos haara on ollut auki liian kauan ja sinusta tuntuu, että se on menossa pois synkronoinnista master-haaran kanssa, voit sulauttaa masterin aihehaarasi aihehaaraan ja jatkaa eteenpäin. Näet helposti pull request -keskustelusta tai commit-listasta, milloin haara on viimeksi saatettu ajan tasalle ”masterin” kanssa.

Kun kaikki on todella ja toden teolla tehty haarassa ja se on mielestäsi valmis käyttöönotettavaksi, voit siirtyä seuraavaan vaiheeseen.

#5 – sulauta vasta pull requestin tarkistuksen jälkeen

Me emme yksinkertaisesti tee työtä suoraan master tai työskentele aihehaarassa ja sulauta sitä, kun se on mielestämme valmis – yritämme saada hyväksynnän joltakulta muulta yrityksessä. Tämä on yleensä +1 tai emoji tai ””-kommentti, mutta yritämme saada jonkun muun katsomaan sitä.

Kun saamme sen ja haara läpäisee CI:n, voimme sulauttaa sen masteriin käyttöönottoa varten, mikä sulkee Pull Requestin automaattisesti, kun työnnämme sen.

#6 – deploy heti tarkistuksen jälkeen

Viimein työsi on valmis ja sulautettu master-haaraan. Tämä tarkoittaa, että vaikka et nyt deploytaisikaan sitä, ihmiset perustavat uuden työn sen pohjalta ja seuraava deploy, joka todennäköisesti tapahtuu muutaman tunnin sisällä, työntää sen ulos. Joten koska et todellakaan halua, että joku muu työntää jotain kirjoittamaasi, joka rikkoo asioita, ihmisillä on tapana varmistaa, että se on todella vakaa, kun se yhdistetään, ja ihmisillä on myös tapana työntää omia muutoksiaan.

Campfire-robottimme, hubot, voi tehdä deploytoja kenelle tahansa työntekijälle, joten pelkkä:

hubot depoy github to production

pystyy tekemään deploytuksen koodista ja käynnistämään nollatilanteessa uudelleen kaikki tarvittavat prosessit. Voit nähdä, kuinka yleistä tämä on GitHubissa:

Näet, että 6 eri ihmistä (mukaan lukien tukihenkilö ja suunnittelija) ottaa käyttöön noin 24 kertaa yhden päivän aikana.

Olen tehnyt tämän haaroille, joissa on yksi yhden rivin muutoksen sisältävä commit. Prosessi on yksinkertainen, suoraviivainen, skaalautuva ja tehokas. Voit tehdä sen feature-haaroilla, joissa on 50 commitia, jotka kestivät kaksi viikkoa, tai yhdellä commitilla, joka kesti 10 minuuttia. Prosessi on niin yksinkertainen ja kitkaton, että sinua ei ärsytä, että joudut tekemään sen edes yhden commitin kohdalla, mikä tarkoittaa, että ihmiset harvoin yrittävät ohittaa tai kiertää prosessin, ellei muutos ole niin pieni tai merkityksetön, ettei sillä ole väliä.

Tämä on uskomattoman yksinkertainen ja tehokas prosessi. Luulen, että useimmat ihmiset ovat samaa mieltä siitä, että GitHubissa on erittäin vakaa alusta, että ongelmiin puututaan nopeasti, jos niitä ylipäätään ilmenee, ja että uusia ominaisuuksia otetaan käyttöön nopeaan tahtiin. Laadusta tai vakaudesta ei tingitä, jotta saisimme enemmän nopeutta tai yksinkertaisuutta tai vähemmän prosessia.

Johtopäätös

Git itsessään on melko monimutkainen ymmärtää, sen kanssa käytettävän työnkulun tekeminen monimutkaisemmaksi kuin on tarpeellista on vain lisää henkistä taakkaa kaikkien päivään. Kannustaisin aina käyttämään yksinkertaisinta mahdollista järjestelmää, joka toimii tiimillesi, ja tekemään niin, kunnes se ei enää toimi, ja sitten lisäämään monimutkaisuutta vain silloin, kun se on ehdottoman tarpeellista.

Tiimeille, joiden täytyy tehdä virallisia julkaisuja pidemmällä aikavälillä (muutamasta viikosta muutamaan kuukauteen julkaisujen välillä) ja pystyä tekemään hot-fixejä ja ylläpitohaaroja ja muita asioita, joita syntyy, kun toimituksia tehdään niin harvoin, git-flow on järkevä, ja suosittelisin vahvasti sen käyttöä.

Tiimeille, jotka ovat luoneet toimituskulttuurin, jotka työntävät tuotantoon joka päivä, jotka testaavat ja ottavat käyttöön jatkuvasti, suosittelisin jotain yksinkertaisempaa, kuten GitHub Flow’ta.