mikaelbr
commented
2 years ago Det fantes cloud build løsninger fra før som ble tilpasset. Det er ikke bygging med PRs på samme måte, men det er OK nok i en overgangsperiode. Mulig vi også kan bruke cloudbuild på PR, men ikke prioritert akkurat nå.
Per nå blir bygging ut til Firebase Hosting gjort via Github Actions. Det kan være et punkt hvor også hosting av nettbutikk blir en del av større utrullingsmekanismer og k8s, men det kan være langt frem i tid. Det kan også være noen ulemper med å gjøre det: Kostnad/kompleksitet på utrulling av alt for hver PR endring. Dette er en egenskap jeg ser på som nyttig i bruk av QA, forankring til andre i organisasjon og for generell teknisk testing. Dette gjør Firebase Hosting og tilsvarende løsninger veldig bra. Hver endring blir synlig under sin egen URL.
Ulempen er at alt ligger som secrets i GH og flatet ut som miljøvariabler. Det kan bli en utfordring for selskaper som er en del av OOS om de skal rulle ut egne versjoner. Også med å holde tritt med oppdateringene som skjer. Det er noen ulike strategier som jeg greier å tenke ut nå:
1. Kjøre separat egen utrulling via eksterne CI-løsninger.
Unngår utvidelse av eksisterende løsning.
Det vil gjøre at det er ulike løsninger som står for bygging og utrulling. Det blir en potensiell kommunikativ foot gun i alle situasjoner hvor ting må endres eller utvides. Det blir større distanse mellom ulike løsninger som alltid er en risiko.
Det må også løses på litt ulike måter og kan få ulike behov for hvordan byggingen gjøres. Må utredes litt mer konsekvensene om det faktisk fører til kodeendringer.
2. Kjøre egen fork repo med periodisk sync og egen secrets i settings.
Unngår utvidelse av eksisterende løsning.
Unngår ulikt oppsett for CI i motsetning til alternativ 1. Men noe av samme ulempene vedvarer: Dersom byggescripts endres og har behov for flere miljøvariabler fører det til feil hos andre. Dette kan håndteres med å fikse feilene når det oppstår, men det blir ofte reaktivt da det skjer i et annet repo og er helt async i byggingen.
Vil også være en ulempe at det ikke blir bygd til alle miljø på PR f.eks. Det holdes kun i sync med main branch.
3. Kjøre egne workflows som er kopier (eller gjenbruk) med egne miljøvariabler i "flat liste"
Gir fleksibilitet og er sikkert det enkleste å gjøre (simple vs easy blablaosvosv).
Vil sannsynligvis føre til duplisering av kode selv om det finnes noen måter å gjenbruke på. Det vil være mange miljøvariabler for å håndtere staging, dev, prod * antall selskaper. Når det er flere selskaper så blir det vanskelig å ikke rote til for andre.
Grensen på miljøvariabler på repo er på 100. Jeg tror ikke denne kommer til å overgås, selv med alle fylkeskommuner i Norge og noen fra Sverige.
4. Strukturere opp bruk av krypterte miljøvariabler som en del av repo
Denne krever sikkert mest forklaring på fremgangsmåte. Det er og uprøvd og bare en hypotese på hvordan ting kan gjøres, som må testes ut om det er mulig å gjennomføre. Løse tanker om hvordan det kan gjøres:
secrets.jsonsom inneholder variabler.Dersom webshop krever miljøvariabler som ikke gir byggefeil kan det føre til at ved utvidelse av nye envs så brekker man andre bygg. Særlig kritisk ved utrulling av prod. Viktig at input valideres og kontrolleres av eksistens. Men det er uansett viktig og en fin praksis.
Noe mer tungvindt å oppdatere miljøvariabler med dekrypt + rekrypt.
NB: Mulig det må håndteres slik at secrets ikke vises i byggelog.
Denne kan gjøres mye likt dersom man serialiserer og legger secrets som JSON-struktur direkte som ENV (tilsvarende som firebase config gjør i dag). Men det kan bli en potensiell ulempe med maksbegrensning på 65KB. Har ikke gjort noe realistiske kalkulasjoner her, så det må eventuelt gjøres. Det er også en farbar veg å starte med det for å utvide til egne filer ved behov. Filer har en fordel med at du grupperer ting som hører sammen under samme område og som en del av input til systemet. Samtidig er filer hakket mer kompleks løsning på det.
Uansett løsning må det sikkert kartlegges/tenkes litt igjennom om konsekvensene av å automatisk rulle ut til prod via samme forløp. Betyr det at ingen har feil dersom AtB ikke har feil? Hvordan kontrolleres regresjoner?