Fra Git repository til production: Dockup-deployguide

At flytte et Git repository til production kræver mere end at forbinde et remote repository og trykke på deploy. Platformen skal kende servicens target, branch, build-metode, start-kommando, lyttende port, environment, health gate og recovery-sti. Dockup gør disse valg eksplicitte og understøtter både automatiske Nixpacks-builds og Dockerfiles, der ejes af repositoryet.

Denne guide starter med et repository, der aldrig er blevet deployed, og ender med en verificeret URL, deployment-historik, logs og en testet rollback-kommando.

Hvad skal kontrolleres før det første production-deploy?

Bekræft, at repositoryet kan deployes uden udokumenteret lokal state. Et clean clone bør indeholde alt, der kræves for at installere dependencies og starte applikationen, bortset fra secrets.

Brug denne tjekliste:

Kontrol	Forventet resultat
Default branch	Den tilsigtede production-branch findes
Dependency lockfile	Er committed for reproducerbare installs
Startproces	Binder til den konfigurerede port og 0.0.0.0
Health route	Returnerer success uden eksterne sideeffekter
Databasemigrationer	Har en eksplicit og sikker execution-plan
Secrets	Gemmes uden for Git
Persistente filer	Bruger en volume, ikke containerens filesystem
Rollback	Den tidligere deployment kan køres igen

Installér CLI'et, og log ind:

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

List eksisterende services, før du opretter noget:

dockup services --json

Det forhindrer duplicate resources og bekræfter den præcise workspace- og target-konvention.

Hvordan understøtter Dockup create Git-deployment?

Den normale kommando til den første deployment opretter servicen, deployer den, venter på resultatet og linker den aktuelle mappe:

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

Det resulterende target er production/api. Linket .dockup gør det muligt for senere kommandoer at finde servicen, når de køres i repositoryet, men production-dokumentation bør stadig registrere det fulde target.

Efter et afbrudt provisioning-forsøg skal du liste services og inspicere det præcise target, før du kører oprettelsen igen:

dockup services --json

Hvis production/api allerede findes, kan du fortsætte ved at læse dens status og deployment-historik. På den måde undgår du, at et usikkert netværksresultat bliver til en duplicate service. Opbevar credentials til repository-adgang uden for source control og command output.

Hvordan vælger Dockup Nixpacks eller Dockerfile?

Hvis repositoryet indeholder en Dockerfile, bruger Dockup den. Ellers registrerer Nixpacks applikationen og bygger den automatisk. Denne rækkefølge gør repositoryets eksplicitte containerdefinition autoritativ.

Nixpacks er et godt førstevalg, når applikationen følger almindelige ecosystem-konventioner og ikke kræver tilpasning på operativsystemniveau. En Dockerfile er nyttig, når du har brug for et bestemt base image, system packages, et multi-stage build, en tilpasset runtime-bruger eller præcise copy boundaries.

Du behøver ikke tilføje en tom Dockerfile bare for at “se production-klar ud”. En forkert Dockerfile kan være mindre reproducerbar end et konventionelt automatisk build. Brug beslutningsprocessen i Nixpacks vs Dockerfile.

Inspicér servicen efter oprettelsen:

dockup info production/api --json

Responsen indeholder repository-URL, branch, deployment-type, port, build- og startindstillinger, environment keys, custom domains og data om den seneste deployment.

Hvis de registrerede kommandoer kræver en override, kan du bruge de dokumenterede indstillinger:

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

Indstillingerne træder i kraft ved den næste deployment.

Hvordan konfigurerer du production-environment og health?

Tilføj almindelige værdier 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-værdier maskeres, når environment listes. De kan angives eller erstattes, men den gemte værdi returneres ikke.

Ændringer i environment kræver en ny deployment, fordi den kørende proces ikke kan modtage et nyt environment retroaktivt. Hele livscyklussen er forklaret i environment variables and secrets.

Konfigurér en health gate, der repræsenterer readiness:

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

Dockup bruger et blue-green-flow uden downtime og sender først trafik til den nye deployment, når readiness er opnået. Når der ikke er konfigureret en HTTP-sti, kan gaten falde tilbage til readiness på TCP-porten.

En health route bør kontrollere, at applikationsprocessen er klar til at håndtere requests. Undgå at lade den udføre destruktive checks eller dyre fulde systemtests. Dybe dependency-checks kan skabe falske outages, når en valgfri service er degraded.

Hvordan deployer, overvåger og verificerer du production?

Udløs releasen, og vent på en terminal state:

dockup deploy production/api --wait --json

Standard-timeout er 900 sekunder. Exit 0 betyder success. deploy_failed og deploy_timeout giver resultater, der ikke er nul, så shell-scripts og CI-systemer stopper korrekt.

Hvis du vil overvåge buildet som NDJSON:

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

Streamen slutter ved success eller failure. Hvis buildet lykkes, men containeren crasher, skal du inspicere runtime logs:

dockup logs production/api --json

Efter en vellykket release skal du verificere platformens state og den offentlige funktion:

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

Uptime-probes kører hvert minut og rapporterer gennemsnitlig responstid og p95-responstid. Security scanning kontrollerer image-CVE'er og konfiguration. Tilføj en applikationsspecifik smoke test for det faktiske business-endpoint; platformens readiness er nødvendig, men ikke tilstrækkelig.

Den detaljerede logmetode findes i build- og runtime-logdebugging.

Hvordan bør automatiske deploys og previews introduceres?

Gennemfør den første production-release manuelt i tilstrækkelig grad til at observere hver boundary. Når build, health gate og rollback-sti er kendt, kan du aktivere deployment ved push:

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

Automatisk deployment bør følge en protected branch og en code-review-politik. Et push er en production-trigger, så repository permissions bliver til infrastructure permissions.

Pull request- og branch-previews giver isolerede URL'er og environments:

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

I et private-networking-project tilsluttes previews projektnetværket. De kan tilgå den samme production-database på <slug>.internal, men Dockup opretter automatisk en read-only databasebruger til previewet. Previewet kan inspicere data, der ligner production-data, uden at skrive til dem.

Det fjerner ikke kravene til privacy. Preview-adgang bør stadig begrænses, auditeres og kun bruges, hvor det er tilladt at læse production-data.

Hvordan ruller du en dårlig deployment tilbage?

Bevar evidens, før du starter recovery. Læs build logs ved en build-fejl og runtime logs ved et crash. List derefter deployment-historikken:

dockup deployments production/api -n 20 --json

Vælg et deployment-ID med kendt status og timestamp, og kør det igen:

dockup rollback <deploymentId> production/api --json

En rollback bør være en eksplicit incident-handling. Registrér det fejlede deployment-ID, det valgte recovery-ID, årsagen og den efterfølgende løsning. Hvis en databasemigration ikke er backward compatible, genskaber en application rollback alene muligvis ikke kompatibiliteten; migrationsdesign skal være en del af release-planen.

Guiden til deployment uden downtime forklarer trafikskiftet, mens Dockup CLI-reference dokumenterer alle kommando-flags.

Registrering af gennemført første deployment

Ved afslutningen af workflowet fra Git repository til production skal du registrere:

• Det præcise project/service-target.
• Repository og production-branch.
• Build-metode: Nixpacks eller Dockerfile.
• Build- og start-kommandoer, når de er overridet.
• Lyttende port og health path.
• Deployment-ID og terminal status.
• Production-URL og plan for custom domain.
• Uptime- og security-verifikation.
• Rollback-deployment-ID eller udvælgelsesregel.

Denne registrering gør den anden deployment til en rutinehandling i stedet for endnu en discovery-øvelse.

Adskil application state fra container image

Det writable filesystem inde i en service-container bør betragtes som udskifteligt. En ny deployment opretter en ny version, og en rollback kører et ældre image igen; filer, der kun er skrevet inde i den gamle container, er ikke en holdbar datastrategi.

Brug managed databases til relationel state, dokument-state eller cache-state, og mount en volume til filer, der skal bevares på tværs af deployments. Bekræft mount paths før den første production-release. En containeriseret upload-mappe, der aldrig blev mountet, kan se sund ud, indtil den næste deployment fjerner dataene.

Læs persistente volumes og snapshots, før du flytter brugergenererede filer. Til database-state skal du bruge det databasespecifikke backup-system i stedet for at betragte et hot volume-snapshot som en transaktionskonsistent backup.

Estimér den første måned uden at opfinde en fast instance-regning

Dockup måler CPU-, RAM- og diskforbrug pr. minut og trækker forbruget fra planens saldo. Free-planen inkluderer $10 i startkredit og op til tre deployments; den anbefalede Pro-plan koster $20 om måneden og inkluderer $20 i usage credit.

Når servicen har reel trafik, skal du gennemgå dens CPU-, RAM- og diskforbrug på app.dockup.ai. Brug det observerede forbrug pr. minut — ikke et gættet maksimum — til at afgøre, om servicen, databasen eller den persistente disk skal justeres.

Verificér en ren anden deployment

Efter den første release skal du lave en ufarlig, reviewed ændring og deploye igen. Det bekræfter, at repository-linket, antagelser om build-cache, health gate, environment og historik fungerer som en løbende proces i stedet for blot som en vellykket engangsprovisionering.

Hold target eksplicit

Registrér den endelige project/service-streng.

Bevar release-URL'en

Registrér production-URL'en sammen med deployment-ID'et.

Bekræft den næste trigger

Registrér, om fremtidige releases er manuelle eller bruger valgfri deploy-on-push. Det holder repository permissions, branch protection og production-forventninger på linje efter den første deployment.

Start med en verificerbar deployment

Vælg et lille repository med en tydelig start-kommando og health route, og dokumentér det præcise target og rollback-ID efter den første vellykkede release.

Start gratis på app.dockup.ai. Free-planen koster $0 om måneden, inkluderer $10 i startkredit og understøtter én workspace, tre databaser og tre deployments.

FAQ

Kan Dockup deploye et repository uden en Dockerfile?

Ja. Når der ikke findes en Dockerfile, bruger Dockup Nixpacks til automatisk at registrere og bygge applikationen.

Hvad gør dockup create --link?

Den skriver et .dockup-link i den aktuelle mappe, så senere kommandoer kan finde det tilknyttede project/service-target.

Hvorfor bør den første deployment bruge --wait?

Det holder kommandoen tilknyttet, indtil deploymenten når success, failure eller timeout, og returnerer en exit-kode, der præcist repræsenterer det endelige resultat.

Træder ændringer i environment variables i kraft med det samme?

Nej. De anvendes på en ny container ved den næste deployment, så servicen skal deployes igen, efter at environment-konfigurationen er ændret.

Hvordan ruller Dockup en applikation tilbage?

List deployment-historikken, identificér et kendt tidligere deployment-ID, og brug dockup rollback med dette ID og det præcise service-target.