Skip to content

FI 5

Jump to bottom
Asko Kauppi edited this page May 28, 2021 · 5 revisions

Hacklab Helsinki #web-kehitys kurssi 21.4.2021 - 26.5.2021

5. CI - Vähittäinen integraatio

Kuva: Wikimedia, Gallery of Modern Art, Brisbane, 2011, CC-BY 3.0

Jatkuva integraatio (engl. continuous integration) on ohjelmistotuotannon menetelmä useiden tekijöiden lähdekoodimuutoksien yhdistämiseen yhteen ohjelmistoprojektiin. Menetelmä esiintyy DevOps-kehityksen yhteydessä, jossa automatisoidut toiminnot varmistavat koodin oikeellisuuden. Menetelmän tavoitteena on löytää ohjelmointivirheet nopeammin, parantaa ohjelmiston laatua ja lyhentää aikajaksoa päivityksen tarkistamiseen ja julkaisemiseen. Lähde: Wikipedia

Tänään:

  • asetamme yhden CI-putken kuntoon (GitHub ja Cloud Build)

  • keskustelemme tällaisen tarpeellisuudesta

  • keskustelemme, miten laajemman web-projektin CI pitäisi hoitaa / mitä hyötyjä, haittoja jne.

  • katsomme taaksepäin, saaden kokonaiskuvaa web-kehityksestä 2021.

CI näyttää tältä

Mitä CI:llä haetaan?

CI:ssä on kyse oikeastaan robotin saamisesta mukaan kehitystiimiin.

Miksi "robotin"?

CI:llä voidaan toteuttaa mitä vain toimenpiteitä. Triggerinä voi olla:

  • uuden koodin tulo repon tiettyyn haaraan (push to a branch)
  • PR:n teko (tai muutoksia siihen) tiettyä haaraa kohtaan (pull request)
  • ajan kuluminen (scheduled)
  • manuaalinen ajo
  • ...
  • PubSub, Webhook event

Nämä mahdollistavat kaikenmoisia työketjuja (workflow) ja CI:n teko onkin aika käsipeliä.

Kyseessä on enemmän kehitystyön prosessiasia kuin tekninen juttu. Kunkin organisaation / koodaajan tulisi tehdä oman näköisensä CI-viritelmä.

(Ne ovat aina viritelmiä; eivät koskaan valmiita. Se on ok.🕊)

Jälleen filosofiaa!? 😛

  • "Pidetään potilas hengissä"
  • pieniä muutoksia "small moves, Ellie"
  • mahdollisuus palata nopeasti aiempaan

Paloittelee riskit pienemmiksi.

Näyttää kaikille, koko ajan, todellisen tilanteen (jos yhdistettynä testaukseen..).

Mitä ketterä vs. hidas prosessi -esimerkkejä tunnet? Onko hitaassa prosessissa hyötyjä? Voisiko CI-työkaluja käyttää myös siinä?

Tiimityössä CI voi toimia tiimiläisten koodeja yhdistävänä tekijänä. Tällöin sovitaan "liikennesäännöt" (koodin tyylitys jne.) ja CI:n tehtävänä on tarkistaa, että näissä pysytään. Näin tiimiläisiltä menee vähemmän aikaa keskinäiseen koodien yhteen sovitteluun.

1 hengen työssä CI:llä on kaverin rooli. Ja on kiva nähdä "vihreää" PR:n yhteydessä.

Miltä CI näyttää?

Tässä GitHubin haarasta on tehty PR ja sen sisältö näyttää läpäisevän testit.

CI-ajo on meneillään.

Jokin meni pieleen. Tätä PR:ää ei tällaisenaan tulisi ottaa käyttöön.

CI käyttökuntoon laitto

Asetetaan CI-työketju firebase-jest-testing -repolle, joka on Firebasen backend-testaukseen käytettävä työkalu.

Haluamme ajaa npm test kun repoon tulee uusi, master-haaraan menossa oleva PR.

CI:llä voi tehdä myös esim. tuotantoonlaittoa Firebaseen. Tällöin sille pitää antaa lisäoikeuksia ("service account"-avain), joita nyt emme tarvitse, koska kyseessä on vain testaus, jonka voisimme yhtä hyvin ajaa myös omalla koneellaamme.

Tarvitaan

  • gcloud CLI-työkalu
  • Docker
$ gcloud --version
Google Cloud SDK 316.0.0
...

Kirjoittamisen aikaan Debian-paketoinnin antama versio, jolla ohjeet on testattu (Windows 10 + WSL2).

gcloud asennus Windows 10 + WSL2:lle

$ sudo apt-get install google-cloud-sdk`

Tämä asennus ei tue gcloud components update -päivitystapaa ja versiona laahaa vähän uusimpien perässä. Jos haluat uusimmat, seuraa perus-Linux asennusohjeita.

Meille apt-get:n kautta tehty asennus kuitenkin riittää.

Docker Desktop Windows 10:lle

Docker Desktop for Windows perustuu WSL2:lle, jonka pitää olla asennettuna etukäteen.

Forkkaa repo

Jotta saamme GitHub - Cloud Build -integraation toimimaan, pitää sinulla olla jokin repo, jota CI:llä seurataan.

Voit forkata tämän:

$ git clone https://github.com/<sinun-tunnus>/firebase-jest-testing.git
$ cd firebase-jest-testing

GitHub: App triggers enablointi

  • GitHub Marketplace > "Google Cloud Build" aplikaatio

    • Set up a plan
    • ... Only select repositories voi olla hyvä?
    • Install

    • Authorize Google Cloud Build

Lopun (Google Cloud-puolella) sait mennä omin voimin. Toivottavasti onnistuit..?

Tämän ansiosta Google Cloud Build saa tiedon GitHubin repoon tehtävistä Pull Request:eista.

Seuraavaksi tuunataan, mitä tapahtuu kun tällainen PR havaitaan.

Cloud Build: Enable APIs

Tämä pitää tehdä ennen kuin Cloud Build toimii.

  • GCP Console > projekti > ≡ > APIs & Services > Enable APIs and Services

Tässä kohtaa GCP haluaa, että luot maksutilin ja tarkistaa puhelinnumeron avulla, että sinuun saa yhteyden.

Jos menet eteenpäin, alkaa 90 päivän tulokasalennuksen (300 USD) laskuri raksuttaa. Sen edun saa käyttöön vain kerran, mutta toisaalta harva saa aikaan järkeviä kuluja ensimmäisinä kuukausina (aiemmin tuo 300 USD oli tarjolla koko vuoden).

Käytännössä kustannuksia tuskin tulee, mutta periaatteessa voi tulla. Niistä voi kokonaan välttyä esim. poistamalla "billing account":in (varsinainen tili ja projektit voivat jäädä) kun on kokeillut tarpeeksi.

Cloud Build: Trigger

Vinkki: voit kiinnittää useasti käyttämäsi GCP-osiot valikossa 📍

  • Triggers > Create Trigger

    Mennään tämän kuvan mukaan.

    • nimi: esim. pr-to-master

    • kuvaus

    • (o) Pull request (GitHub App only)

    • Repository: (valitse)

    • Base branch: ^master$

    • Show included and ignored files filters (klikkaa)

      • Ignored files: lisätään *.md, .images/**.

        Näin pelkkien dokumenttien muutokset eivät laukaise CI-ajoa.

    • (o) Cloud Build configuration file (YAML or JSON)

      ..ja poluksi /ci/cloudbuild.yaml. Tämä tarvitaan sen takia, että kyseisessä repossa cloudbuild.yaml ei ole sen juuressa.

Demo!

  • Tehdään jokin PR
  • Mitä GitHub:ssa näkyy?
  • Käynnistyykö CI-ketju?

Ei toimi, koska sillä ei ole pääsyä firebase-ci-builder Docker-kuvaan.

Build the builder

Firebase-emulaattorien ajamiseen ei ole tarjolla hyvää, julkisesti tarjolla olevaa Docker-image:a. Niinpä sellainen pitää rakentaa itse.

  • gcloud auth login

    • onko projekti sopiva?

  • Kloonaa firebase-ci-builder

    • Käännä make build ja tuuppaa projektiin make push

  • Käynnistetään aiemmin epäonnistunut CI-ajo uudelleen

  • toimiiko nyt?

Käydään katsomassa, miltä PR näyttää.

GitHubin ja GCP:n välinen integraatio toimii aika hyvin. Vaikka käynnistimme viimeisen ajon GCP:n konsolissa, GitHub tietää, että se on sama ajo, josta kyseinen PR on kiinnostunut.

Voimme siis painaa Merge pull request ja tietää, että jatkossa luodut PR:t saavat saman testikäsittelyn.

Yhteenveto

CI-työpolun toimimaan laitto ei ole ihan yksinkertaista. Vaikka perusteet ovat samat, se myös eroaa käytännössä paljonkin eri toimijoiden välillä.

Tässä haluttiin käyttää Cloud Build:ia, koska se sopii muuten kyseiseen projektiin. Myös GitHub ihan itsessään sisältää CI:n ja pienelle projektille sen käyttöönotto on luultavasti suoraviivaisempaa.

Yksi yllättävä yksityiskohta oli, että git push origin/master hyväksyttäminen CI:llä ei Cloud Build:iä käytettäessä onnistu. Pohditaanpa, miksi..?

CI ei ole välttämätön osa projektia, mutta suositeltava. Kun sen on kerran laittanut pystyyn, muokkaaminen ja laajentaminen on suhteellisen helppoa.

Toisaalta CI on vähän kuin lemmikki - sitä ei tule ottaa, koska muillakin on...

CI-setin kuntoon laiton jälkeen, alkuperäisen web app -repon kontekstissa, sen tekijä harkitsee laittavansa myös kehityksen aikaisen testauksen Dockerin alaisuuteen. Näin samaa työkalusettiä (ja versioita) käyttäisivät kaikki kehittäjät, sekä CI.

Turvallisuusnäkökohtia (CD)

Jos CI:tä käytetään tuotosten (automaattiseen tai semi-automaattiseen) vientiin tuotantoon, asiasta käytetään nimeä "Continuous Delivery". Siitä termi "CI/CD".

CI/CD:llä voidaan poistaa tarve antaa (kaikille) kehittäjille tuotannon avaimet. Tästä on (ainakin) kaksi hyötyä:

  1. julkaisuun vaadittavat tunnukset voidaan pitää pienemmän porukan tiedossa (CI:n asetuksissa)

    • ..jolloin isommalle porukalle voidaan tarjota mahdollisuus "viedä asioita tuotantoon"

  2. mahdollisuus tietovuotoihin vähenee

    • yksittäisen kehittäjän koneella on vain hänen tunnistautumisensa GitHubiin (ja sen voi tehdä 2FA:lla turvalliseksi), joten jos kone varastetaan tai sen tiedot vuotavat, vahinko voidaan rajata nopeammin

Seuraavaksi: Loppusanat

Clone this wiki locally