Codex deployment: Dockup workflow od početka do kraja

Codex deployment treba završiti dokazima, a ne pretpostavkom. Praktični izazov nije zatražiti od Codexa da pokrene deploy naredbu, nego agentu omogućiti sučelje koje identificira točno odredište, čeka završno stanje, vraća stvarne exit kodove i prikazuje pojedinosti o pogrešci bez browsera.

Dockup je deployment sloj za ovaj workflow. Njegov CLI Codexu za svaku podržanu naredbu daje strukturirani JSON, a ugrađeni skill uči agenta kako se autentificirati, pronaći servise, pokrenuti deployment, dijagnosticirati probleme i zaustaviti se prije destruktivnih operacija.

Kako instalirati Codex CLI skill?

Instalirajte CLI globalno, a zatim pokrenite jedinstveni installer za skill. On zapisuje canonical skill i povezuje ga s Claude Codeom i Codexom:

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

Canonical skill nalazi se u ~/.agents/skills/dockup/ i symlinkom je povezan s ~/.codex/skills/. Dolazi unutar dockup-cli paketa, pa se uobičajenim ažuriranjem zajedno mijenjaju izvršna datoteka i njezine upute:

dockup update

Ova povezanost verzija važna je kod velikog broja naredbi. Agent nikada ne bi smio izvršiti zapamćenu zastavicu samo zato što se pojavila u starom promptu. Codex treba koristiti skill iz paketa i aktualni Dockup CLI reference kao autoritativni izvor za naredbe.

Za obrazloženje dizajna skillova pogledajte agent skills vs MCP.

Kako se Codex autentificira bez interaktivnog terminala?

Sandbox ili CI job možda ne može dovršiti login putem browsera. Postavite token u environment procesa:

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

DOCKUP_TOKEN ima prednost pred lokalnom config datotekom. Odgovor naredbe whoami pokazuje je li aktivna vjerodajnica preuzeta iz environmenta ili configa, što Codexu pomaže dijagnosticirati čest slučaj u kojem istodobno postoje zastarjeli lokalni token i CI token.

Token tretirajte kao infrastructure secret. Nemojte ga stavljati u AGENTS.md, SKILL.md, source control, primjere naredbi commitane u repository ili završni transcript agenta. U CI-ju koristite platformin encrypted secret store i vrijednost izložite samo deployment koraku. Potpuni non-interactive obrazac opisan je u članku CI/CD with DOCKUP_TOKEN.

Prije nego što Codexu omogućite write access, odredite opseg njegovih dopuštenja. Razuman početni opseg uključuje otkrivanje servisa, deployment, čitanje logova i provjeru statusa. Brisanje baze podataka, uništavanje servisa, promjene tima i uklanjanje configa trebaju i dalje zahtijevati odobrenje.

Kako Codex pronalazi ili izrađuje ispravan servis?

Neka otkrivanje bude prva operacija. Nemojte od Codexa tražiti da naziv „Payments API” pretvori u pretpostavljeni slug:

dockup services --json

Svaki rezultat uključuje točan target u obliku project/service. Codex bi tu vrijednost trebao kopirati u sljedeće naredbe i vratiti je u sažetku.

Kada servis ne postoji, izradite ga iz Gita:

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

Naredba izrađuje servis, pokreće deployment, blokira dok se deployment ne razriješi i u radnom direktoriju zapisuje .dockup link. Ako postoji Dockerfile, koristi se on; u suprotnom Nixpacks automatski detektira način buildanja.

Kada Codex izgubi stanje sesije ili se workflow ponovno pokrene nakon prekida mreže, trebao bi ponovno pronaći servise i provjeriti točan target prije bilo kakve izmjene. Ako target već postoji, nastavite na temelju njegova statusa i povijesti deploymenta umjesto slanja novog create requesta.

Cijeli slijed koji počinje od repositoryja dostupan je u članku Git repository to production.

Kako Codex treba pripremiti konfiguraciju prije deploymenta?

Zatražite od Codexa da provjeri aktualne metapodatke servisa prije njihove izmjene:

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

Environment response uključuje ključeve i oznake isSecret, dok vrijednosti secretova ostaju maskirane. Codex može zasebno dodati obične varijable i secretove:

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

Nikada nemojte produkcijski secret stavljati u dockup.yaml; manifest je prikladan za konfiguraciju u običnom tekstu koja se može pregledavati, a ne za credentials. Postojeće secret varijable config-as-code workflow ne prepisuje niti uklanja.

Konfigurirajte port na kojem servis osluškuje i readiness check kada su ti podaci poznati:

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

Readiness gate čini provjeru produkcije smislenom. Platforma provodi blue-green deployment i usmjerava promet tek nakon što nova verzija zadovolji gate.

Kako provjera produkcije potvrđuje završno stanje?

Za postojeći servis upotrijebite jednu naredbu:

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

Eksplicitni timeout podudara se sa zadanih 900 sekundi i jasno pokazuje namjeru workflowa. Exit 0 znači da je deployment uspio. Rezultat različit od nule s vrijednošću deploy_failed znači da su build ili deployment završili neuspjehom. deploy_timeout znači da operacija još nije bila u završnom stanju kada je vrijeme čekanja isteklo.

Ispravna Codexova logika grananja temelji se na statusu procesa:

Rezultat	Radnja za Codex
Exit 0, status:"success"	Nastaviti s provjerama healtha, uptimea i sigurnosti
deploy_failed	Pročitati build logove i pronaći prvu pogrešku na temelju koje se može postupati
deploy_timeout	Prijaviti neizvjesnost; provjeriti status ili ponoviti pokušaj uz opravdan timeout
not_logged_in	Zaustaviti se i zatražiti valjan token
needs_confirm	Zaustaviti se i zatražiti odobrenje čovjeka

Nakon uspješnog Codex deploymenta prikupite provjerljive dokaze:

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

Uptime provjere pokreću se svake minute i uključuju statistiku vremena odgovora, poput p95 vrijednosti. Sigurnosni rezultati uključuju CVE-ove imagea i konfiguracijske provjere. Ti signali ne dokazuju da poslovna logika ispravno radi, pa bi Codex trebao pokrenuti i vlastite smoke testove repositoryja kada su dostupni.

Kako Codex treba dijagnosticirati neuspješni release i oporaviti se?

Build pogreške i runtime pogreške zahtijevaju različite logove. Upotrijebite najnoviji build output kada deployment nikada nije dosegnuo pokretljivi container:

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

Runtime logove upotrijebite kada je image izgrađen, ali se aplikacija ruši, osluškuje na pogrešnom portu ili ne uspijeva nakon pokretanja:

dockup logs production/payments-api --json

Follow mode koristan je tijekom dugog builda:

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

U JSON modu follow output je NDJSON, što Codexu omogućuje obradu svakog batcha čim stigne. Stream završava kada deployment dosegne završno stanje i zadržava stvarni exit code pogreške.

Oporavak počinje poviješću, a ne pogađanjem cilja rollbacka:

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

Codex treba pronaći poznati uspješni deployment, navesti odabrani ID i sačuvati dokaze o neuspjehu prije ponovnog pokretanja. Nikada ne bi smio odabrati „drugu stavku” bez provjere statusa i vremenskih oznaka.

Koristan završni izvještaj ima sedam polja: target, branch ili commit, deployment ID, exit code, završni status, production URL i naknadne radnje. Takav format omogućuje da svaku Codex deployment operaciju pregleda čovjek ili kasniji automation korak.

Sažeta skripta za provjeru

Ovaj shell obrazac drži deployment i dijagnostiku u jednom transparentnom kontrolnom toku:

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

Skripta ne pretražuje poruku o uspjehu. Oslanja se na exit code CLI-ja, zadržava deployment JSON i označava pozivajući job neuspješnim kada produkcija nije dosegnula uspješno stanje.

Učinite ponovljene pokušaje vidljivima, a ne neprimjetnima

Agent sesije mogu biti prekinute nakon pokretanja operacije, ali prije nego što rezultat stigne u transcript. Sljedeće Codex pokretanje ne bi trebalo slijepo ponoviti svaku mutation operaciju. Trebalo bi ponovno pronaći servis, provjeriti najnoviji deployment i utvrditi je li prethodna operacija dosegnula završno stanje.

Codex deployment runbook treba naredbe razvrstati u one koje je sigurno ponoviti, one koje je sigurno ponoviti tek nakon provjere i one za koje je potrebno odobrenje. Read naredbe sigurno je ponavljati. Izrada servisa zahtijeva prethodno otkrivanje. Novi deploy novi je produkcijski događaj i tako ga treba evidentirati. Pruning i drugi destruktivni postupci ostaju odluke čovjeka.

Odvojite provjeru platforme od provjere aplikacije

Dockup može dokazati da je build dovršen, da je container postao spreman i da probe na razini minute opažaju javno dostupni servis. Codex bi ipak trebao pokrenuti provjere specifične za aplikaciju: javni health endpoint, authenticated test request ili smoke test repositoryja koji ne mijenja korisničke podatke.

Završni rezultat treba navesti oba sloja. „Platform deployment uspio” i „application smoke test prošao” različite su tvrdnje. Kada je dostupan samo prvi podatak, Codex to treba jasno reći umjesto da neizvjesnost sažme u zelenu kvačicu.

Prije automatizacije potvrdite instalirani command surface

Reusable Codex task trebao bi započeti provjerom dockup skill status --json i otvaranjem aktualnog CLI referencea kada ovisi o manje poznatoj opciji. Time se sprječava da sesija slijedi primjer napisan za drugo izdanje.

Provjera je posebno korisna u ephemeral runnerima gdje se nova globalna npm instalacija može razlikovati od one na developerskom laptopu. Codex može prijaviti stanje skilla prije prvog production writea, čime zapis deploymenta postaje reproducibilan.

Završna predaja

Sačuvajte dokaze.

Neka target bude vidljiv

U završnom izvještaju navedite točan target servisa.

Sačuvajte odluku o izvoru

Zabilježite je li Dockup koristio Dockerfile iz repositoryja ili Nixpacks. Ta informacija pomaže sljedećoj Codex sesiji odabrati odgovarajući build log i sprječava da se promjena strukture izvora pogrešno protumači kao incident na platformi.

Zabilježite i je li automatski deployment na push omogućen. U suprotnom se manualni agent release i release pokrenut pushom mogu preklopiti te iz iste istrage stvoriti dva produkcijska događaja.

Uvedite workflow u produkciju

Prvi Codex deployment pokrenite na disposable ili niskorizičnom servisu, a zatim isti provjereni command contract prenesite u produkciju.

npm install -g dockup-cli
dockup skill install

Prva naredba instalira CLI. Druga instalira odgovarajući Dockup skill za Claude Code i Codex. Započnite besplatno na app.dockup.ai.

Česta pitanja

Može li Codex jednom naredbom deployati novi Git repository?

Da. dockup create može izraditi servis, deployati ga, pričekati završni rezultat i povezati trenutačni direktorij kada se koristi s opcijama --deploy, --wait i --link.

Kako se Codex treba autentificirati na Dockup?

Upotrijebite DOCKUP_TOKEN u environmentu procesa i provjerite ga naredbom dockup whoami --json. Time se izbjegava interaktivni login putem browsera u sandboxima i CI-ju.

Što dokazuje da je Codex deployment uspio?

Deploy naredba mora završiti s exitom 0 nakon pokretanja s opcijom --wait, a njezin JSON mora prijaviti uspješan završni status. Nakon toga pokrenite status, uptime i application smoke provjere.

Može li Codex čitati produkcijske secretove iz Dockupa?

Ne. Vrijednosti secretova maskirane su u outputu. Codex može postaviti ili zamijeniti secret, ali ne prima spremljenu vrijednost prilikom izlistavanja konfiguracije.

Što Codex treba učiniti s vrijednošću needs_confirm?

Treba se zaustaviti i zatražiti izričito odobrenje čovjeka. Pogreška pokazuje da je pokušana destruktivna naredba bez obaveznog --yes confirmationa.