Od Git repozitorija do produkcije: Dockup vodič za deployment

Prebacivanje Git repozitorija u produkciju zahtijeva više od povezivanja remote repozitorija i pritiska na deploy. Platforma mora znati ciljni servis, branch, način buildanja, startnu naredbu, port na kojem aplikacija sluša, environment, health gate i postupak oporavka. Dockup te odluke čini eksplicitnima, uz podršku za automatske Nixpacks buildove i Dockerfileove kojima upravlja sam repozitorij.

Ovaj vodič počinje repozitorijem koji nikad nije bio deployan, a završava provjerenim URL-om, poviješću deploymenta, logovima i testiranom naredbom za rollback.

Što treba provjeriti prije prvog production deploya?

Provjerite može li se repozitorij deployati bez nedokumentiranog lokalnog stanja. Čisti clone treba sadržavati sve što je potrebno za instalaciju dependencija i pokretanje aplikacije, osim secreta.

Upotrijebite ovaj checklist:

Provjera	Očekivani rezultat
Zadani branch	Postoji predviđeni production branch
Lockfile dependencija	Commitan je radi reproducibilne instalacije
Startni proces	Sluša na konfiguriranom portu i adresi 0.0.0.0
Health ruta	Vraća uspješan rezultat bez vanjskih nuspojava
Database migrations	Imaju izričit i siguran plan izvršavanja
Secreti	Pohranjeni su izvan Git repozitorija
Persistentne datoteke	Koriste volume, a ne filesystem containera
Rollback	Prethodni deployment može se ponovno pokrenuti

Instalirajte CLI i autentificirajte se:

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

Prije izrade bilo čega izlistajte postojeće servise:

dockup services --json

Time sprječavate stvaranje dupliciranih resursa i potvrđujete točan workspace i konvenciju za target.

Kako Dockup create podržava Git deployment?

Uobičajena naredba za prvi deploy izrađuje servis, deploya ga, čeka rezultat i povezuje trenutačni direktorij:

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

Dobiveni target je production/api. .dockup link omogućuje kasnijim naredbama da pronađu taj servis kada se pokreću unutar repozitorija, no produkcijska dokumentacija i dalje treba navesti puni target.

Nakon prekinutog pokušaja provisioninga izlistajte servise i provjerite točan target prije ponovnog pokretanja izrade:

dockup services --json

Ako production/api već postoji, nastavite tako da pročitate njegov status i povijest deploymenta. Time neizvjestan mrežni rezultat ne pretvarate u duplicirani servis. Akreditacijske podatke za pristup repozitoriju držite izvan source controla i izlaza naredbi.

Kako Dockup odabire Nixpacks ili Dockerfile?

Ako repozitorij sadrži Dockerfile, Dockup ga koristi. U suprotnom Nixpacks automatski detektira aplikaciju i builda je. Takav redoslijed čini eksplicitnu definiciju containera u repozitoriju mjerodavnom.

Nixpacks je dobar prvi izbor kada aplikacija slijedi uobičajene konvencije ekosustava i ne treba prilagodbu na razini operacijskog sustava. Dockerfile je koristan kada trebate određeni base image, system packages, multi-stage build, prilagođenog runtime korisnika ili precizne granice za kopiranje datoteka.

Ne morate dodavati prazan Dockerfile samo da biste „izgledali spremno za produkciju”. Neispravan Dockerfile može biti manje reproducibilan od konvencionalnog automatskog builda. Upotrijebite postupak odlučivanja u članku Nixpacks u odnosu na Dockerfile.

Pregledajte servis nakon izrade:

dockup info production/api --json

Odgovor uključuje URL repozitorija, branch, deployment type, port, postavke za build i start, ključeve environmenta, custom domene i podatke o najnovijem deploymentu.

Ako detektirane naredbe trebaju override, upotrijebite dokumentirane postavke:

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

Postavke se primjenjuju pri sljedećem deploymentu.

Kako konfigurirati production environment i health?

Dodajte obične vrijednosti i secrete odvojeno:

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

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

Secret vrijednosti maskiraju se pri ispisu environmenta. Mogu se postaviti ili zamijeniti, ali pohranjena se vrijednost ne vraća.

Promjene environmenta zahtijevaju redeploy jer pokrenuti proces retroaktivno ne može primiti novi environment. Cijeli životni ciklus objašnjen je u članku environment varijable i secreti.

Konfigurirajte health gate koji predstavlja spremnost servisa:

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

Dockup koristi blue-green flow bez prekida rada i promet šalje na novi deployment tek nakon uspješne provjere spremnosti. Kada nije konfigurirana HTTP putanja, gate se može osloniti na spremnost TCP porta.

Health ruta treba provjeravati je li proces aplikacije spreman za obradu zahtjeva. Izbjegavajte da izvršava destruktivne provjere ili skupe testove cijelog sustava. Dubinske provjere dependencija mogu stvoriti lažne prekide rada kada je neka opcionalna usluga degradirana.

Kako deployati, pratiti i provjeriti produkciju?

Pokrenite release i čekajte terminalno stanje:

dockup deploy production/api --wait --json

Zadani timeout iznosi 900 sekundi. Izlaz 0 znači uspjeh. Rezultati deploy_failed i deploy_timeout vraćaju vrijednosti različite od nule, pa se shell skripte i CI sustavi ispravno zaustavljaju.

Za praćenje builda u obliku NDJSON-a:

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

Stream završava nakon uspjeha ili neuspjeha. Ako build uspije, ali se container sruši, pregledajte runtime logove:

dockup logs production/api --json

Nakon uspješnog releasea provjerite stanje platforme i javno ponašanje servisa:

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

Uptime probeovi pokreću se svake minute i prijavljuju prosječno i p95 vrijeme odziva. Security scanning provjerava CVE-ove imagea i konfiguraciju. Dodajte smoke test specifičan za aplikaciju i stvarni business endpoint; spremnost platforme nužna je, ali nije dovoljna.

Detaljna metoda za rad s logovima dostupna je u članku debugging build i runtime logova.

Kako uvesti automatske deploymente i previewe?

Prvi production release izvedite dovoljno ručno da možete promatrati svaku granicu procesa. Kada su build, health gate i postupak rollbacka poznati, uključite deployment na push:

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

Automatski deployment treba pratiti zaštićeni branch i pravila code reviewa. Push je production trigger, pa dozvole za repozitorij postaju infrastrukturne dozvole.

Pull request i branch previewi pružaju izolirane URL-ove i environmente:

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

U projektu s privatnim networkingom previewi se pridružuju project networku. Mogu pristupiti istoj production bazi pod adresom <slug>.internal, ali Dockup za preview automatski izrađuje read-only database usera. Preview može pregledavati podatke oblikovane kao production podaci, ali ih ne može mijenjati.

To ne uklanja obveze povezane s privatnošću. Pristup previewu i dalje treba biti ograničen i auditiran te se koristiti samo kada je čitanje production podataka dopušteno.

Kako vratiti neispravan deployment?

Prije oporavka sačuvajte dokaze. Za build failure pročitajte build logove, a za crash runtime logove. Zatim izlistajte povijest deploymenta:

dockup deployments production/api -n 20 --json

Odaberite deployment ID čiji su status i vrijeme poznati, a zatim ga ponovno pokrenite:

dockup rollback <deploymentId> production/api --json

Rollback treba biti izričita incidentna radnja. Zabilježite ID neuspjelog deploymenta, odabrani recovery ID, razlog i naknadni popravak. Ako database migration nije backward compatible, sam rollback aplikacije možda neće vratiti kompatibilnost; dizajn migracije mora biti dio plana releasea.

Vodič za deployment bez prekida rada objašnjava preusmjeravanje prometa, a Dockup CLI referenca dokumentira sve zastavice naredbi.

Zapis o dovršetku prvog deploymenta

Na kraju tijeka od Git repozitorija do produkcije zabilježite:

• Točan target project/service.
• Repozitorij i production branch.
• Način buildanja: Nixpacks ili Dockerfile.
• Build i start naredbe ako su promijenjene.
• Port na kojem servis sluša i health putanju.
• Deployment ID i terminalni status.
• Production URL i plan za custom domenu.
• Uptime i security provjeru.
• Rollback deployment ID ili pravilo odabira.

Ovaj zapis pretvara drugi deployment u rutinsku operaciju, a ne u još jedno istraživanje.

Odvojite stanje aplikacije od container imagea

Writable filesystem unutar containera servisa treba smatrati zamjenjivim. Novi deployment izrađuje novu verziju, a rollback ponovno pokreće stariji image; datoteke zapisane samo unutar starog containera nisu trajna strategija za podatke.

Za relacijsko, dokumentno ili cache stanje koristite managed baze podataka, a za datoteke koje moraju preživjeti deploymente priključite volume. Prije prvog production releasea potvrdite mount putanje. Directory za upload unutar containera koji nikad nije bio mountan može izgledati ispravno sve dok sljedeći deploy ne ukloni podatke.

Prije premještanja datoteka koje su generirali korisnici pročitajte članak persistentni volumei i snapshoti. Za stanje baze podataka koristite backup sustav specifičan za tu bazu, umjesto da snapshot hot volumea tretirate kao transakcijski konzistentan backup.

Procijenite prvi mjesec bez izmišljanja fiksnog računa za instance

Dockup svake minute mjeri potrošnju CPU-a, RAM-a i diska te potrošnju oduzima od salda plana. Free plan uključuje početni kredit od 10 USD i do tri deploymenta; preporučeni Pro plan stoji 20 USD mjesečno i uključuje kredit za potrošnju od 20 USD.

Nakon što servis počne primati stvarni promet, pregledajte njegovu potrošnju CPU-a, RAM-a i diska u app.dockup.ai. Na temelju izmjerene potrošnje po minuti — a ne pretpostavljenog maksimuma — odlučite treba li prilagoditi servis, bazu podataka ili persistentni disk.

Provjerite čist drugi deployment

Nakon prvog releasea napravite bezopasnu promjenu koju je prošao review i ponovno deployajte. Time potvrđujete da link na repozitorij, pretpostavke o build cacheu, health gate, environment i povijest rade kao kontinuirani proces, a ne samo kao jednokratni uspjeh provisioninga.

Neka target uvijek bude eksplicitan

Zabilježite konačni string project/service.

Sačuvajte release URL

Zabilježite production URL uz deployment ID.

Potvrdite sljedeći trigger

Zabilježite hoće li budući releaseovi biti ručni ili će koristiti opcionalni deploy-on-push. Time nakon prvog deploymenta usklađujete dozvole repozitorija, zaštitu brancha i production očekivanja.

Započnite deploymentom koji se može provjeriti

Odaberite mali repozitorij s jasnom startnom naredbom i health rutom, a nakon prvog uspješnog releasea dokumentirajte točan target i rollback ID.

Započnite besplatno na app.dockup.ai. Free plan iznosi 0 USD mjesečno, uključuje početni kredit od 10 USD i podržava jedan workspace, tri baze podataka i tri deploymenta.

Česta pitanja

Može li Dockup deployati repozitorij bez Dockerfilea?

Da. Kada Dockerfile nije prisutan, Dockup koristi Nixpacks za automatsku detekciju i buildanje aplikacije.

Što radi dockup create --link?

U trenutačni direktorij zapisuje .dockup link kako bi kasnije naredbe mogle pronaći povezani project/service target.

Zašto prvi deploy treba koristiti --wait?

Naredba ostaje povezana sve dok deployment ne dosegne stanje uspjeha, neuspjeha ili timeouts te vraća exit code koji točno predstavlja konačni rezultat.

Primjenjuju li se promjene environment varijabli odmah?

Ne. Primjenjuju se na novi container pri sljedećem deploymentu, zato nakon promjene environment konfiguracije ponovno deployajte servis.

Kako Dockup vraća prethodnu verziju aplikacije?

Izlistajte povijest deploymenta, identificirajte poznati prethodni deployment ID i upotrijebite dockup rollback s tim ID-jem i točnim targetom servisa.