От Git repository до production: ръководство за deployment с Dockup

Преминаването от Git repository до production изисква повече от свързване на remote и натискане на deploy. Платформата трябва да знае целевия service, branch, метода за build, start командата, listening port, environment, health gate и пътя за възстановяване. Dockup прави тези решения явни, като поддържа както автоматични Nixpacks builds, така и Dockerfile, управляван от repository.

Това ръководство започва с repository, който никога не е бил deploy-ван, и завършва с проверен URL, deployment history, logs и тествана rollback команда.

Какво трябва да се провери преди първия production deploy?

Уверете се, че repository-то може да бъде deploy-нато без недокументирано локално състояние. Един чист clone трябва да съдържа всичко необходимо за инсталиране на dependencies и стартиране на application-а, с изключение на secrets.

Използвайте този checklist:

Проверка	Очакван резултат
Default branch	Съществува branch-ът, предназначен за production
Dependency lockfile	Commit-нат е за възпроизводими инсталации
Start process	Слуша на конфигурирания port и 0.0.0.0
Health route	Връща success без външни странични ефекти
Database migrations	Имат изричен и безопасен план за изпълнение
Secrets	Съхраняват се извън Git
Persistent files	Използват volume, а не файловата система на container-а
Rollback	Предишният deployment може да бъде изпълнен отново

Инсталирайте CLI и се удостоверете:

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

Изведете съществуващите services, преди да създадете нов:

dockup services --json

Това предотвратява създаването на дублирани resources и потвърждава точната convention за workspace и target.

Как Dockup create поддържа Git deployment?

Обичайната команда за първи deploy създава service-а, deploy-ва го, изчаква резултата и свързва текущата директория:

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

Полученият target е production/api. Връзката .dockup позволява на следващите команди да откриват service-а, когато се изпълняват в repository-то, но production документацията все пак трябва да записва пълния target.

След прекъснат опит за provisioning изведете services и проверете точния target, преди да стартирате създаването отново:

dockup services --json

Ако production/api вече съществува, продължете, като прочетете неговия status и deployment history. Така избягвате превръщането на несигурен network резултат в дублиран service. Съхранявайте credentials за достъп до repository извън source control и output-а на командите.

Как Dockup избира Nixpacks или Dockerfile?

Ако repository-то съдържа Dockerfile, Dockup го използва. В противен случай Nixpacks открива application-а и го build-ва автоматично. Този ред на избор прави изричната container дефиниция в repository-то водеща.

Nixpacks е добър първи избор, когато application-ът следва обичайните conventions на ecosystem-а и не се нуждае от customization на ниво операционна система. Dockerfile е полезен, когато са ви нужни конкретен base image, system packages, multi-stage build, custom runtime user или точни граници на копиране.

Не е необходимо да добавяте празен Dockerfile само за да изглежда проектът „готов за production“. Неправилен Dockerfile може да бъде по-малко възпроизводим от conventional automatic build. Използвайте процеса за избор в Nixpacks vs Dockerfile.

Проверете service-а след създаването му:

dockup info production/api --json

Отговорът включва repository URL, branch, deployment type, port, build и start settings, environment keys, custom domains и данни за последния deployment.

Ако откритите команди изискват override, използвайте документирани settings:

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

Settings влизат в сила при следващия deployment.

Как се конфигурират production environment и health?

Добавяйте обикновените стойности и secrets отделно:

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

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

Secret стойностите се маскират при извеждане на environment-а. Те могат да бъдат задавани или заменяни, но съхранената стойност не се връща.

Промените в environment-а изискват redeploy, защото работещият process не може да получи нов environment със задна дата. Пълният lifecycle е обяснен в environment variables and secrets.

Конфигурирайте health gate, който представя готовността на application-а:

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

Dockup използва blue-green flow без downtime и започва да изпраща traffic към новия deployment едва след успешно преминаване на readiness проверката. Когато не е конфигуриран HTTP path, gate-ът може да използва readiness на TCP port.

Health route трябва да проверява дали application process-ът е готов да обслужва requests. Избягвайте да го карате да изпълнява destructive checks или скъпи тестове на цялата система. Задълбочените проверки на dependencies могат да създадат false outages, когато незадължителен service е влошен.

Как се правят deploy, наблюдение и проверка в production?

Стартирайте release-а и изчакайте terminal state:

dockup deploy production/api --wait --json

Default timeout-ът е 900 секунди. Exit 0 означава success. deploy_failed и deploy_timeout са non-zero резултати, така че shell scripts и CI системите спират правилно.

За да наблюдавате build-а като NDJSON:

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

Stream-ът приключва при success или failure. Ако build-ът е успешен, но container-ът се срине, проверете runtime logs:

dockup logs production/api --json

След успешен release проверете състоянието на платформата и публичното поведение:

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

Uptime probes се изпълняват всяка минута и отчитат средното време за response и p95. Security scanning проверява за image CVEs и проблеми в configuration. Добавете специфичен за application-а smoke test за реалния business endpoint; platform readiness е необходима, но не е достатъчна.

Подробният метод за работа с logs е описан в build and runtime log debugging.

Как трябва да се въведат automatic deploys и previews?

Направете първия production release достатъчно ръчно, за да наблюдавате всяка граница. След като са ясни build-ът, health gate-ът и rollback пътят, активирайте deployment при push:

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

Automatic deployment трябва да следва protected branch и policy за code review. Push към repository е production trigger, затова permissions за repository се превръщат в infrastructure permissions.

Pull request и branch previews предоставят изолирани URLs и environments:

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

В project с private networking previews се присъединяват към project network-а. Те могат да достигат до същата production database на <slug>.internal, но Dockup създава автоматичен read-only database user за preview-то. Preview-то може да преглежда данни със структура като тази в production, без да ги променя.

Това не отменя задълженията за privacy. Достъпът на previews все пак трябва да бъде ограничен и одитиран и да се използва само когато четенето на production данни е разрешено.

Как се прави rollback на неуспешен deployment?

Запазете evidence преди recovery. Прочетете build logs при build failure и runtime logs при crash. След това изведете deployment history:

dockup deployments production/api -n 20 --json

Изберете deployment ID, чийто status и timestamp са известни, след което го изпълнете отново:

dockup rollback <deploymentId> production/api --json

Rollback трябва да бъде изрично incident действие. Запишете ID на неуспешния deployment, избрания recovery ID, причината и последващия fix. Ако database migration не е backward compatible, rollback само на application-а може да не възстанови съвместимостта; design-ът на migration-ите трябва да бъде част от release плана.

Ръководството за deployment без downtime обяснява traffic cutover-а, а Dockup CLI reference документира всички command flags.

Запис за завършване на първия deploy

В края на workflow-а от Git repository до production запишете:

• Точния project/service target.
• Repository-то и production branch-а.
• Build метода: Nixpacks или Dockerfile.
• Build и start командите, когато са override-нати.
• Listening port-а и health path-а.
• Deployment ID и terminal status.
• Production URL и плана за custom domain.
• Uptime и security проверката.
• Rollback deployment ID или правилото за избор.

Този запис превръща втория deployment в рутинна операция, а не в поредно проучване.

Отделете application state от container image

Writable filesystem-ът в service container трябва да се приема като заменяем. Нов deployment създава нова версия, а rollback изпълнява отново по-стар image; файловете, записани само в стария container, не са надеждна стратегия за durable data.

Използвайте managed databases за relational, document или cache state и прикачете volume за файлове, които трябва да се запазят между deployments. Потвърдете mount paths преди първия production release. Containerized upload directory, която никога не е била mount-ната, може да изглежда здрава, докато следващият deploy не изтрие данните.

Прегледайте persistent volumes and snapshots, преди да преместите user-generated files. За database state използвайте специфичната backup система на database-а, вместо да приемате hot volume snapshot за transaction-consistent backup.

Как да изчислите първия месец, без да измисляте фиксирана сметка за instance?

Dockup измерва потреблението на CPU, RAM и disk всяка минута и приспада използваното от баланса на плана. Free plan включва началeн кредит от $10 и до три deployments; препоръчителният Pro plan струва $20 месечно и включва $20 usage credit.

След като service-ът започне да получава реален traffic, прегледайте потреблението му на CPU, RAM и disk в app.dockup.ai. Използвайте наблюдаваното потребление на минута, а не предположен максимум, за да решите дали service-ът, database-ът или persistent disk-ът се нуждаят от промяна.

Проверете чист втори deployment

След първия release направете безобидна промяна, преминала review, и deploy-нете отново. Така потвърждавате, че repository link-ът, предположенията за build cache-а, health gate-ът, environment-ът и history работят като постоянен process, а не само като еднократно успешно provisioning действие.

Поддържайте target-а изрично указан

Запишете окончателния project/service string.

Запазете URL-а на release-а

Запишете production URL-а до deployment ID.

Потвърдете следващия trigger

Запишете дали бъдещите releases са ръчни или използват незадължителен deploy-on-push. Така permissions за repository, branch protection и production очакванията остават съгласувани след първия deployment.

Започнете с deployment, който може да бъде проверен

Изберете малко repository с ясна start команда и health route, след което документирайте точния target и rollback ID след първия успешен release.

Започнете безплатно в app.dockup.ai. Free plan е $0 месечно, включва $10 начален кредит и поддържа един workspace, три databases и три deployments.

Често задавани въпроси

Може ли Dockup да deploy-не repository без Dockerfile?

Да. Когато няма Dockerfile, Dockup използва Nixpacks, за да открие и build-не application-а автоматично.

Какво прави dockup create --link?

Той записва .dockup link в текущата директория, така че следващите команди да могат да открият свързания project/service target.

Защо първият deploy трябва да използва --wait?

Той поддържа командата свързана, докато deployment-ът достигне success, failure или timeout, и връща exit code, който точно представя крайния резултат.

Прилагат ли се промените в environment variables незабавно?

Не. Те се прилагат към нов container при следващия deployment, затова deploy-нете service-а отново след промяна на environment configuration.

Как Dockup прави rollback на application?

Изведете deployment history, идентифицирайте известен предишен deployment ID и използвайте dockup rollback с този ID и точния service target.