-
Notifications
You must be signed in to change notification settings - Fork 3
FI 5
Hacklab Helsinki #web-kehitys
kurssi 21.4.2021 - 26.5.2021
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: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.🕊)
- "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ä.
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.
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.
-
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
-
Install Docker Desktop on Windows
Huom: Kohdan "Download and install the Linux kernel update package." voinee ohittaa.
Paina nappia, lataa ja asenna. 😊
Docker Desktop for Windows perustuu WSL2:lle, jonka pitää olla asennettuna etukäteen.
Jotta saamme GitHub - Cloud Build -integraation toimimaan, pitää sinulla olla jokin repo, jota CI:llä seurataan.
Voit forkata tämän:
- firebase-jest-testing
- paina
Fork
$ git clone https://github.com/<sinun-tunnus>/firebase-jest-testing.git
$ cd firebase-jest-testing
-
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.
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.
-
GCP Console > projekti >
≡
>Cloud Build
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ä repossacloudbuild.yaml
ei ole sen juuressa.
-
- 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.
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 projektiinmake push
- Käännä
-
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.
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.
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ä:
-
julkaisuun vaadittavat tunnukset voidaan pitää pienemmän porukan tiedossa (CI:n asetuksissa)
- ..jolloin isommalle porukalle voidaan tarjota mahdollisuus "viedä asioita tuotantoon"
-
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