← Hjem

Ingen CI/CD i din AI-genererte app — hvorfor manuelle deployer vil knekke deg

Du bygde appen din med AI. Du deployer manuelt og ber til at det fungerer. Lær hvorfor dette er en oppskrift på katastrofe og hvordan du fikser det på en dag.

⏱ 4 min lesing

Hver deploy er et myntkast

Du bygde appen din med AI — Cursor, Lovable, Bolt. Den fungerer på localhost. Nå er det tid for å deploye. Du laster opp filer manuelt til en server, eller pusher til main og ber. Det finnes ingen automatiserte tester, ingen staging-miljø, ingen rollback-strategi. Noen ganger fungerer det, noen ganger knekker produksjonen og du bruker de neste tre timene på å finne ut hva som gikk galt.

Dette er ikke uflaks. Det er manglende infrastruktur. Appen din har kode — men ingen prosess for å trygt levere den koden til brukerne. Hver deploy er en manuell operasjon, og manuelle operasjoner feiler alltid til slutt.

Jo lenger du utsetter å sette opp CI/CD, desto mer tid kaster du bort på brannslukking i stedet for å bygge produktet ditt. Og hver brann koster deg brukernes tillit.

Hvorfor AI-genererte apper mangler CI/CD

AI genererer ikke infrastruktur. AI-verktøy som Cursor, Lovable og Bolt genererer applikasjonskode men aldri deployment-pipelinen. Du får en fungerende app med null DevOps. Ingen Dockerfile, ingen .github/workflows, ingen databasemigreringsskript. AI bygger bilen uten veien.

Ingen tester betyr intet sikkerhetsnett. AI-generert kode kommer nesten aldri med meningsfulle tester. Uten tester kan du ikke automatisere deployment fordi du ikke har noen måte å verifisere at en endring ikke ødelegger noe. Så du deployer blindt — og ber.

„Det fungerer på min maskin"-syndromet. AI bygger for ditt lokale miljø. Det setter aldri opp staging, miljøparitet eller produksjonsbyggeprosesser. Når du deployer manuelt, sammenligner du dev-modus med produksjonsmodus — forskjellige byggeinnstillinger, forskjellige miljøvariabler, forskjellig oppførsel.

Ingen rollback. Når en manuell deploy ødelegger produksjonen, er ditt eneste alternativ å finne ut hva som endret seg og prøve å fikse fremover. Med CI/CD ruller du tilbake på 30 sekunder.

Frykt for å deploye. Uten CI/CD begynner team å samle endringer i store pakker fordi hver deploy er risikabel. Store pakker er vanskeligere å feilsøke når noe går galt. Det skaper en ond sirkel — jo sjeldnere du deployer, jo reddere blir du, jo sjeldnere deployer du.

6 steg til trygge deployer

  1. Sett opp GitHub Actions (eller GitLab CI) — selv en minimal pipeline som kjører npm run build og deployer ved push til main er 100x bedre enn manuelle opplastinger. En YAML-fil, 20 minutters arbeid.
  2. Legg til minst smoke-tester — test at appen starter, hovedsiden laster, og API-et svarer. Dette fanger 80% av buggene som ødelegger deployer.
  3. Opprett et staging-miljø — deploy dit først, verifiser, deretter promoter til produksjon. Speil produksjonen så nøye som mulig — samme miljøvariabler, samme databaseoppsett, samme byggeprosess.
  4. Automatiser databasemigreringer — kjør aldri SQL manuelt på produksjon. Bruk et migreringsverktøy (Prisma, Knex, Doctrine) som kjører automatisk under deploy.
  5. Sett opp rollback — tagg hver deploy, hold den forrige versjonen klar. En kommando for å rulle tilbake. Når noe går galt, er du tilbake online på 30 sekunder i stedet for 3 timer.
  6. Legg til deploy-varsler — Slack- eller e-postvarsler når en deploy starter, lykkes eller feiler. Vet hva som skjer uten å stirre på terminalen.
Nøkkelprinsipp

Du trenger ikke perfekt CI/CD med en gang. Selv den enkleste pipelinen — build + deploy ved push — eliminerer 90% av problemene med manuell deployment. Start enkelt og iterer.

Les også

Manuelle deployer sakker deg ned?

Vi setter opp CI/CD, legger til tester, oppretter staging og rollback. Slutt på deployer basert på flaks.

Bestill en gratis samtale →
Gratis konsultasjon Helt uforpliktende Svar innen 24t