CI/CD Pipeline

Alt du trenger for a forsta og bruke CI/CD-pipelinen i Impulse AI. Skrevet for soloutviklere som vil ha full kontroll uten a vaere DevOps-ekspert.

Hurtigreferanse

Oppgave	Kommando
Ny feature-branch	git checkout -b feat/min-feature
Kjor med secrets lokalt	doppler run -- pnpm dev
Promoter staging til production	/deploy-prod eller git push origin main:production
iOS til TestFlight	fastlane ios bump type:patch (oppretter git tag v*)
Promoter til App Store	/promote eller fastlane ios promote
Manuell DB-migrasjon	db-deploy.yml -> dry-run / migrate
Sjekk CI-status	gh run list --limit 5

---

1. Hva er CI/CD?

CI/CD star for Continuous Integration (CI) og Continuous Deployment (CD). I praksis betyr det at koden din blir automatisk testet og deployet nar du pusher den til GitHub.

Continuous Integration (CI)

Hver gang du pusher kode eller apner en pull request, kjorer GitHub Actions automatisk en serie sjekker: linting, typechecking, tester, kompilering. Alt dette skjer for koden merges til main.

Continuous Deployment (CD)

Nar kode er merget til main, deployes DB+API automatisk til staging (Railway + Supabase staging). Nar du promoterer til production (git push origin main:production), deployes DB+API til production (Railway + Supabase production).

iOS har en separat release-syklus: git tags (v*) trigger TestFlight-bygg via Fastlane, og promotering til App Store gjores manuelt.

Kjerneprinsippet

Kontroll skjer FOR merge, ikke etter. Staging er automatisk. Production er en bevisst handling (/deploy-prod).

Hvorfor er dette viktig for en soloutvikler?

• Sikkerhetsnett: CI fanger feil for de nar brukerne. Du har ikke et QA-team — CI er QA-teamet ditt.
• Konsistens: Deploy-prosessen er identisk hver gang, uansett om det er mandagsmorgen eller fredagskveld.
• Hastighet: En git tag er alt som trengs for a release. Ingen manuell building, uploading, eller huskelister.
• Trygghet: Du kan merge med selvtillit fordi du vet at alt er sjekket.

---

2. Arkitekturoversikt

Her er hele pipelinen visualisert — fra du skriver kode lokalt til den er live i produksjon:

Full pipeline

Lokal dev ──> Feature branch ──> CI Preflight ──> Merge til main
(din maskin)   (git push)       (GitHub Actions)  (PR godkjent)

DB + API (tett koblet):
main branch ──> ┌─ DB staging  ┐
(push trigger)  └─ API staging ┘── STAGING (Railway staging + Supabase staging)

main:production ─> ┌─ DB prod  ┐
(/deploy-prod)     └─ API prod ┘── PRODUCTION (Railway prod + Supabase prod)

iOS (separat syklus):
git tag v* ──> TestFlight ──> App Store
(fastlane)     (automatisk)   (manuell promote)

Systemer involvert

System	Rolle	Trigger
GitHub Actions	Kjorer CI-sjekker og orkestrerer deploys	Push, PR, git tag
Doppler	Secrets management — erstatter .env-filer	Injiseres automatisk
Supabase	Database (PostgreSQL) + Auth	Migrasjoner ved deploy
Railway	API-server hosting (Fastify)	Staging: auto-deploy fra main. Prod: auto-deploy fra production
Vercel	Web-app hosting (Next.js)	Auto-deploy fra main
Fastlane	iOS build-automatisering	Kalles fra GitHub Actions
App Store Connect	TestFlight-distribusjon og App Store	Upload fra Fastlane

---

3. Secrets Management med Doppler

Hva er Doppler? Doppler er en sentral plattform for a haandtere secrets (API-nokler, passord, konfigurasjon). Istedenfor a ha .env-filer liggende lokalt som du maa holde synkronisert, lever alle secrets i Doppler og injiseres automatisk der de trengs.

De tre konfigurasjonene

Doppler har tre separate configs som matcher dine miljoer:

Config	Miljo	Brukes av
dev	Lokal utvikling	Din maskin via doppler run
stg	Staging	GitHub Actions (CI + staging deploy)
prd	Production	GitHub Actions (prod deploy)

Hvordan secrets flyter

                  ┌─ doppler run ────────────> din terminal
                  │
  Doppler ────────┼─ DOPPLER_TOKEN_STG ──────> GitHub Actions (CI)
  (sentralt lager)│
                  └─ DOPPLER_TOKEN_PRD ──────> GitHub Actions (prod deploy)

Bruke Doppler lokalt

Prosjektet har en doppler.yaml i roten som setter opp riktig prosjekt og config:

setup:
  - project: im
    config: dev

Etter forste gangs oppsett (doppler login + doppler setup), kjorer du all lokal utvikling med:

# Starter dev-server med alle secrets injisert som env vars
doppler run -- pnpm dev

# Eller bare API-serveren
doppler run -- pnpm --filter api dev

Legge til eller oppdatere en secret

1. Ga til Doppler Dashboard (app.doppler.com) — velg prosjektet “im” og riktig config (dev/stg/prd)
2. Legg til eller endre secret — klikk “Add Secret” eller rediger en eksisterende. Gjor dette for alle configs der den trengs.
3. Bruk den — lokalt: restart doppler run -- pnpm dev. I CI: automatisk tilgjengelig neste kjoring.

Key rotation (bytte en noekkel)

1. Generer ny noekkel hos tjenesteleverandoren (f.eks. Anthropic, Supabase)
2. Oppdater i Doppler for alle miljoer (dev, stg, prd)
3. Restart/redeploy — lokalt: restart doppler run. Staging/prod: trigger ny deploy.
4. Revoke gammel noekkel hos tjenesteleverandoren

aside.caution

Roter alltid i reikefolgen: generer ny -> oppdater overalt -> revoke gammel. Aldri revoke for den nye er aktiv.

---

4. GitHub Actions — Hva skjer nar du pusher kode?

Nar du pusher til en branch eller apner en PR mot main, starter ci.yml automatisk. Her er en oversikt over hva som skjer:

Steg 1: Detect Changes

Forste jobb bruker dorny/paths-filter for a finne ut hvilke deler av monorepo-et som er endret. Dette betyr at hvis du bare har endret iOS-kode, kjorer ikke API-sjekkene. Effektivt og raskt.

Filter	Stier som overvakes
db	packages/database/**
api	apps/api/**, packages/shared/**, packages/auth/**
packages	packages/**
ios	apps/mobile-kmp/shared/**, apps/mobile-kmp/iosApp/**, Gradle-filer
android	apps/mobile-kmp/shared/**, apps/mobile-kmp/androidApp/**, Gradle-filer

Steg 2: Parallelle sjekker

Basert pa hvilke endringer som ble oppdaget, kjores relevante jobber parallelt:

Database Starter lokal Supabase, kjorer alle migrasjoner med supabase db reset, verifiserer at genererte TypeScript-typer er oppdaterte. Kjorer kun nar: packages/database/** er endret.

API Lint -> Type check (shared + auth + api) -> Test -> Build. Secrets hentes fra Doppler (stg). Kjorer nar: apps/api/** eller packages/** er endret.

iOS Preflight Kjorer pa macos-15. KMP shared-modul kompileres, deretter iOS simulator build via Fastlane preflight lane. Kjorer nar: KMP shared, iosApp, eller Gradle-filer er endret.

Android Preflight Kjorer pa ubuntu-latest. Bygger Android debug APK med assembleDebug. Kjorer nar: KMP shared, androidApp, eller Gradle-filer er endret.

Steg 3: CI Gate

Den siste jobben, CI Gate, venter pa alle andre jobber. Den feiler hvis noen av sjekkene feilet. Jobber som ble skippet (fordi de delene av koden ikke var endret) teller som ok.

aside.note

CI Gate er branch protection-kravet. Du kan ikke merge en PR til main med mindre CI Gate rapporterer suksess. Dette er sikkerhetsnett nr. 1.

Concurrency control

Workflowen bruker concurrency: ci-${{ github.ref }} med cancel-in-progress: true. Det betyr at hvis du pusher to ganger raskt etter hverandre pa samme branch, kanselleres den forste kjoringen automatisk. Ingen bortkastet tid.

---

5. Automatisk Deploy til Staging

Nar kode merges til main (push, ikke PR), skjer staging-deploy automatisk.

To brancher

Branch	Miljo	URL
main	Staging	api-stg.impulseai.app
production	Production	api.impulseai.app

Hva trigger staging?

if: github.ref == 'refs/heads/main' && github.event_name == 'push'

Hva skjer?

Database -> Staging Kjorer supabase db push mot staging-prosjektet. Secrets (project ref, access token) hentes fra Doppler via DOPPLER_TOKEN_STG. Kun nar DB-filer er endret.

API -> Staging Railway overvaker main-branchen og deployer automatisk. Ingen manuell handling nodvendig.

aside.tip

Staging = alltid oppdatert med main. Nar du merger en PR, deployes DB+API automatisk til staging innen minutter. Du trenger aldri a gjore noe manuelt for staging.

---

6. Release til Production

DB + API (tett koblet)

DB og API deployes sammen ved a promotere main til production-branchen:

# Promoter staging til production
git push origin main:production

# Eller via Claude Code:
/deploy-prod

Railway production-service overvaker production-branchen og deployer automatisk. Database-migrasjoner kjores mot produksjons-Supabase.

Forutsetning: Staging er testet og fungerer. main inneholder alltid den nyeste koden som er verifisert i staging.

aside.caution

Concurrency-beskyttelse: Production-deployen bruker cancel-in-progress: false. Det betyr at en pagaende prod-deploy aldri kanselleres.

iOS (separat release-syklus)

iOS har sin egen release-syklus, uavhengig av DB+API:

# 1. Bump versjon og opprett git tag
cd apps/mobile-kmp/iosApp
bundle exec fastlane ios bump type:patch   # 1.0.0 -> 1.0.1

# Eller via Claude Code:
/release ios patch

# 2. Git tag v* trigger TestFlight-bygg automatisk

TestFlight -> App Store:

Etter at iOS-bygget er oppe pa TestFlight, tester du det manuelt. Nar du er fornoyd, promoterer du til App Store:

# Via Claude Code:
/promote

# Eller lokalt:
cd apps/mobile-kmp/iosApp
bundle exec fastlane ios promote

# Eller via GitHub Actions:
# Actions > "iOS Release (manual)" > Run workflow > Velg "promote"

---

7. Fastlane — iOS Build Pipeline

Hva er Fastlane? Fastlane er et Ruby-basert verktoy som automatiserer iOS (og Android) build, testing, og distribusjon. Istedenfor a gjore ting manuelt i Xcode, definerer du “lanes” (oppgaver) i en Fastfile.

Nokkelprinsipp: Fastfilen er “single source of truth”. GitHub Actions kaller bare Fastlane — all byggelogikk bor i Fastfilen.

Tilgjengelige lanes

Lane	Hva den gjor	Nar
preflight	KMP compile + iOS simulator build (ingen signing)	CI pa hver PR
test	Kjorer iOS-tester pa iPhone 16 simulator	Lokal utvikling
beta	Signing -> KMP release -> archive -> TestFlight upload	Production deploy (git tag)
promote	Siste TestFlight-bygg -> App Store Connect	Manuelt etter testing
release	Full pipeline: beta + App Store upload	Force-release (manuelt)
bump	Bump versjon (patch/minor/major) + commit + tag	For release
doctor	Health check: Gradle, Xcode, signing, ASC API key	Debugging

Signing med Match

Fastlane bruker Match for kodesignering. Match lagrer sertifikater og provisioning profiles i et privat Git-repo, slik at de kan deles mellom lokal maskin og CI.

Slik fungerer signing-flyten

1. API-noekkel: App Store Connect API key (ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY) injiseres fra Doppler.
2. Match synkroniserer: Henter certificates og profiles fra Git-repoet. I CI kjorer den readonly (oppretter aldri nye).
3. Build: Xcode bruker provisioning profile fra Match for a signere appen.

Beta lane i detalj

Nar fastlane ios beta kjorer, skjer dette:

1. Sjekk clean git (skippes i CI)
2. Sync signing — henter sertifikater via Match
3. Auto-inkrement build number — henter siste fra TestFlight, legger til 1
4. KMP release framework — linkReleaseFrameworkIosArm64
5. Archive — release-build med export_method: "app-store"
6. Upload til TestFlight — med changelog fra siste 15 commits
7. Commit versjonsbump + tag — beta/v1.2.3-42

---

8. Git Workflow

Branch-basert flyt

feature/* ──> Pull Request ──> main ──────────────> production
(utvikling)   (CI kjorer)      (-> staging auto)    (/deploy-prod)

iOS: fastlane ios bump ──> git tag v* ──> TestFlight ──> App Store
     (/release ios)                        (auto)         (/promote)

Branch-navnkonvensjoner

Prefiks	Bruk	Eksempel
feat/	Ny funksjonalitet	feat/check-in-flow
fix/	Bugfix	fix/session-timeout
chore/	Vedlikehold, opprydding	chore/update-deps
refactor/	Kode-omstrukturering	refactor/store-architecture
docs/	Dokumentasjon	docs/cicd-guide

Commit-meldinger

Folg Conventional Commits-monsteret:

feat(ios): add check-in flow with AI coaching
fix(api): cap breakthroughs to meaningful clusters
chore: update AI prompts and dashboard cleanup
refactor(shared): simplify impulse classification model
docs: add CI/CD complete guide

Format: <type>(<scope>): <beskrivelse>

Branch Protection

• CI Gate required: PR kan ikke merges med mindre CI Gate er gronn
• Aldri push direkte til main: All kode gar via PR
• Squash merge anbefalt: Holder commit-historikken ren

---

9. Claude Code Integration

Claude Code har innebygde kommandoer som mapper til CI/CD-pipelinen:

Kommando	Hva den gjor	Mapper til
/deploy-prod	Promoterer staging til production	git push origin main:production
/release ios [patch|minor|major]	iOS versjonsbump + TestFlight	fastlane ios bump + git tag v*
/promote	Promoterer TestFlight-bygg til App Store	fastlane ios promote
/deploy-status	Viser status pa siste deploys	gh run list
/pr	Oppretter PR med sammendrag	GitHub PR + trigger CI

aside.tip

Du trenger ikke huske de underliggende git-kommandoene. Claude Code abstraherer dem til enkle slash-kommandoer.

---

10. Daglig arbeidsflyt — Steg for steg

Morgen: Sjekk status

# Sjekk om noe har feilet i natt
gh run list --limit 5

# Eller via Claude Code
/deploy-status

Under dagen: Feature-utvikling

1. Lag feature branch

   git checkout -b feat/min-nye-feature

2. Utvikle og commite

   # Jobb pa koden...
   git add -A
   git commit -m "feat(ios): add awesome feature"

3. Push og la CI gjore jobben

   git push -u origin feat/min-nye-feature
   # CI starter automatisk

Klar for merge

1. Opprett PR

   # Via Claude Code
   /pr
   
   # Eller manuelt
   gh pr create --fill

2. Vent pa CI Gate — gronn checkmark i GitHub

3. Merge til main -> staging deployes automatisk

Klar for production (DB + API)

1. Verifiser at staging fungerer

   # Sjekk staging-deploy
   gh run list --branch main --limit 3

2. Promoter til production

   # Via Claude Code:
   /deploy-prod
   
   # Eller manuelt:
   git push origin main:production

3. Verifiser production — sjekk Railway logs og API-respons

iOS-release (separat syklus)

1. Bump versjon og send til TestFlight

   cd apps/mobile-kmp/iosApp
   bundle exec fastlane ios bump type:patch
   # Git tag v* opprettes automatisk -> TestFlight-bygg starter

2. Test pa TestFlight — appen dukker opp etter 15-30 min

3. Promoter til App Store

   cd apps/mobile-kmp/iosApp
   bundle exec fastlane ios promote

4. Submit for review i App Store Connect (manuelt steg)

---

11. Feilsoking

Nar CI feiler

Database-sjekk feiler

Vanligste arsak: Genererte typer er utdaterte.

# Fix: Regenerer types lokalt og commit
pnpm db:types
git add packages/database/types/database.ts
git commit -m "chore: update generated database types"

API-sjekk feiler

Vanligste arsaker: TypeScript type errors, lint-feil, testfeil.

# Kjor lokalt for a reprodusere
pnpm --filter api lint
pnpm --filter api type-check
pnpm --filter api test

iOS preflight feiler

Vanligste arsaker: KMP kompileringsfeil, Xcode build-feil.

# Rask KMP-sjekk lokalt
cd apps/mobile-kmp
./gradlew :shared:compileKotlinIosSimulatorArm64

# Full preflight
cd iosApp
bundle exec fastlane ios preflight

Nar deploy feiler

Database-migrasjon feiler i staging/production

1. Sjekk loggen i GitHub Actions for a se den eksakte feilen
2. Kjor dry-run via manuell workflow: Actions -> “DB Deploy (manual)” -> velg miljo -> “dry-run”
3. Fiks migrasjonsfilen lokalt, test med pnpm db:reset
4. Commit og push — CI + staging deploy kjorer pa nytt

iOS TestFlight-upload feiler

1. Sjekk signing: Er Match-sertifikatene gyldige? Kjor fastlane ios doctor
2. Sjekk Doppler: Er ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY satt for prd?
3. Timeout? Build har 30 min timeout. Sjekk om Gradle-cache mangler.
4. Force retry: Actions -> “iOS Release (manual)” -> velg “beta”

Railway deployer ikke

Railway overvaker branchen direkte. Hvis den ikke deployer:

• Sjekk Railway dashboard for feilmeldinger
• Verifiser at Railway staging er koblet til main-branchen
• Verifiser at Railway production er koblet til production-branchen
• Sjekk at Doppler-secrets er synkronisert til Railway via integrasjonen (stg -> staging, prd -> production)

Sjekke logger

# Se siste workflow-kjoringer
gh run list --limit 10

# Se detaljer for en spesifikk kjoring
gh run view <run-id>

# Se logger for en feilet jobb
gh run view <run-id> --log-failed

Manuelle fallback-workflows

Workflow	Hva	Nar
db-deploy.yml	Manuell DB-migrasjon (dry-run eller migrate) mot staging/production	Feilretting, force-migrate, inspeksjon
ios-release.yml	Manuell iOS-build (beta/promote/release)	Force-release, promote til App Store

---

12. Nokkelfiler

Workflow-filer (GitHub Actions)

Fil	Trigger	Beskrivelse
.github/workflows/ci.yml	Push/PR til main	Hoved-CI: change detection, parallelle sjekker (DB, API, iOS, Android), CI Gate, staging deploy
.github/workflows/deploy-production.yml	Push til production branch	Production deploy: DB-migrasjoner + API deploy
.github/workflows/ios-release.yml	Manuell	Fallback for iOS: beta (force), promote (TestFlight -> App Store), full release
.github/workflows/db-deploy.yml	Manuell	Fallback for DB: dry-run eller migrate mot staging/production

Konfigurasjonsfiler

Fil	Beskrivelse
doppler.yaml	Lokal Doppler-konfig — kobler prosjektet til “im” med “dev” config
apps/mobile-kmp/iosApp/fastlane/Fastfile	All iOS build-logikk: preflight, test, beta, promote, release, bump, doctor
apps/mobile-kmp/iosApp/Gemfile	Ruby-avhengigheter for Fastlane
packages/database/supabase/	Supabase-konfig og migrasjonsfiler

GitHub Secrets (konfigurert i repo Settings)

Secret	Brukes i	Beskrivelse
DOPPLER_TOKEN_STG	CI + staging deploy	Doppler service token for staging-config
DOPPLER_TOKEN_PRD	Production deploy	Doppler service token for production-config

aside.note

Minimalt med GitHub Secrets. Fordi Doppler haandterer alle secrets, trenger du bare to tokens i GitHub. All annen konfigurasjon (API-nokler, database-passord, signing-info) lever i Doppler.

---

Sist oppdatert: Mars 2026