Codex deployment: цялостен workflow с Dockup

Един Codex deployment трябва да завършва с доказателства, а не с предположение. Практическото предизвикателство не е да помолите Codex да изпълни deploy команда, а да дадете на агента интерфейс, който идентифицира точния target, изчаква terminal state, връща реални exit codes и показва подробности за грешките без browser.

Dockup е deployment слоят за този workflow. Неговият CLI предоставя на Codex структуриран JSON за всяка поддържана команда, а вграденият skill обучава агента как да се authenticate-ва, да открива services, да извършва deployment, да диагностицира проблеми и да спира преди destructive operations.

Как да инсталирате Codex CLI skill?

Инсталирайте CLI глобално, след което изпълнете единствения installer за skill. Той записва canonical skill-а и го свързва както с Claude Code, така и с Codex:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

Canonical skill-ът се намира в ~/.agents/skills/dockup/ и е symlink-нат към ~/.codex/skills/. Той е част от dockup-cli, така че стандартен update променя едновременно executable файла и инструкциите му:

dockup update

Тази version coupling е важна при голям набор от команди. Един agent никога не трябва да изпълнява запомнен flag само защото е присъствал в стар prompt. Codex трябва да използва пакетирания skill и актуалния Dockup CLI reference като authority за командите.

За обосновката зад skills вижте agent skills vs MCP.

Как Codex се authenticate-ва без интерактивен terminal?

Sandbox или CI job може да не успее да завърши login чрез browser. Задайте token в process environment:

export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

DOCKUP_TOKEN има предимство пред local config файла. Отговорът от whoami показва дали активният credential идва от environment или config, което помага на Codex да диагностицира често срещания случай, при който stale local token и CI token съществуват едновременно.

Третирайте token-а като infrastructure secret. Не го поставяйте в AGENTS.md, SKILL.md, source control, command examples, commit-нати в repository-то, или във финалния transcript на агента. В CI използвайте encrypted secret store на платформата и предоставяйте стойността само на deployment стъпката. Пълният non-interactive pattern е описан в CI/CD with DOCKUP_TOKEN.

Преди да дадете write access на Codex, определете неговия permission envelope. Разумният първоначален scope включва service discovery, deployment, четене на logs и status checks. Изтриването на database, унищожаването на service, промените по team и config pruning трябва да останат approval-gated.

Как Codex намира или създава правилния service?

Направете discovery първата операция. Не карайте Codex да преобразува „Payments API“ в предположен slug:

dockup services --json

Всеки резултат включва точен target във формат project/service. Codex трябва да копира тази стойност в следващите команди и да я върне в summary-то си.

Когато няма съществуващ service, създайте такъв от Git:

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

Командата създава service-а, deploy-ва го, блокира, докато deployment-ът завърши, и записва .dockup link в работната директория. Когато е наличен Dockerfile, се използва той; в противен случай Nixpacks извършва автоматично разпознаване на build-а.

Когато Codex загуби session state или workflow-ът бъде стартиран отново след мрежово прекъсване, той трябва отново да открие services и да провери точния target, преди да промени нещо. Ако target-ът вече съществува, продължете от неговия status и deployment history, вместо да изпращате нов create request.

Пълната repository-first последователност е достъпна в Git repository to production.

Как Codex трябва да подготви configuration преди deployment?

Помолете Codex да провери текущите metadata на service-а, преди да ги променя:

dockup info production/payments-api --json
dockup env list -s production/payments-api --json

Environment отговорът включва keys и isSecret markers, докато secret стойностите остават masked. Codex може да добавя обикновени variables и secrets поотделно:

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

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

Никога не поставяйте production secret в dockup.yaml; manifest-ът е подходящ за configuration в plain text, която може да бъде преглеждана, но не и за credentials. Съществуващите secret variables не се overwrite-ват или prune-ват от config-as-code workflow-а.

Конфигурирайте listening port-а и readiness check-а на service-а, когато са известни:

dockup set production/payments-api --port 3000 --json
dockup health production/payments-api \
  --path /health \
  --interval 5 \
  --retries 5 \
  --json

Readiness gate прави production verification смислена. Платформата извършва blue-green deployment и насочва traffic само след като новата версия изпълни gate-а.

Как production verification потвърждава terminal state?

За съществуващ service използвайте една команда:

dockup deploy production/payments-api \
  --wait \
  --timeout 900 \
  --json

Явният timeout съвпада с default стойността от 900 секунди и прави намерението на workflow-а видимо. Exit 0 означава, че deployment-ът е успешен. Non-zero резултат с deploy_failed означава, че build или deploy е завършил с failure. deploy_timeout означава, че операцията все още не е била terminal, когато периодът на изчакване е изтекъл.

Правилната branching logic за Codex се основава на process status-а:

Резултат	Действие на Codex
Exit 0, status:"success"	Продължете към health, uptime и security verification
deploy_failed	Прочетете build logs и идентифицирайте първата actionable грешка
deploy_timeout	Докладвайте несигурност; проверете status или retry-нете с обоснован timeout
not_logged_in	Спрете и поискайте валиден token
needs_confirm	Спрете и поискайте human approval

След успешен Codex deployment съберете observable evidence:

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

Uptime checks се изпълняват всяка минута и включват response-time statistics, например p95. Security резултатите включват image CVEs и configuration checks. Тези сигнали не доказват business correctness, затова Codex трябва да изпълни и собствените smoke tests на repository-то, когато са налични.

Как Codex трябва да диагностицира и възстанови failed release?

Build errors и runtime errors изискват различни logs. Използвайте последния build output, когато deployment-ът не е достигнал runnable container:

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

Използвайте runtime logs, когато image-ът е build-нат, но application-ът crash-ва, bind-ва грешен port или се проваля след startup:

dockup logs production/payments-api --json

Follow mode е полезен при дълъг build:

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

В JSON mode follow output-ът е NDJSON, което позволява на Codex да обработва всеки batch при пристигането му. Stream-ът завършва при terminal deployment state и запазва реалния failure exit code.

Recovery започва с history, а не с предположен rollback target:

dockup deployments production/payments-api -n 20 --json
dockup rollback <deploymentId> production/payments-api --json

Codex трябва да идентифицира познат успешен deployment, да посочи избрания ID и да запази evidence за failure-а, преди да го стартира отново. Никога не трябва да избира „втория елемент“, без да провери status и timestamps.

Полезният финален report има седем полета: target, branch или commit, deployment ID, exit code, terminal status, production URL и follow-up actions. Този формат прави всеки Codex deployment прегледен от човек или от следваща automation стъпка.

Компактен verification script

Този shell pattern събира deployment-а и diagnosis-а в един прозрачен control flow:

if dockup deploy production/payments-api --wait --json > deploy-result.json; then
  dockup status production/payments-api --json
  dockup uptime production/payments-api --hours 24 --json
else
  dockup logs production/payments-api --build --json
  exit 1
fi

Script-ът не търси success sentence чрез grep. Той се доверява на CLI exit code-а, запазва deployment JSON-а и проваля calling job-а, когато production не е достигнал success.

Направете retries observable, а не невидими

Agent sessions могат да бъдат прекъснати, след като операцията е започнала, но преди резултатът да достигне transcript-а. Следващото Codex изпълнение не трябва сляпо да повтаря всяка mutation. То трябва отново да открие service-а, да провери последния deployment и да установи дали предишната операция е достигнала terminal state.

Един Codex deployment runbook трябва да класифицира командите като safe to repeat, safe only after inspection или approval-gated. Read операциите могат да се повтарят безопасно. Service creation изисква discovery предварително. Нов deploy е нов production event и трябва да бъде записан като такъв. Pruning и другите destructive operations остават човешки решения.

Разделяйте platform verification от application verification

Dockup може да докаже, че build-ът е завършил, container-ът е станал ready и minute-level probes наблюдават публичния service. Codex все пак трябва да изпълни application-specific checks: публичен health endpoint, authenticated test request или предоставен от repository-то smoke test, който не променя customer data.

Финалният резултат трябва да посочва и двата слоя. „Platform deployment succeeded“ и „application smoke test passed“ са различни твърдения. Когато е наличен само първият резултат, Codex трябва да го каже, вместо да превръща несигурността в зелена отметка.

Потвърждавайте инсталирания command surface преди automation

Една reusable Codex задача трябва да започва с проверка на dockup skill status --json и отваряне на актуалния CLI reference, когато използва по-малко позната option. Това предотвратява следването на пример, написан за друг release.

Проверката е особено полезна в ephemeral runners, където нова глобална npm инсталация може да се различава от тази на developer laptop. Codex може да докладва skill state-а, преди да извърши първия production write, което прави deployment record-а reproducible.

Финално предаване

Запазете evidence.

Дръжте target-а видим

Върнете точния service target във финалния report.

Запазете решението за source-а

Запишете дали Dockup е използвал repository Dockerfile или Nixpacks. Този факт помага на следващата Codex session да избере правилния build log и предотвратява объркването на промяна в source layout-а с platform incident.

Запишете също дали automatic deploy on push е включен. В противен случай manual agent release и push-triggered release могат да се припокрият и да създадат два production events от едно и също разследване.

Въведете workflow-а в production

Изпълнете първия Codex deployment към disposable или low-risk service, след което прехвърлете същия проверен command contract към production.

npm install -g dockup-cli
dockup skill install

Първата команда инсталира CLI. Втората инсталира съвместимия Dockup skill за Claude Code и Codex. Започнете безплатно от app.dockup.ai.

FAQ

Може ли Codex да deploy-не нов Git repository с една команда?

Да. dockup create може да създаде service-а, да го deploy-не, да изчака terminal резултата и да свърже текущата директория, когато се използва с --deploy, --wait и --link.

Как Codex трябва да се authenticate-ва към Dockup?

Използвайте DOCKUP_TOKEN в process environment и го проверете с dockup whoami --json. Това избягва интерактивния browser login в sandboxes и CI.

Какво доказва, че един Codex deployment е успешен?

Deploy командата трябва да завърши с exit 0 след изпълнение с --wait, а нейният JSON трябва да отчете успешен terminal status. След това изпълнете status, uptime и application smoke checks.

Може ли Codex да прочете production secrets от Dockup?

Не. Secret стойностите са masked в output-а. Codex може да задава или заменя secret, но не получава съхранената стойност при listing на configuration.

Какво трябва да направи Codex при needs_confirm?

Той трябва да спре и да поиска изрично human approval. Грешката показва, че е направен опит за destructive command без необходимото --yes confirmation.