Git-repository til produksjon: Dockup-distribusjonsveiledning

Å flytte et Git-repository til produksjon krever mer enn å koble til en remote og trykke på deploy. Plattformen må vite hvilket target tjenesten skal bruke, hvilken branch og build-metode som skal benyttes, hvilken startkommando og lytteport som gjelder, samt miljø, health gate og gjenopprettingsplan. Dockup gjør disse valgene eksplisitte og støtter både automatiske Nixpacks-builds og Dockerfiles som vedlikeholdes i repositoryet.

Denne veiledningen starter med et repository som aldri har blitt deployet, og ender med en verifisert URL, deployment-historikk, logger og en testet rollback-kommando.

Hva bør kontrolleres før den første produksjonsdeployen?

Bekreft at repositoryet kan deployes uten udokumentert lokal tilstand. En clean clone skal inneholde alt som trengs for å installere avhengigheter og starte applikasjonen, bortsett fra secrets.

Bruk denne sjekklisten:

Kontroll	Forventet resultat
Standardbranch	Den tiltenkte produksjonsbranchen finnes
Lockfile for avhengigheter	Committet for reproduserbare installasjoner
Startprosess	Binder til den konfigurerte porten og 0.0.0.0
Health route	Returnerer suksess uten eksterne sideeffekter
Databasemigreringer	Har en eksplisitt og trygg kjøringsplan
Secrets	Lagres utenfor Git
Persistente filer	Bruker et volume, ikke containerens filsystem
Rollback	Forrige deployment kan kjøres på nytt

Installer CLI-en og autentiser:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

List eksisterende tjenester før du oppretter noe:

dockup services --json

Dette hindrer dupliserte ressurser og bekrefter riktig workspace- og target-konvensjon.

Hvordan støtter Dockup create Git-deployment?

Den vanlige kommandoen for første deploy oppretter tjenesten, deployer den, venter på resultatet og kobler den aktuelle katalogen:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Det resulterende targetet er production/api. .dockup-koblingen gjør at senere kommandoer kan finne tjenesten når de kjøres i repositoryet, men produksjonsdokumentasjon bør fortsatt registrere hele targetet.

Etter et avbrutt provisioneringsforsøk bør du liste tjenester og kontrollere det nøyaktige targetet før du kjører opprettingen på nytt:

dockup services --json

Hvis production/api allerede finnes, fortsetter du ved å lese statusen og deployment-historikken. Slik unngår du å gjøre et usikkert nettverksresultat om til en duplisert tjeneste. Oppbevar tilgangslegitimasjon til repositoryet utenfor kildekode og kommandoutdata.

Hvordan velger Dockup Nixpacks eller Dockerfile?

Hvis repositoryet inneholder en Dockerfile, bruker Dockup den. Hvis ikke, oppdager Nixpacks applikasjonen og bygger den automatisk. Denne rekkefølgen gjør repositoryets eksplisitte containerdefinisjon autoritativ.

Nixpacks er et godt førstevalg når applikasjonen følger vanlige konvensjoner i økosystemet og ikke trenger tilpasning på operativsystemnivå. En Dockerfile er nyttig når du trenger et bestemt base image, systempakker, multi-stage build, en egendefinert runtime-bruker eller nøyaktige grenser for hvilke filer som kopieres.

Du trenger ikke å legge til en tom Dockerfile bare for å «se produksjonsklar ut». En feilaktig Dockerfile kan være mindre reproduserbar enn en konvensjonell automatisk build. Bruk beslutningsprosessen i Nixpacks vs Dockerfile.

Inspiser tjenesten etter opprettingen:

dockup info production/api --json

Responsen inneholder repository-URL, branch, deployment type, port, build- og startinnstillinger, environment keys, custom domains og data om siste deployment.

Hvis de oppdagede kommandoene trenger en override, bruker du dokumenterte innstillinger:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Innstillingene gjelder ved neste deployment.

Hvordan konfigurerer du produksjonsmiljø og health?

Legg til vanlige verdier og secrets separat:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Secret-verdier maskeres når miljøet listes. De kan settes eller erstattes, men den lagrede verdien returneres ikke.

Endringer i miljøet krever en ny deployment fordi den kjørende prosessen ikke kan motta et nytt miljø retroaktivt. Hele livssyklusen er forklart i environment variables and secrets.

Konfigurer en health gate som representerer readiness:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup bruker en blue-green-flyt uten nedetid og sender først trafikk til den nye deploymenten etter at readiness er bekreftet. Når ingen HTTP-path er konfigurert, kan gaten falle tilbake til readiness på TCP-porten.

En health route bør kontrollere at applikasjonsprosessen er klar til å håndtere forespørsler. Unngå at den utfører destruktive kontroller eller kostbare tester av hele systemet. Omfattende avhengighetskontroller kan skape falske driftsavbrudd når en valgfri tjeneste er degradert.

Hvordan deployer, følger du med på og verifiserer du produksjon?

Utløs releasen og vent på en terminal status:

dockup deploy production/api --wait --json

Standard timeout er 900 sekunder. Exit 0 betyr suksess. deploy_failed og deploy_timeout gir resultater som ikke er null, slik at shell-skript og CI-systemer stopper korrekt.

Følg builden som NDJSON:

dockup logs production/api --build -f --json

Strømmen avsluttes ved suksess eller feil. Hvis builden lykkes, men containeren krasjer, inspiser runtime-logger:

dockup logs production/api --json

Etter en vellykket release verifiserer du plattformstatusen og den offentlige oppførselen:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Uptime-prober kjører hvert minutt og rapporterer gjennomsnittlig responstid og p95-responstid. Sikkerhetsskanning kontrollerer image-CVE-er og konfigurasjon. Legg til en applikasjonsspesifikk smoke test for det faktiske business-endpointet. Plattformens readiness er nødvendig, men ikke tilstrekkelig.

Den detaljerte metoden for logging er tilgjengelig i feilsøking av build- og runtime-logger.

Hvordan bør automatiske deployer og previews introduseres?

Gjør den første produksjonsreleasen manuelt, slik at du får observert hver grense i prosessen. Når build, health gate og rollback-flyt er kjent, kan du aktivere deployment ved push:

dockup auto-deploy production/api --on --json

Automatisk deployment bør følge en beskyttet branch og en policy for code review. En push utløser en produksjonsendring, så repository-tillatelser blir i praksis infrastruktur-tillatelser.

Pull request- og branch-previews gir isolerte URL-er og miljøer:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

I et prosjekt med private nettverk blir previews med i prosjektnettverket. De kan nå den samme produksjonsdatabasen på <slug>.internal, men Dockup oppretter automatisk en skrivebeskyttet databasebruker for previewet. Previewet kan lese produksjonslignende data uten å skrive til dem.

Dette eliminerer ikke personvernforpliktelser. Preview-tilgang bør fortsatt begrenses, loggføres og bare brukes når det er tillatt å lese produksjonsdata.

Hvordan ruller du tilbake en mislykket deployment?

Ta vare på bevis før du starter gjenopprettingen. Les build-logger ved en build-feil og runtime-logger ved en krasj. List deretter deployment-historikken:

dockup deployments production/api -n 20 --json

Velg en deployment-ID med kjent status og tidspunkt, og kjør den på nytt:

dockup rollback <deploymentId> production/api --json

En rollback bør være en eksplisitt handling under en hendelse. Registrer ID-en til den mislykkede deploymenten, valgt recovery-ID, årsak og oppfølgende retting. Hvis en databasemigrering ikke er bakoverkompatibel, kan ikke en rollback av applikasjonen alene nødvendigvis gjenopprette kompatibiliteten. Migreringsdesign må være en del av release-planen.

Veiledningen for deployment uten nedetid forklarer trafikkomleggingen, mens Dockup CLI-referansen dokumenterer alle kommandoflagg.

Registrering av fullført første deploy

Når arbeidsflyten for Git-repository til produksjon er fullført, bør du registrere:

• Nøyaktig project/service-target.
• Repository og produksjonsbranch.
• Build-metode: Nixpacks eller Dockerfile.
• Build- og startkommandoer når de er overstyrt.
• Lytteport og health path.
• Deployment-ID og terminal status.
• Produksjons-URL og plan for custom domain.
• Uptime- og sikkerhetsverifisering.
• Rollback-deployment-ID eller utvalgsregel.

Denne registreringen gjør den andre deploymenten til en rutineoperasjon i stedet for en ny oppdagelsesrunde.

Skill applikasjonstilstand fra container-imaget

Det skrivbare filsystemet i en service-container bør behandles som utskiftbart. En ny deployment oppretter en ny versjon, og en rollback kjører et eldre image på nytt. Filer som bare er skrevet til den gamle containeren, er derfor ikke en varig strategi for lagring av data.

Bruk administrerte databaser for relasjonell data, dokumentdata eller cache-tilstand, og koble til et volume for filer som må bevares mellom deployer. Bekreft mount-pathene før den første produksjonsreleasen. En containerisert opplastingskatalog som aldri ble mountet, kan se frisk ut helt til neste deploy sletter dataene.

Les persistente volumer og snapshots før du flytter brukergenererte filer. For databasetilstand bør du bruke det databasespesifikke backupsystemet i stedet for å behandle et varmt volume-snapshot som en transaksjonskonsistent backup.

Estimer den første måneden uten å finne på en fast instance-regning

Dockup måler CPU-, RAM- og diskforbruk per minutt og trekker bruken fra planens saldo. Free-planen inkluderer en startkreditt på $10 og opptil tre deployer. Den anbefalte Pro-planen koster $20 per måned og inkluderer $20 i brukskreditt.

Når tjenesten har reell trafikk, kan du se CPU-, RAM- og diskforbruket i app.dockup.ai. Bruk observert forbruk per minutt – ikke et anslått maksimum – når du avgjør om tjenesten, databasen eller den persistente disken trenger justeringer.

Verifiser en ren andre deployment

Etter den første releasen gjør du en ufarlig endring som er gjennomgått, og deployer på nytt. Dette bekrefter at repository-koblingen, antakelsene om build-cache, health gate, miljø og historikk fungerer som en løpende prosess, ikke bare som en vellykket engangsprovisionering.

Hold targetet eksplisitt

Registrer den endelige project/service-strengen.

Ta vare på release-URL-en

Registrer produksjons-URL-en sammen med deployment-ID-en.

Bekreft neste trigger

Registrer om fremtidige releaser er manuelle eller bruker valgfri deploy-on-push. Slik holder du repository-tillatelser, branch-beskyttelse og forventningene til produksjon samkjørte etter den første deploymenten.

Start med en deployment som kan verifiseres

Velg et lite repository med en tydelig startkommando og health route, og dokumenter det nøyaktige targetet og rollback-ID-en etter den første vellykkede releasen.

Kom i gang gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre deployer.

Vanlige spørsmål

Kan Dockup deploye et repository uten Dockerfile?

Ja. Når ingen Dockerfile finnes, bruker Dockup Nixpacks til å oppdage og bygge applikasjonen automatisk.

Hva gjør dockup create --link?

Den skriver en .dockup-kobling i den aktuelle katalogen, slik at senere kommandoer kan finne det tilknyttede project/service-targetet.

Hvorfor bør den første deployen bruke --wait?

Den holder kommandoen tilkoblet frem til deploymenten når suksess, feil eller timeout, og returnerer en exit-kode som nøyaktig gjenspeiler terminalresultatet.

Gjelder endringer i miljøvariabler umiddelbart?

Nei. De gjelder for en ny container ved neste deployment, så du må deploye tjenesten på nytt etter at miljøkonfigurasjonen er endret.

Hvordan ruller Dockup tilbake en applikasjon?

List deployment-historikken, identifiser en kjent tidligere deployment-ID, og bruk dockup rollback med denne ID-en og det nøyaktige service-targetet.