De la repository Git la producție: ghidul de deployment Dockup

Mutarea unui repository Git în producție presupune mai mult decât conectarea unui remote și apăsarea butonului de deploy. Platforma trebuie să cunoască serviciul țintă, branch-ul, metoda de build, comanda de pornire, portul de ascultare, mediul de execuție, criteriul de health și metoda de recuperare. Dockup face explicite aceste decizii și acceptă atât build-uri automate Nixpacks, cât și Dockerfile-uri gestionate în repository.

Acest ghid pornește de la un repository care nu a fost niciodată folosit pentru deployment și se încheie cu un URL verificat, istoricul deployment-urilor, loguri și o comandă de rollback testată.

Ce trebuie verificat înainte de primul deployment în producție?

Confirmă că repository-ul poate fi folosit pentru deployment fără stare locală nedocumentată. Un clone curat ar trebui să conțină tot ce este necesar pentru instalarea dependențelor și pornirea aplicației, cu excepția secretelor.

Folosește această listă de verificare:

Verificare	Rezultat așteptat
Branch implicit	Branch-ul destinat producției există
Lockfile pentru dependențe	Este inclus în repository pentru instalări reproductibile
Procesul de pornire	Se leagă la portul configurat și la 0.0.0.0
Rută de health	Returnează succes fără efecte secundare externe
Migrații de bază de date	Au un plan explicit și sigur de execuție
Secrete	Sunt stocate în afara Git
Fișiere persistente	Folosesc un volum, nu filesystem-ul containerului
Rollback	Deployment-ul anterior poate fi rulat din nou

Instalează CLI-ul și autentifică-te:

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

Listează serviciile existente înainte de a crea ceva:

dockup services --json

Astfel eviți resursele duplicate și confirmi convenția exactă pentru workspace și țintă.

Cum permite Dockup create efectuarea unui deployment din Git?

Comanda obișnuită pentru primul deployment creează serviciul, efectuează deployment-ul, așteaptă rezultatul și leagă directorul curent:

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

Ținta rezultată este production/api. Linkul .dockup permite comenzilor ulterioare să identifice serviciul atunci când sunt rulate din repository, însă documentația pentru producție ar trebui să păstreze în continuare ținta completă.

După o încercare de provisioning întreruptă, listează serviciile și inspectează ținta exactă înainte de a rula din nou comanda de creare:

dockup services --json

Dacă production/api există deja, continuă citind statusul și istoricul deployment-urilor. Astfel eviți transformarea unui rezultat de rețea incert într-un serviciu duplicat. Păstrează credentialele pentru accesul la repository în afara source control-ului și a outputului comenzilor.

Cum alege Dockup între Nixpacks și Dockerfile?

Dacă repository-ul conține un Dockerfile, Dockup îl folosește. În caz contrar, Nixpacks detectează aplicația și o construiește automat. Această ordine face ca definiția explicită a containerului din repository să aibă prioritate.

Nixpacks este o alegere bună pentru început atunci când aplicația urmează convențiile uzuale ale ecosistemului și nu are nevoie de personalizări la nivelul sistemului de operare. Un Dockerfile este util atunci când ai nevoie de o imagine de bază specifică, pachete de sistem, un build multi-stage, un utilizator runtime personalizat sau limite exacte pentru operațiunile de copiere.

Nu este necesar să adaugi un Dockerfile gol doar pentru a „arăta pregătit pentru producție”. Un Dockerfile incorect poate fi mai puțin reproductibil decât un build automat convențional. Folosește procesul de decizie din Nixpacks vs Dockerfile.

Inspectează serviciul după creare:

dockup info production/api --json

Răspunsul include URL-ul repository-ului, branch-ul, tipul de deployment, portul, setările de build și pornire, cheile de environment, domeniile custom și datele despre cel mai recent deployment.

Dacă comenzile detectate au nevoie de un override, folosește setările documentate:

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

Setările se aplică la următorul deployment.

Cum configurezi mediul de producție și health?

Adaugă separat valorile obișnuite și secretele:

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

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

Valorile secrete sunt mascate atunci când este listat mediul. Ele pot fi setate sau înlocuite, însă valoarea stocată nu este returnată.

Modificările de environment necesită un redeploy, deoarece procesul aflat în execuție nu poate primi retroactiv un environment nou. Întregul ciclu de viață este explicat în variabile de environment și secrete.

Configurează un health gate care să reprezinte readiness-ul:

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

Dockup folosește un flux blue-green fără downtime și trimite trafic către noul deployment numai după ce readiness-ul este confirmat. Dacă nu este configurată nicio rută HTTP, criteriul poate reveni la readiness-ul portului TCP.

O rută de health ar trebui să verifice dacă procesul aplicației este pregătit să răspundă la request-uri. Evită să efectueze verificări distructive sau teste complete și costisitoare ale sistemului. Verificările aprofundate ale dependențelor pot crea outage-uri false atunci când un serviciu opțional este degradat.

Cum faci deployment, urmărești și verifici producția?

Declanșează release-ul și așteaptă o stare finală:

dockup deploy production/api --wait --json

Timeout-ul implicit este de 900 de secunde. Codul de ieșire 0 înseamnă succes. Rezultatele deploy_failed și deploy_timeout sunt non-zero, astfel încât scripturile shell și sistemele CI se opresc corect.

Pentru a urmări build-ul ca NDJSON:

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

Fluxul se încheie la succes sau la eșec. Dacă build-ul reușește, dar containerul se închide, inspectează logurile runtime:

dockup logs production/api --json

După un release reușit, verifică starea platformei și comportamentul public:

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

Probele de uptime rulează o dată pe minut și raportează timpul mediu de răspuns și p95. Scanarea de securitate verifică CVE-urile imaginii și configurația. Adaugă un smoke test specific aplicației pentru endpoint-ul relevant pentru business; readiness-ul platformei este necesar, dar nu suficient.

Metoda detaliată de analizare a logurilor este disponibilă în debugging pentru build și logurile runtime.

Cum trebuie introduse deployment-urile automate și preview-urile?

Efectuează primul release în producție manual, astfel încât să poți observa fiecare etapă. După ce build-ul, health gate-ul și metoda de rollback sunt clare, activează deployment-ul la push:

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

Deployment-ul automat ar trebui să urmeze un branch protejat și o politică de code review. Un push este un trigger de producție, astfel încât permisiunile repository-ului devin permisiuni de infrastructură.

Preview-urile pentru pull request-uri și branch-uri oferă URL-uri și medii izolate:

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

Într-un proiect cu private networking, preview-urile se alătură rețelei proiectului. Ele pot accesa aceeași bază de date de producție la <slug>.internal, însă Dockup creează automat pentru preview un utilizator de bază de date read-only. Preview-ul poate inspecta date cu aceeași structură ca cele de producție, fără să le modifice.

Acest lucru nu elimină obligațiile privind confidențialitatea. Accesul preview-urilor trebuie în continuare limitat și auditat și trebuie folosit numai acolo unde citirea datelor de producție este permisă.

Cum revii la o versiune anterioară după un deployment problematic?

Păstrează dovezile înainte de recuperare. Citește build logurile pentru un build eșuat și runtime logurile pentru un crash. Apoi listează istoricul deployment-urilor:

dockup deployments production/api -n 20 --json

Selectează un deployment ID al cărui status și timestamp sunt cunoscute, apoi rulează-l din nou:

dockup rollback <deploymentId> production/api --json

Un rollback ar trebui să fie o acțiune explicită de incident response. Notează deployment ID-ul eșuat, recovery ID-ul selectat, motivul și remedierea ulterioară. Dacă o migrare de bază de date nu este backward compatible, simplul rollback al aplicației poate să nu refacă compatibilitatea; proiectarea migrației trebuie să facă parte din planul de release.

Ghidul despre deployment fără downtime explică schimbarea traficului, iar referința CLI Dockup documentează toate opțiunile comenzilor.

Înregistrarea finalizării primului deployment

La finalul fluxului de la repository Git la producție, notează:

• Ținta exactă project/service.
• Repository-ul și branch-ul de producție.
• Metoda de build: Nixpacks sau Dockerfile.
• Comenzile de build și pornire, dacă au fost suprascrise.
• Portul de ascultare și ruta de health.
• Deployment ID-ul și statusul final.
• URL-ul de producție și planul pentru domeniul custom.
• Verificarea uptime-ului și a securității.
• Deployment ID-ul pentru rollback sau regula de selecție.

Această înregistrare transformă al doilea deployment într-o operațiune de rutină, nu într-un nou exercițiu de descoperire.

Separă starea aplicației de imaginea containerului

Filesystem-ul writable din interiorul unui container de serviciu trebuie tratat ca înlocuibil. Un deployment nou creează o versiune nouă, iar un rollback rulează din nou o imagine mai veche; fișierele scrise doar în containerul vechi nu reprezintă o strategie durabilă pentru date.

Folosește baze de date managed pentru starea relațională, document sau de cache și atașează un volum pentru fișierele care trebuie să persiste între deployment-uri. Confirmă căile de mount înainte de primul release în producție. Un director de upload-uri dintr-un container care nu a fost niciodată montat poate părea sănătos până la următorul deploy, când datele sunt șterse.

Consultă volume persistente și snapshot-uri înainte de a muta fișiere generate de utilizatori. Pentru starea bazei de date, folosește sistemul de backup specific bazei de date, nu trata un snapshot hot al volumului ca pe un backup consistent la nivel de tranzacție.

Estimează prima lună fără să inventezi o factură fixă pentru instanță

Dockup măsoară consumul de CPU, RAM și disk în fiecare minut și scade utilizarea din soldul planului. Planul Free include un credit inițial de 10 $ și până la trei deployment-uri; planul Pro recomandat costă 20 $ pe lună și include un credit de utilizare de 20 $.

După ce serviciul primește trafic real, verifică utilizarea CPU, RAM și disk în app.dockup.ai. Folosește consumul observat pe minut — nu un maximum presupus — pentru a decide dacă serviciul, baza de date sau disk-ul persistent necesită ajustări.

Verifică un al doilea deployment curat

După primul release, fă o modificare inofensivă, verificată prin review, și efectuează din nou deployment-ul. Astfel confirmi că linkul repository-ului, presupunerile privind build cache-ul, health gate-ul, environment-ul și istoricul funcționează ca proces continuu, nu doar ca succes unic de provisioning.

Păstrează ținta explicită

Notează stringul final project/service.

Păstrează URL-ul release-ului

Notează URL-ul de producție alături de deployment ID.

Confirmă următorul trigger

Notează dacă release-urile viitoare sunt manuale sau folosesc opțional deploy-on-push. Astfel păstrezi aliniate permisiunile repository-ului, protecția branch-urilor și așteptările pentru producție după primul deployment.

Începe cu un deployment verificabil

Alege un repository mic, cu o comandă de pornire și o rută de health clare, apoi documentează ținta exactă și rollback ID-ul după primul release reușit.

Începe gratuit pe app.dockup.ai. Planul Free costă 0 $ pe lună, include un credit inițial de 10 $ și permite un workspace, trei baze de date și trei deployment-uri.

Întrebări frecvente

Poate Dockup să facă deployment pentru un repository fără Dockerfile?

Da. Când nu există un Dockerfile, Dockup folosește Nixpacks pentru a detecta și construi automat aplicația.

Ce face dockup create --link?

Scrie un link .dockup în directorul curent, astfel încât comenzile ulterioare să poată identifica ținta asociată în format project/service.

De ce ar trebui ca primul deploy să folosească --wait?

Menține comanda conectată până când deployment-ul ajunge la succes, eșec sau timeout și returnează un cod de ieșire care reprezintă corect rezultatul final.

Modificările variabilelor de environment se aplică imediat?

Nu. Ele se aplică unui container nou la următorul deployment, așa că trebuie să faci redeploy serviciului după modificarea configurației de environment.

Cum face Dockup rollback pentru o aplicație?

Listează istoricul deployment-urilor, identifică un deployment ID anterior cunoscut și folosește dockup rollback cu acel ID și ținta exactă a serviciului.