Mit Håndværk udgiver sig selv i to app stores — og en rigtig telefon har vetoret

En pollende CI, ikke en webhook. Hvert tiende minut spørger build-hosten repositoryet, om main har flyttet sig. Et nyt commit tager en single-flight-lås (et signeret build tager længere end ti-minutters-ticket) og registreres, når det er bygget — med store-uploaden sporet i sin egen tilstand, så en forbigående upload-fejl prøver igen på næste tick i stedet for stille at blive markeret som færdig. Kun main bygges nogensinde: testbranches kan pushes hele dagen uden at udgive noget.

En host-gate, der kører, før der overhovedet findes et artefakt. Dependencies resolves, statisk analyse kører, unit- og widget-suiten kører som en hård gate — 44 tests i dag, op fra 3 da gaten blev indført — repository-hygiejnen tjekkes, og den live backend probes read-only: REST-endpointet skal svare 200, og den offentlige WebSocket skal gennemføre et rigtigt handshake gennem Cloudflare. En fejl her betyder, at der slet ikke produceres nogen APK, en alarmmail sendes, og det dårlige commit markeres, så det ikke prøves igen hvert tiende minut i al evighed.

Så får telefonen vetoret. Det signerede build kopieres til en anden maskine, der har virtualisering, en Android-emulator booter headless, og appen installeres forfra: lageret ryddes, loggen ryddes, og appen startes gennem den rigtige launcher-intent. Ti sekunder senere assertes to ting: processen lever stadig, og der står ingen fatal exception i loggen. Et screenshot hentes tilbage som bevis — det er telefonpanelet i billedet ovenfor, produceret af pipelinen selv, ikke iscenesat til denne side.

Dommen er trevejs, og det er den vigtige del. Pass udgiver. En reel launch-fejl blokerer altid udgivelsen, kan aldrig omgås af noget flag og er terminal, så et ødelagt commit ikke testes og alarmeres igen hvert tiende minut. »Testrig utilgængelig« er sit eget udfald: det blokerer også som standard, men behandles som forbigående — releasen prøver simpelthen igen, når riggen kommer tilbage. En operatør kan aktivt slå udgivelse uden device-tjek til, og den kontakt leveres slået fra.

Ingen bumper en version i hånden. Før upload spørger pipelinen Google Play om den højeste versionCode, den nogensinde har set på tværs af bundles, APK'er og track-releases, lægger én til og stempler den på buildet. Uploaden går til production-tracket som en færdig release, og en mail rapporterer version, build-nummer, commit og smoke-udfaldet — med en emnelinje, der siger, om device-tjekket bestod, blev sprunget over eller blokerede releasen.

Apple, styret fra en Linux-host. Et release-tag udløser en cloud-macOS-builder, og tagget gates, før det overhovedet pushes: et script forespørger App Store Connect og asserter, at hvert abonnementsprodukt er APPROVED til den forventede pris i danske kroner — hvis ikke, pushes tagget ikke, og intet shippes. Det identiske tjek er vendoreret ind i cloud-buildet som sit eget trin, så selv et håndpushet tag fejler ved gaten i stedet for at producere en signeret release med et ødelagt købsflow. Det er bevist i begge retninger: en bevidst falsk produktliste fejlede et scratch-build ved gaten med nul artefakter, og det første rigtige gatede release-tag gik gennem alle fjorten trin ind i TestFlight.

iOS-banens øvrige trin er alle sammen lærepenge. Swift Package Manager er slået fra, så CocoaPods alene embedder push-frameworket (begge på én gang gav duplikerede frameworks ved archive-tid); de fem credentials valideres, før noget dyrt går i gang; den committede lock-fil droppes, så pods resolver forfra; automatisk kodesignering tvinges til manuel — kun i CI — fordi det committede projekt er rettet mod en udviklers maskine, og en ubemandet runner ikke har nogen Apple-konto at signere interaktivt med; signeringsfiler hentes til begge bundle-identifiers — appen og dens notification extension; og build-nummeret tages fra det seneste TestFlight-build plus én, så et re-tag aldrig kræver en versionsrettelse.

iOS-tests kører også i skyen. Et andet workflow uden egen trigger startes gennem build-udbyderens REST-API, booter en iOS-simulator og kører integrationstestene — og sådan får en ren iOS-ændring et rigtigt testresultat fra en Linux-host, der ikke kan bygge til iOS.

Og hver morgen, uafhængigt af enhver release, bruges den samme enhed igen. Det nyeste build geninstalleres, og det assertes, at det starter; derefter reseedes fire abonnementstilstande på backenden — aktiv, to varianter af opsagt og udløbet — appen drives efter fixture, og abonnementsskærmen læses tilbage med OCR. Det er ikke et stilistisk valg: et Flutter-view når aldrig accessibility-tilstanden »idle« og eksponerer ingen tekstnoder til det standardiserede Android-tooling, så at læse pixels er den eneste pålidelige måde at asserte, hvad brugeren faktisk får at vide. Det findes på grund af en rigtig bug — et opsagt abonnement, der meldte, at det udløb »om 0 dage« — og det vogter hele kæden, fra gemt ordretilstand gennem den live reconcile til det, API'et og socketen rækker appen. Det alarmerer kun på en reel app-defekt og tier stille, når riggen bare er slukket; infrastruktur-hikke råber aldrig ulven kommer.