Codex-distribusjon: Dockup-arbeidsflyt fra start til slutt

En Codex-distribusjon bør avsluttes med dokumentasjon, ikke antakelser. Den praktiske utfordringen er ikke å be Codex kjøre en deploy-kommando, men å gi agenten et grensesnitt som identifiserer det nøyaktige målet, venter på en terminaltilstand, returnerer faktiske exit-koder og viser feildetaljer uten en nettleser.

Dockup er distribusjonslaget for denne arbeidsflyten. CLI-et gir Codex strukturert JSON for alle støttede kommandoer, og den medfølgende skill-en lærer agenten hvordan den autentiserer, finner tjenester, distribuerer, diagnostiserer og stopper før destruktive operasjoner.

Hvordan installerer du Codex CLI-skill-en?

Installer CLI-et globalt, og kjør deretter den eneste skill-installasjonen. Den skriver den kanoniske skill-en og lenker den inn i både Claude Code og Codex:

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

Den kanoniske skill-en ligger i ~/.agents/skills/dockup/ og lenkes til ~/.codex/skills/. Den følger med i dockup-cli, slik at en vanlig oppdatering endrer både den kjørbare filen og instruksjonene samtidig:

dockup update

Denne koblingen mellom versjoner er viktig når kommandoflaten er stor. En agent bør aldri kjøre et flagg den husker, bare fordi det dukket opp i en gammel prompt. Codex bør bruke den pakkede skill-en og den oppdaterte Dockup CLI-referansen som autoritativ kilde for kommandoer.

Se agent skills vs MCP for begrunnelsen bak designet av skills.

Hvordan autentiserer Codex uten en interaktiv terminal?

En sandbox eller CI-jobb kan kanskje ikke fullføre en nettleserbasert innlogging. Angi et token i prosessmiljøet:

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

DOCKUP_TOKEN har forrang over den lokale konfigurasjonsfilen. Svaret fra whoami viser om den aktive legitimasjonen kom fra miljøet eller konfigurasjonen. Dette hjelper Codex med å diagnostisere det vanlige tilfellet der et utdatert lokalt token og et CI-token eksisterer samtidig.

Behandle tokenet som en infrastrukturhemmelighet. Ikke legg det i AGENTS.md, SKILL.md, kildekontroll, kommandoeksempler som legges inn i repositoryet, eller agentens sluttrapport. I CI bør du bruke plattformens krypterte secret store og bare eksponere verdien for distribusjonstrinnet. Hele det ikke-interaktive mønsteret er beskrevet i CI/CD with DOCKUP_TOKEN.

Før du gir Codex skrivetilgang, må du bestemme hvilke tillatelser agenten skal ha. Et fornuftig utgangspunkt omfatter tjenesteoppdagelse, distribusjon, lesing av logger og statussjekker. Sletting av databaser, destruksjon av tjenester, teamendringer og trimming av konfigurasjon bør fortsatt kreve godkjenning.

Hvordan finner eller oppretter Codex riktig tjeneste?

Gjør oppdagelse til første operasjon. Ikke be Codex om å gjøre «Payments API» om til en gjetning av en slug:

dockup services --json

Hvert resultat inneholder et nøyaktig target i formatet project/service. Codex bør kopiere denne verdien inn i påfølgende kommandoer og returnere den i oppsummeringen.

Når ingen tjeneste finnes, kan du opprette en fra Git:

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

Kommandoen oppretter tjenesten, distribuerer den, blokkerer til distribusjonen er ferdig, og skriver en .dockup-lenke i arbeidskatalogen. En Dockerfile brukes når den finnes; ellers utfører Nixpacks automatisk byggdeteksjon.

Når Codex mister sesjonstilstanden, eller en arbeidsflyt kjøres på nytt etter et nettverksavbrudd, bør den finne tjenestene på nytt og kontrollere det nøyaktige målet før den endrer noe. Hvis målet allerede finnes, bør den fortsette basert på status og distribusjonshistorikk i stedet for å sende en ny create-forespørsel.

Den komplette repository-først-sekvensen er tilgjengelig i Git repository to production.

Hvordan bør Codex klargjøre konfigurasjonen før distribusjon?

Be Codex inspisere gjeldende metadata for tjenesten før den gjør endringer:

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

Miljøresponsen inneholder nøkler og isSecret-markører, mens hemmelige verdier forblir maskerte. Codex kan legge til vanlige variabler og secrets separat:

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

Legg aldri et production-secret i dockup.yaml; manifestet egner seg for konfigurasjon i klartekst som kan gjennomgås, ikke for credentials. Eksisterende secret-variabler overskrives eller fjernes ikke av config-as-code-arbeidsflyten.

Konfigurer tjenestens lytteport og readiness-sjekk når du kjenner verdiene:

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

En readiness-gate gjør produksjonsverifiseringen meningsfull. Plattformen utfører en blue-green-distribusjon og ruter trafikk først når den nye versjonen oppfyller gaten.

Hvordan bekrefter produksjonsverifiseringen terminaltilstanden?

For en eksisterende tjeneste bruker du én kommando:

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

Den eksplisitte tidsavbruddsverdien samsvarer med standardverdien på 900 sekunder og gjør hensikten med arbeidsflyten synlig. Exit 0 betyr at distribusjonen var vellykket. Et resultat som ikke er null, med deploy_failed, betyr at byggingen eller distribusjonen mislyktes. deploy_timeout betyr at operasjonen fortsatt ikke hadde nådd en terminaltilstand da ventetiden utløp.

Riktig forgreningslogikk for Codex er basert på prosessstatusen:

Resultat	Codex-handling
Exit 0, status:"success"	Fortsett med verifisering av health, uptime og security
deploy_failed	Les byggloggene og identifiser den første feilen som kan løses
deploy_timeout	Rapporter usikkerhet; inspiser status eller prøv på nytt med en begrunnet tidsavbruddsverdi
not_logged_in	Stopp og be om et gyldig token
needs_confirm	Stopp og be om godkjenning fra et menneske

Etter en vellykket Codex-distribusjon bør du samle observerbare bevis:

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

Uptime-sjekker kjøres hvert minutt og inkluderer statistikk for responstid, for eksempel p95. Security-resultater inkluderer CVE-er i images og konfigurasjonssjekker. Disse signalene beviser ikke at forretningslogikken fungerer, så Codex bør også kjøre repositoryets egne smoke-tester når de er tilgjengelige.

Hvordan bør Codex diagnostisere og gjenopprette etter en mislykket release?

Byggfeil og runtime-feil krever ulike logger. Bruk den nyeste byggoutputen når distribusjonen aldri nådde en kjørbar container:

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

Bruk runtime-logger når imaget ble bygget, men applikasjonen krasjer, binder feil port eller feiler etter oppstart:

dockup logs production/payments-api --json

Follow-modus er nyttig under en langvarig bygging:

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

I JSON-modus er follow-output NDJSON, slik at Codex kan behandle hver batch etter hvert som den kommer. Strømmen avsluttes ved en terminal distribusjonstilstand og bevarer den faktiske feilens exit-kode.

Gjenoppretting starter med historikken, ikke med et gjetting av mål for rollback:

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

Codex bør identifisere en kjent vellykket distribusjon, oppgi den valgte ID-en og bevare feilbevisene før den kjører den på nytt. Den bør aldri velge «det andre elementet» uten å kontrollere status og tidsstempler.

En nyttig sluttrapport har sju felt: mål, branch eller commit, distribusjons-ID, exit-kode, terminalstatus, production-URL og oppfølgingshandlinger. Dette formatet gjør hver Codex-distribusjon etterprøvbar for en person eller et senere automatiseringstrinn.

Et kompakt verifiseringsskript

Dette shell-mønsteret holder distribusjon og diagnostisering i én transparent kontrollflyt:

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

Skriptet leter ikke etter en setning som bekrefter suksess. Det stoler på CLI-ets exit-kode, beholder distribusjonens JSON og feiler den kallende jobben når produksjonen ikke nådde suksess.

Gjør nye forsøk observerbare i stedet for usynlige

Agentsesjoner kan bli avbrutt etter at en operasjon har startet, men før resultatet når transkriptet. Neste Codex-kjøring bør derfor ikke blindt gjenta alle endringer. Den bør finne tjenesten på nytt, inspisere den nyeste distribusjonen og fastslå om den forrige operasjonen nådde en terminaltilstand.

En Codex-distribusjon-runbook bør klassifisere kommandoer som trygge å gjenta, trygge først etter inspeksjon, eller avhengige av godkjenning. Lesekommandoer er trygge å gjenta. Oppretting av tjenester krever oppdagelse først. En ny distribusjon er en ny produksjonshendelse og bør registreres som det. Trimming og annet destruktivt arbeid forblir menneskelige beslutninger.

Skill mellom plattformverifisering og applikasjonsverifisering

Dockup kan dokumentere at en bygging er fullført, at containeren ble klar, og at probes på minuttnivå observerer den offentlige tjenesten. Codex bør fortsatt kjøre applikasjonsspesifikke kontroller: et offentlig health-endpoint, en autentisert testforespørsel eller en smoke-test fra repositoryet som ikke endrer kundedata.

Sluttresultatet bør oppgi begge lagene. «Plattformdistribusjonen var vellykket» og «applikasjonens smoke-test besto» er ulike påstander. Når bare den første er tilgjengelig, bør Codex si det i stedet for å komprimere usikkerheten til et grønt hakemerke.

Bekreft den installerte kommandoflaten før automatisering

En gjenbrukbar Codex-oppgave bør begynne med å kontrollere dockup skill status --json og åpne den gjeldende CLI-referansen når den avhenger av et mindre kjent alternativ. Dette hindrer en sesjon i å følge et eksempel som er skrevet for en annen release.

Kontrollen er særlig nyttig i ephemeral runners, der en ny global npm-installasjon kan avvike fra en utviklers laptop. Codex kan rapportere skill-statusen før den utfører den første skrivingen til produksjon, slik at distribusjonsposten blir reproduserbar.

Endelig overlevering

Ta vare på bevisene.

Hold målet synlig

Returner det nøyaktige tjenestemålet i sluttrapporten.

Bevar beslutningen om kilde

Registrer om Dockup brukte repositoryets Dockerfile eller Nixpacks. Denne informasjonen hjelper neste Codex-sesjon med å velge riktig bygglogg og hindrer at en endring i kildestrukturen forveksles med en plattformhendelse.

Registrer også om automatisk distribusjon ved push er aktivert. En manuell agent-release og en push-utløst release kan ellers overlappe og opprette to produksjonshendelser fra samme undersøkelse.

Sett arbeidsflyten i produksjon

Kjør den første Codex-distribusjonen mot en tjeneste som kan kastes eller har lav risiko, og promoter deretter den samme verifiserte kommandokontrakten til produksjon.

npm install -g dockup-cli
dockup skill install

Den første kommandoen installerer CLI-et. Den andre installerer den matchende Dockup-skill-en for Claude Code og Codex. Kom i gang gratis på app.dockup.ai.

Vanlige spørsmål

Kan Codex distribuere et nytt Git-repository med én kommando?

Ja. dockup create kan opprette tjenesten, distribuere den, vente på terminalresultatet og lenke den gjeldende katalogen når den brukes med --deploy, --wait og --link.

Hvordan bør Codex autentisere mot Dockup?

Bruk DOCKUP_TOKEN i prosessmiljøet, og bekreft det med dockup whoami --json. Dette unngår interaktiv nettleserinnlogging i sandboxes og CI.

Hva beviser at en Codex-distribusjon var vellykket?

Deploy-kommandoen må avsluttes med exit 0 etter å ha kjørt med --wait, og JSON-en må rapportere en vellykket terminalstatus. Følg opp med status-, uptime- og applikasjonssmoke-sjekker.

Kan Codex lese produksjonshemmeligheter fra Dockup?

Nei. Hemmelige verdier er maskert i output. Codex kan angi eller erstatte en secret, men mottar ikke den lagrede verdien når konfigurasjonen listes.

Hva bør Codex gjøre med needs_confirm?

Den bør stoppe og be om eksplisitt godkjenning fra et menneske. Feilen viser at en destruktiv kommando ble forsøkt uten den nødvendige --yes-bekreftelsen.