Git-repository till produktion: Dockup-distributionsguide

Att flytta ett Git-repository till produktion kräver mer än att ansluta ett remote och trycka på deploy. Plattformen måste känna till tjänstens mål, branch, build-metod, startkommando, lyssningsport, miljö, health gate och återställningsväg. Dockup gör dessa beslut explicita och stöder både automatiska Nixpacks-builds och Dockerfiles som hanteras i repositoryt.

Den här guiden börjar med ett repository som aldrig har distribuerats och avslutas med en verifierad URL, distributionshistorik, loggar och ett testat rollback-kommando.

Vad bör kontrolleras före den första produktionsdistributionen?

Bekräfta att repositoryt kan distribueras utan odokumenterat lokalt tillstånd. En ren clone ska innehålla allt som behövs för att installera beroenden och starta applikationen, med undantag för secrets.

Använd den här checklistan:

Kontroll	Förväntat resultat
Standardbranch	Den avsedda produktionsbranchen finns
Lockfil för beroenden	Incheckad för reproducerbara installationer
Startprocess	Binder till den konfigurerade porten och 0.0.0.0
Health route	Returnerar lyckat resultat utan externa sidoeffekter
Databasmigreringar	Har en explicit och säker körningsplan
Secrets	Lagras utanför Git
Beständiga filer	Använder en volume, inte containerns filsystem
Rollback	Den föregående distributionen kan köras igen

Installera CLI:t och autentisera:

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

Lista befintliga tjänster innan du skapar något:

dockup services --json

Det förhindrar duplicerade resurser och bekräftar den exakta konventionen för workspace och mål.

Hur stöder Dockup create Git-distribution?

Det vanliga kommandot för den första distributionen skapar tjänsten, distribuerar den, väntar på resultatet och länkar den aktuella katalogen:

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

Det resulterande målet är production/api. Länken .dockup gör att senare kommandon kan hitta tjänsten när de körs i repositoryt, men produktionsdokumentationen bör fortfarande ange hela målet.

Efter ett avbrutet provisioningförsök listar du tjänsterna och granskar det exakta målet innan du försöker skapa det igen:

dockup services --json

Om production/api redan finns fortsätter du genom att läsa dess status och distributionshistorik. Då förvandlas inte ett osäkert nätverksresultat till en duplicerad tjänst. Förvara inloggningsuppgifter för repositoryt utanför källkoden och kommandoutdata.

Hur väljer Dockup mellan Nixpacks och Dockerfile?

Om repositoryt innehåller en Dockerfile använder Dockup den. Annars identifierar Nixpacks applikationen och bygger den automatiskt. Den ordningen gör repositoryts explicita containerdefinition auktoritativ.

Nixpacks är ett bra förstahandsval när applikationen följer vanliga konventioner i sitt ekosystem och inte behöver anpassningar på operativsystemnivå. En Dockerfile är användbar när du behöver en specifik base image, systempaket, multi-stage build, en anpassad runtime-användare eller exakta gränser för vilka filer som kopieras.

Du behöver inte lägga till en tom Dockerfile bara för att “se produktionsklar ut”. En felaktig Dockerfile kan vara mindre reproducerbar än en konventionell automatisk build. Använd beslutsprocessen i Nixpacks vs Dockerfile.

Inspektera tjänsten efter skapandet:

dockup info production/api --json

Svaret innehåller repository-URL, branch, distributionstyp, port, build- och startinställningar, miljönycklar, custom domains och data om den senaste distributionen.

Om de identifierade kommandona behöver åsidosättas använder du dokumenterade inställningar:

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

Inställningarna börjar gälla vid nästa distribution.

Hur konfigurerar du produktionsmiljö och health?

Lägg till vanliga värden och 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ärden maskeras när miljön listas. De kan anges eller ersättas, men det lagrade värdet returneras inte.

Miljöändringar kräver en ny distribution eftersom den körande processen inte kan ta emot en ny miljö retroaktivt. Hela livscykeln förklaras i miljövariabler och secrets.

Konfigurera en health gate som representerar readiness:

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

Dockup använder ett blue-green-flöde utan driftstopp och skickar endast trafik till den nya distributionen när readiness har lyckats. När ingen HTTP-sökväg har konfigurerats kan gaten falla tillbaka på readiness för TCP-porten.

En health route bör verifiera att applikationsprocessen är redo att hantera requests. Undvik att låta den utföra destruktiva kontroller eller dyra tester av hela systemet. Djupa kontroller av beroenden kan skapa falska avbrott när en valfri tjänst är degraderad.

Hur distribuerar, bevakar och verifierar du produktion?

Starta releasen och vänta på ett slutgiltigt tillstånd:

dockup deploy production/api --wait --json

Standardtimeouten är 900 sekunder. Exit 0 betyder att körningen lyckades. deploy_failed och deploy_timeout ger resultat som inte är noll, så shellskript och CI-system stoppar korrekt.

Om du vill följa builden som NDJSON:

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

Strömmen avslutas när körningen lyckas eller misslyckas. Om builden lyckas men containern kraschar granskar du runtime-loggarna:

dockup logs production/api --json

Efter en lyckad release verifierar du plattformens status och det publika beteendet:

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

Uptime-prober körs varje minut och rapporterar genomsnittlig svarstid samt p95-svarstid. Säkerhetsskanningen kontrollerar CVE:er i image-filer och konfiguration. Lägg till ett applikationsspecifikt smoke test för den faktiska business-endpointen; plattformens readiness är nödvändig men inte tillräcklig.

Den detaljerade metoden för loggning finns i felsökning av build- och runtime-loggar.

Hur bör automatiska distributioner och previews introduceras?

Gör den första produktionsreleasen manuellt, i tillräcklig grad för att kunna observera varje gränssnitt. När builden, health gaten och rollback-vägen är kända aktiverar du distribution vid push:

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

Automatisk distribution bör följa en skyddad branch och en policy för code review. En push utlöser produktion, så repository-behörigheter blir infrastrukturbehörigheter.

Pull request- och branch-previews tillhandahåller isolerade URL:er och miljöer:

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

I ett projekt med private networking ansluter previews till projektnätverket. De kan nå samma produktionsdatabas på <slug>.internal, men Dockup skapar automatiskt en skrivskyddad databasanvändare för previewn. Previewn kan läsa produktionsliknande data utan att skriva till den.

Detta eliminerar inte skyldigheterna kring integritet. Preview-åtkomst bör fortfarande begränsas, granskas och endast användas där läsning av produktionsdata är tillåten.

Hur återställer du en felaktig distribution?

Bevara bevis innan du påbörjar återställningen. Läs build-loggar vid ett build-fel och runtime-loggar vid en krasch. Lista sedan distributionshistoriken:

dockup deployments production/api -n 20 --json

Välj ett distributions-ID vars status och tidsstämpel är kända och kör det sedan igen:

dockup rollback <deploymentId> production/api --json

En rollback bör vara en explicit incidentåtgärd. Dokumentera ID:t för den misslyckade distributionen, valt återställnings-ID, orsaken och den efterföljande korrigeringen. Om en databasmigrering inte är bakåtkompatibel kanske en rollback av applikationen inte återställer kompatibiliteten; migreringsdesignen måste vara en del av releaseplanen.

Guiden om distributioner utan driftstopp förklarar trafikväxlingen, medan Dockup CLI-referensen dokumenterar alla kommandoflaggor.

Dokumentation för slutförd första distribution

När arbetsflödet Git-repository till produktion är klart dokumenterar du:

• Exakt mål i formatet project/service.
• Repository och produktionsbranch.
• Build-metod: Nixpacks eller Dockerfile.
• Build- och startkommandon när de har åsidosatts.
• Lyssningsport och health path.
• Distributions-ID och slutgiltig status.
• Produktions-URL och plan för custom domain.
• Uptime- och säkerhetsverifiering.
• Distributions-ID för rollback eller urvalsregel.

Den här dokumentationen gör den andra distributionen till en rutinåtgärd i stället för ännu en upptäcktsövning.

Separera applikationstillstånd från container-imagen

Det skrivbara filsystemet i en service-container bör betraktas som utbytbart. En ny distribution skapar en ny version och en rollback kör en äldre image igen; filer som endast skrevs i den gamla containern är inte en hållbar datastrategi.

Använd hanterade databaser för relationsdata, dokumentdata eller cachedata och anslut en volume för filer som måste finnas kvar mellan distributioner. Bekräfta mount-sökvägarna före den första produktionsreleasen. En containeriserad uppladdningskatalog som aldrig monterades kan verka fungera tills nästa deploy tar bort datan.

Läs beständiga volymer och snapshots innan du flyttar användargenererade filer. För databastillstånd använder du det databasspecifika backupsystemet i stället för att behandla en snapshot av en aktiv volume som en transaktionskonsistent backup.

Uppskatta den första månaden utan att hitta på en fast instanskostnad

Dockup mäter CPU-, RAM- och diskanvändning per minut och drar av användningen från saldot i abonnemanget. Free-abonnemanget inkluderar en startkredit på 10 USD och upp till tre distributioner; Pro-abonnemanget kostar 20 USD per månad och inkluderar 20 USD i användningskredit.

När tjänsten har verklig trafik granskar du dess CPU-, RAM- och diskanvändning i app.dockup.ai. Använd den observerade förbrukningen per minut – inte en gissad maxnivå – när du avgör om tjänsten, databasen eller den beständiga disken behöver justeras.

Verifiera en ren andra distribution

Efter den första releasen gör du en ofarlig, granskad ändring och distribuerar igen. Det bekräftar att repository-länken, antagandena om build cache, health gaten, miljön och historiken fungerar som en löpande process i stället för som ett engångsresultat av provisioning.

Håll målet explicit

Dokumentera den slutliga strängen project/service.

Bevara release-URL:en

Dokumentera produktions-URL:en bredvid distributions-ID:t.

Bekräfta nästa trigger

Dokumentera om framtida releaser är manuella eller använder valfri deploy-on-push. Då hålls repository-behörigheter, branch-skydd och produktionsförväntningar i linje även efter den första distributionen.

Börja med en verifierbar distribution

Välj ett litet repository med ett tydligt startkommando och en health route och dokumentera det exakta målet samt rollback-ID:t efter den första lyckade releasen.

Starta kostnadsfritt på app.dockup.ai. Free-abonnemanget kostar 0 USD per månad, inkluderar 10 USD i startkredit och stöder en workspace, tre databaser och tre distributioner.

Vanliga frågor

Kan Dockup distribuera ett repository utan en Dockerfile?

Ja. När ingen Dockerfile finns använder Dockup Nixpacks för att automatiskt identifiera och bygga applikationen.

Vad gör dockup create --link?

Det skriver en .dockup-länk i den aktuella katalogen så att senare kommandon kan hitta det associerade målet i formatet project/service.

Varför bör den första distributionen använda --wait?

Det håller kommandot anslutet tills distributionen når lyckat resultat, fel eller timeout och returnerar en exit-kod som korrekt motsvarar slutresultatet.

Börjar ändringar av miljövariabler gälla omedelbart?

Nej. De börjar gälla i en ny container vid nästa distribution, så distribuera om tjänsten efter att du har ändrat miljökonfigurationen.

Hur återställer Dockup en applikation?

Lista distributionshistoriken, identifiera ett känt tidigare distributions-ID och använd dockup rollback med det ID:t och det exakta tjänstemålet.