Sådan konfigureres kontinuerlig integration til din ildbase-app

En fin dag besluttede jeg, at jeg skulle prøve det skinnende nye barn på markedet, ildbase.

Firebase kom med en masse funktioner indbygget og dem alle i en let plug and play slags implementering. Efterhånden som vi blev købt af google, så vi en række nye funktioner komme i spil, nemlig stor fillagring og forbedret autentificering.

Så langt så godt.

For et par dage tilbage overvejede jeg at hacking sammen en messenger-app over ildbase, og det havde været en rutsjebane tur derfra. Mens appen i sig selv er temmelig ligetil, havde CI-delen været sjov.

Jeg har personligt aldrig opsat nogen CI for nogen af ​​de projekter, jeg arbejdede for. Dette er mit første forsøg på at opsætte et. Så før vi går i dybden, en lille ansvarsfraskrivelse.

Dette er på ingen måde en tutorial eller en ekspertguide. Det er simpelthen en beretning om min rejse for at forstå et undvigende koncept.

Jeg ville ikke lege med Jenkins dette tidligt i min læringscyklus og besluttede derfor at gå videre med Gitlab CI, da min kode allerede var der.

For at opsætte CI har gitlab simpelthen brug for en fil med navnet .gitlab-ci.yml i roden af ​​projektet. Når den er tilføjet, forsøger den indbyggede CI at bygge dit projekt ved at køre opgaver som nævnt i YAML.

Nok tale. Lad os se noget kode :)

Lad os prøve at nedbryde den ene linje ad gangen.

image: node: seneste

Dette trækker det nyeste billede af node ind i din forekomst. Da min app er bygget over npm, som i, bruger jeg npm som min pakkeadministrator og dermed node.

before_script:
 - kl. Svis
 - npm installation
 - npm installere -g grunt-cli
 - npm installere -g firebase-værktøjer

Denne blok instruerer min CI til at køre et sæt kommandoer inden udførelse af nogen af ​​mine stadier. For at tage det ovenfra har vi npm-sviske, hvis anvendelse som pr. Dokumentation er:

#npm sviske
Denne kommando fjerner “udvendige” pakker. Hvis der gives et pakkenavn, fjernes kun pakker, der matcher et af de medfølgende navne.
Ekstreme pakker er pakker, der ikke er angivet på overpakkens liste over afhængigheder.

Derefter har vi npm installation til at installere alle afhængigheder af min app.

Npm-installation -g grunt-cli & npm-installation -g firebase-værktøjer er stort set selvforklarende. Ellers google det. :)

niveauer:
 - indsætte

Denne blok erklærer stadierne i build-rørledningen. I øjeblikket har vi kun en implementeringsfase. Kontroller https://gitlab.com/help/ci/yaml/README.md#stages

Hvis det er nødvendigt, kan man vælge at tilføje hele sættet.

Gå videre, der er

cache:
 stier:
 - node_moduler /
 nøgle: "$ CI_BUILD_REPO"

Dette er den sjove del. Den fortæller CI-motoren at cache mappen node_moduler på tværs af builds. Dette betyder, at alle dine node_moduler ikke behøver at blive downloadet, hver gang du udløser en build.

Det centrale argument er faktisk den identifikator, hvormed cacher valideres. Læs https://gitlab.com/help/ci/yaml/README.md#cachekey

deploy_to_firebase:
 scene: implementere
 kun:
 - mester
 manuskript:
 - grym alle
 - brandbaseudstationering - token $ FIREBASE_DEPLOY_KEY

Endelig har vi implementeringsdelen. Denne blok er blevet mærket deploy_to_firebase. Dette ligner mere et brugerdefineret job. Det leveres med et sæt opgaver, som CI har til at køre. Går linje for linje,

scene: implementere

Dette mærker den fase, denne opgave peger på. I dette tilfælde er det implementeret.

kun:
 - mester

Dette fortæller, at CI kun skal køre builds, når git master branch ændres. Læs https://git-scm.com/book/da/v2/Git-Branching-Branches-in-a-Nutshell.

manuskript:
 - grym alle
 - brandbaseudstationering - token $ FIREBASE_DEPLOY_KEY

Dette er den sidste del af tilpasset implementeringsjob.

Herinde beder vi CI om at køre vores forudkonfigurerede gryntopgave alle.

Denne opgave transponerer ES6, kompilerer min JSX, minimerer min css og kopierer til sidst over de indbyggede filer til et build-bibliotek til distribution over wire til firebase.

Så er der: ildbaseudstationering - token $ FIREBASE_DEPLOY_KEY

$ FIREBASE_DEPLOY_KEY er faktisk en beskyttet variabel. Dette bruges af distributionskommandoen til at autentificere med ildbase, at installationen er gyldig. Da det er et adgangstoken, må man ikke udsætte det som en del af koden. Derfor opretholdes dette som en env-variabel.

$ FIREBASE_DEPLOY_KEY genereres af firebase login: ci-kommandoen. Læs https://firebase.google.com/docs/cli/#administrative_commands.

Og det er det.

Skub til hoved, og det skal begynde at bygge.

Held og lykke og god hastighed :)

PS: læs op på ES6, Reager og grynt, og vend om nødvendigt tilbage til mig med kommentarer.