Lisää läskiä työnkulkuun, osa 3: GitLab ja vastaavat

Edellisissä artikkeleissa käsiteltiin hallintarepoa ja r10k:ta. Vaikka mikään ei estäkään hallintarepon pitämistä Puppetmaster-koneella ja r10k.yaml:n osoittamista siihen, menetettäisiin silloin monta työvaihetta eikä ratkaisu siten sopisi tämän artikkelisarjan teemaan. Viimeinen puuttuva komponentti työnkulun läskiyttämisessä onkin GitLab tai vastaava, kuten GitHub tai Bitbucket. Näistä ensimmäinen soveltuu parhaiten tilanteeseen, jossa halutaan luoda paljon yksityisiä Git-repoja, joista ei haluta maksaa, eikä GitLabin edistyneemmille ominaisuuksille ole käyttöä. GitHubissa jokainen yksityinen repository maksaa, joten se on kallis ratkaisu yksityisten puppet-moduulien säilömiseen. Bitbucket sallii GitLabin tavoin rajoittamattomasti yksityisiä repositoryjä, mutta rajoittaa käyttäjien määrän tällä hetkellä viiteen, eikä tarjoa merkittävästi etuja, paitsi ehkä Trello-integraation, jos Kanbania haluaa käytellä. GitLabilla on puolellaan vielä se etu, että se on avointa lähdekoodia, joten sen voi asentaa myös omaan sisäverkkoon ja käyttää sieltä.

Työnkulku on GitLabin ja sen kaltaisten järjestelmien kanssa jokseenkin sama. Lisäksi valmisteluvaihe on jokseenkin identtinen:

  • Luodaan GitLabiin tarvittavat käyttäjätilit
  • Kukin käyttäjä luo SSH-avaimen ja liittää sen GitLab-käyttäjäänsä
  • Luodaan GitLabiin organisaatio
  • Liitetään GitLab-käyttäjät organisaatioon
  • Sallitaan GitLab-käyttäjien julkaista (“push”) organisaation Git repoihin
  • Luodaan nk. deploy key, joka on siis SSH-avain
  • Luodaan GitLabissa hallintarepo-projekti (nimeltään esim. “control-repo” tai “control”)
  • Muutetaan hallintarepon oletushaaran nimeksi “production” (ohjeita)
  • Annetaan GitLabissa hallintarepoon “vain luku”-oikeus deploy avaimella
  • Kukin käyttäjä kloonaa hallintarepon itselleen esim. kannettavalleen Gitillä

Edellisessä artikkelissa kerrottiin, miten r10k konfiguroidaan käyttämään GitLabin kanssa oikeaa SSH-avainta eli “deploy keytä”. Kun kaikki yllä mainitut valmistelut on tehty, voidaankin siirtyä varsinaiseen työnkulkuun, joka menee tyypillisesti näin.

Ensin käyttäjä päivättä oman hallintarepo-klooninsa production-haaran:

$ git branch
 * production
 $ git pull

luo paikalliseen hallintarepon klooniinsa uuden haaran (ns. “feature branch”):

$ git branch feature_a
 $ git checkout feature_a

Seuraavaksi hän tekee tarvittavat muokkaukset ja commitoi (“commit”) muutokset:

$ git add file
 $ git commit -m "Add feature a"

Sitten hän julkaisee muutokset GitLabissa:

$ git push origin feature_a

Muutokset siis löytyvät nyt GitLab-reposityn haarasta feature_a.

Seuraavaksi käyttäjä tekee “Merge requestin” GitLabin käyttöliittymällä. Yleensä GitLab osaa valita oikean lähdehaaran automaattisesti, mutta jos näin ei ole, voi sen valita myös käsin. Merge requestin kohteeksi valitaan tyypillisesti production-haara, mutta mikään ei estä erillisen, pitkäikäisen testing tai staging-haaran käyttöä ennen production-haaraan siirtämistä.

Jonkun toisen käyttäjän olisi hyvä seuraavaksi tarkistaa Merge requestin sisältämät muutokset niiden laadun varmistamiseksi. Tässä vaiheessa on myös mahdollista ja jopa järkevää ajaa r10k Puppetmasterilla, jolloin se luo Puppet environmentin feature_a:

$ r10k deploy environment

Nyt uutta ominaisuutta (“feature_a”) voi testata oikeilla Puppetiin liitetyillä koneilla tähän tapaan:

$ puppet agent -tv --environment=feature_a --noop

Testikoneilla komento voidaan turvallisesti ajaa myös ilman --noop -vipua.

Jos muutokset näyttävät hyviltä ja toimivat odotetulla tavalla, voi tarkistava käyttäjä liittää (“merge”) ne hallintarepoon, jolloin ne päätyvät sen production-haaraan.

Seuraava ja viimeinen vaihe on uuden production-haaran sisällön vienti oikeasti tuotantoon r10k:lla:

$ r10k deploy environment

Sama prosessi toistetaan aina muutoksia tehdessä.

Jos (ja vain jos) Puppetia käyttää ainostaan yksi henkilö, voi merge requestit halutessaan unohtaa ja tarkistaa muutokset pelkästään Gitin omilla työkaluilla eli lähinnä “git diff”-komennolla. Erillisten feature-haarojen käyttö on kuitenkin perusteltua, koska se helpottaa uuden koodin testausta r10k:lla. Testien jälkeen muutokset voi liittää (“merge”) production-haaraan ja julkaista suoraan:

$ git branch
 * feature_a
 production
 $ git push origin feature_a
 $ r10k deploy environment
 --- testaus ---
 $ git checkout production
 $ git merge feature_a
 $ git push

Artikkelisarjan muut osat: