Codex-deployment: teljes Dockup-munkafolyamat

Egy Codex-deploymentnek bizonyítékokkal, nem pedig feltételezéssel kell lezárulnia. A gyakorlati kihívás nem az, hogy megkérjük Codexet egy deploy parancs futtatására, hanem hogy olyan interfészt adjunk az ügynöknek, amely azonosítja a pontos célt, megvárja a terminális állapotot, valódi exit code-okat ad vissza, és böngésző nélkül is elérhetővé teszi a hibák részleteit.

A Dockup ennek a munkafolyamatnak a deployment rétege. A CLI minden támogatott parancshoz strukturált JSON-t ad Codexnek, a beépített skill pedig megtanítja az ügynököt hitelesíteni, szolgáltatásokat felderíteni, deployolni, hibát diagnosztizálni, valamint a destruktív műveletek előtt megállni.

Hogyan telepíthető a Codex CLI-skill?

Telepítsd globálisan a CLI-t, majd futtasd az egyetlen skill-telepítőt. Ez létrehozza a canonical skillt, és belinkeli a Claude Code-ba és a Codexbe is:

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

A canonical skill a ~/.agents/skills/dockup/ útvonalon található, és symlinkként szerepel a ~/.codex/skills/ alatt. A dockup-cli részeként érkezik, így egy szokásos frissítés egyszerre módosítja a végrehajtható fájlt és a hozzá tartozó utasításokat:

dockup update

Ez a verziók összekapcsolása különösen fontos nagy command surface esetén. Egy ügynöknek soha nem szabad csak azért végrehajtania egy megjegyzett flaget, mert az egy régi promptban szerepelt. Codexnek a csomagolt skillt és az aktuális Dockup CLI-referenciát kell használnia a parancsok hiteles forrásaként.

A skillek mögötti tervezési megfontolásokról lásd: agent skillek az MCP-vel szemben.

Hogyan hitelesít Codex interaktív terminál nélkül?

Előfordulhat, hogy egy sandbox vagy CI-feladat nem tudja végrehajtani a böngészőalapú bejelentkezést. Állíts be tokent a process környezetében:

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

A DOCKUP_TOKEN elsőbbséget élvez a helyi config fájllal szemben. A whoami válaszából kiderül, hogy az aktív credential a környezetből vagy a configból származik-e. Ez segít Codexnek diagnosztizálni azt a gyakori esetet, amikor egy régi helyi token és egy CI-token egyszerre van jelen.

A tokent kezeld infrastructure secretként. Ne tedd bele az AGENTS.md vagy a SKILL.md fájlba, source controlba, a repositoryba commitolt parancspéldákba, illetve az ügynök végső transcriptjébe. CI-ban használd a platform titkosított secret store-át, és csak a deployment lépés számára tedd elérhetővé az értéket. A teljes non-interactive minta részletes leírását lásd itt: CI/CD DOCKUP_TOKEN használatával.

Mielőtt írási hozzáférést adsz Codexnek, határozd meg a jogosultsági kereteit. Ésszerű kezdeti hatókör a szolgáltatások felderítése, a deployment, a logok olvasása és a status checkek futtatása. Az adatbázis törlése, a szolgáltatások megsemmisítése, a team módosítása és a config ritkítása maradjon jóváhagyáshoz kötött.

Hogyan találja meg vagy hozza létre Codex a megfelelő szolgáltatást?

A felderítés legyen az első művelet. Ne kérd Codexet arra, hogy a „Payments API” szöveget egy kitalált slugra alakítsa:

dockup services --json

Minden találat tartalmaz egy pontos target értéket project/service formában. Codexnek ezt az értéket kell átmásolnia a további parancsokba, és az összefoglalójában is vissza kell adnia.

Ha még nem létezik szolgáltatás, hozz létre egyet Gitből:

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

A parancs létrehozza a szolgáltatást, deployolja, megvárja a deployment lezárását, és egy .dockup linket ír a munkakönyvtárba. Ha van Dockerfile, azt használja; egyébként a Nixpacks automatikusan felismeri a buildet.

Amikor Codex elveszíti a session állapotát, vagy egy workflow hálózati megszakítás után újraindul, először újra fel kell derítenie a szolgáltatásokat, majd a módosítások előtt meg kell vizsgálnia a pontos targetet. Ha a target már létezik, az állapotából és a deployment historyból kell folytatni a munkát, nem pedig újabb create requestet kiadni.

A teljes repository-first sorozatot lásd itt: Git repositorytól productionig.

Hogyan készítse elő Codex a konfigurációt deploy előtt?

Kérd meg Codexet, hogy a módosítások előtt vizsgálja meg az aktuális service metadata adatait:

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

A környezeti változókat tartalmazó válasz a kulcsokat és az isSecret jelöléseket is tartalmazza, miközben a secret értékek maszkolva maradnak. Codex külön adhat hozzá normál változókat és secreteket:

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

Soha ne tegyél production secretet a dockup.yaml fájlba; a manifest ellenőrizhető, egyszerű konfigurációhoz alkalmas, credentialekhez nem. A meglévő secret változókat a config-as-code workflow nem írja felül és nem ritkítja.

Állítsd be a szolgáltatás listening portját és readiness checkjét, ha ezek ismertek:

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

A readiness gate teszi értelmessé a production-ellenőrzést. A platform blue-green deploymentet hajt végre, és csak akkor irányítja át a forgalmat, amikor az új verzió teljesíti a gate feltételeit.

Hogyan erősíti meg a production-ellenőrzés a terminális állapotot?

Meglévő szolgáltatás esetén használj egyetlen parancsot:

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

A kifejezett timeout megegyezik az alapértelmezett 900 másodperccel, és láthatóvá teszi a workflow szándékát. A 0 exit azt jelenti, hogy a deployment sikeres volt. A deploy_failed értékkel jelzett nem nulla eredmény azt jelenti, hogy a build vagy a deploy hibával zárult. A deploy_timeout azt jelenti, hogy a művelet a várakozási idő végén még nem ért terminális állapotba.

A helyes Codex-ágazási logika a process státuszán alapul:

Eredmény	Codex művelete
Exit 0, status:"success"	Folytassa a health, uptime és security ellenőrzésével
deploy_failed	Olvassa el a build logokat, és azonosítsa az első javítható hibát
deploy_timeout	Jelezze a bizonytalanságot; vizsgálja meg a statust, vagy indítsa újra indokolt timeouttal
not_logged_in	Álljon le, és kérjen érvényes tokent
needs_confirm	Álljon le, és kérjen emberi jóváhagyást

Sikeres Codex-deployment után gyűjts megfigyelhető bizonyítékokat:

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

Az uptime checkek percenként futnak, és olyan válaszidő-statisztikákat is tartalmaznak, mint a p95. A security eredmények tartalmazzák az image CVE-it és a konfigurációs ellenőrzéseket. Ezek a jelzések nem bizonyítják az üzleti helyességet, ezért Codexnek a repository saját smoke testjeit is le kell futtatnia, ha rendelkezésre állnak.

Hogyan diagnosztizálja és állítsa helyre Codex a sikertelen release-t?

A buildhibákhoz és a runtime hibákhoz eltérő logokra van szükség. A legutóbbi build kimenetét használd, ha a deployment soha nem jutott el futtatható containerig:

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

Runtime logokat használj, ha az image felépült, de az alkalmazás összeomlik, rossz porthoz bindol, vagy indulás után hibázik:

dockup logs production/payments-api --json

A follow mód hasznos hosszú build esetén:

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

JSON módban a follow kimenete NDJSON, így Codex minden batch-et feldolgozhat, amint az megérkezik. A stream terminális deployment-állapotnál ér véget, és megőrzi a valódi hibás exit code-ot.

A helyreállítást az előzmények vizsgálatával kell kezdeni, nem egy találomra választott rollback targettel:

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

Codexnek azonosítania kell egy ismerten sikeres deploymentet, meg kell neveznie a kiválasztott ID-t, és az újrafuttatás előtt meg kell őriznie a hibára vonatkozó bizonyítékokat. Soha nem választhatja ellenőrzés nélkül „a második elemet”; az állapotot és az időbélyegeket is validálnia kell.

Egy hasznos végső jelentés hét mezőt tartalmaz: target, branch vagy commit, deployment ID, exit code, terminális status, production URL és a további műveletek. Ez a formátum lehetővé teszi, hogy minden Codex-deploymentet egy ember vagy egy későbbi automatizálási lépés felülvizsgáljon.

Tömör ellenőrző script

Ez a shell-minta egyetlen átlátható vezérlési folyamatban tartja a deploymentet és a diagnosztikát:

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

A script nem keres egy sikerre utaló mondatot grep-pel. A CLI exit code-jára támaszkodik, megőrzi a deployment JSON-ját, és hibával leállítja a hívó jobot, ha a production nem jutott sikeres állapotba.

Tedd láthatóvá az újrapróbálkozásokat ahelyett, hogy elrejtenéd őket

Az agent sessionök megszakadhatnak azután, hogy egy művelet elindult, de még azelőtt, hogy az eredmény bekerült volna a transcriptbe. A következő Codex-futtatásnak nem szabad vakon megismételnie minden mutációt. Újra fel kell derítenie a szolgáltatást, meg kell vizsgálnia a legutóbbi deploymentet, és meg kell állapítania, hogy az előző művelet eljutott-e terminális állapotba.

Egy Codex-deployment runbookjának a parancsokat meg kell különböztetnie aszerint, hogy biztonságosan ismételhetők, csak ellenőrzés után ismételhetők, vagy jóváhagyáshoz kötöttek. Az olvasási műveletek biztonságosan ismételhetők. A szolgáltatás létrehozása előtt felderítésre van szükség. Egy új deploy új production esemény, ezért ennek megfelelően kell rögzíteni. A ritkítás és az egyéb destruktív műveletek továbbra is emberi döntést igényelnek.

Válaszd külön a platform- és az alkalmazásszintű ellenőrzést

A Dockup bizonyítani tudja, hogy a build elkészült, a container ready állapotba került, és a percenként futó probe-ok elérik a publikus szolgáltatást. Codexnek ettől függetlenül alkalmazásspecifikus ellenőrzéseket is kell futtatnia: publikus health endpointot, authentikált tesztkérést vagy egy repository által biztosított, ügyféladatot nem módosító smoke testet.

A végső eredményben mindkét réteget fel kell tüntetni. A „platform deployment sikeres” és az „alkalmazás smoke testje sikeres” két külön állítás. Ha csak az első áll rendelkezésre, Codexnek ezt kell jeleznie, ahelyett hogy a bizonytalanságot egy zöld pipába sűrítené.

Automatizálás előtt erősítsd meg a telepített command surface-t

Egy újrahasznosítható Codex-feladatnak a dockup skill status --json ellenőrzésével kell kezdődnie, és meg kell nyitnia az aktuális CLI-referenciát, amikor egy kevésbé ismert opciótól függ. Így elkerülhető, hogy a session egy másik release-hez készült példát kövessen.

Az ellenőrzés különösen hasznos ephemeral runner környezetben, ahol egy friss globális npm-telepítés eltérhet a fejlesztő laptopján találhatótól. Codex még az első production write előtt jelentheti a skill állapotát, így a deployment rekordja reprodukálhatóvá válik.

Végső átadás

Őrizd meg a bizonyítékokat.

Tartsd láthatóan a targetet

A végső jelentésben add vissza a pontos service targetet.

Őrizd meg a source-döntést

Rögzítsd, hogy a Dockup a repository Dockerfile-ját vagy a Nixpackset használta-e. Ez az információ segít a következő Codex-sessionnek kiválasztani a megfelelő build logot, és megakadályozza, hogy egy source-layout változást platformincidensként értelmezzen.

Azt is rögzítsd, hogy engedélyezve van-e a push utáni automatikus deploy. Ellenkező esetben egy manuális agent release és egy push által indított release átfedhet, és ugyanabból a vizsgálatból két production eseményt hozhat létre.

Vidd a workflow-t productionbe

Az első Codex-deploymentet futtasd egy eldobható vagy alacsony kockázatú szolgáltatáson, majd ugyanazt az ellenőrzött parancsszerződést emeld production környezetbe.

npm install -g dockup-cli
dockup skill install

Az első parancs telepíti a CLI-t. A második a hozzá illeszkedő Dockup-skillt telepíti Claude Code és Codex számára. Kezdd ingyenesen az app.dockup.ai oldalon.

GYIK

Deployolhat Codex egy új Git repositoryt egyetlen paranccsal?

Igen. A dockup create létrehozhatja a szolgáltatást, deployolhatja azt, megvárhatja a terminális eredményt, és belinkelheti az aktuális könyvtárat, ha a --deploy, --wait és --link opciókkal használod.

Hogyan hitelesítse magát Codex a Dockuphoz?

Használd a DOCKUP_TOKEN értékét a process környezetében, majd ellenőrizd a dockup whoami --json paranccsal. Így sandboxokban és CI-ban elkerülhető az interaktív böngészős bejelentkezés.

Mi bizonyítja, hogy egy Codex-deployment sikeres volt?

A deploy parancsnak --wait használata után 0 exit code-dal kell kilépnie, a JSON-nak pedig sikeres terminális statust kell jeleznie. Ezt kövesse status, uptime és alkalmazásszintű smoke check.

Kiolvashatja Codex a production secreteket a Dockupból?

Nem. A secret értékek maszkolva jelennek meg a kimenetben. Codex beállíthat vagy lecserélhet egy secretet, de a konfiguráció listázásakor nem kapja meg a tárolt értéket.

Mit tegyen Codex a needs_confirm értékkel?

Álljon le, és kérjen kifejezett emberi jóváhagyást. A hiba azt jelzi, hogy egy destruktív parancsot a szükséges --yes megerősítés nélkül próbáltak végrehajtani.