Codex Deployment: Baştan Sona Dockup İş Akışı

Bir Codex deployment işlemi varsayımla değil, kanıtla sona ermelidir. Pratikteki zorluk, Codex'ten bir deploy komutu çalıştırmasını istemek değildir; agente tam hedefi belirleyen, terminal state oluşana kadar bekleyen, gerçek exit code'ları döndüren ve browser kullanmadan hata ayrıntılarını sunan bir interface sağlamaktır.

Dockup, bu workflow için deployment katmanıdır. CLI'ı, desteklenen her komutta Codex'e yapılandırılmış JSON sağlar; paketle birlikte gelen skill ise agente authenticate olmayı, service'leri keşfetmeyi, deploy etmeyi, teşhis koymayı ve destructive operation'lardan önce durmayı öğretir.

Codex CLI skill nasıl kurulur?

Önce CLI'ı global olarak kurun, ardından tek komutla skill installer'ı çalıştırın. Bu işlem canonical skill'i yazar ve hem Claude Code hem de Codex içine linkler:

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

Canonical skill ~/.agents/skills/dockup/ konumunda bulunur ve ~/.codex/skills/ içine symlink olarak eklenir. dockup-cli içinde gelir; dolayısıyla normal bir update, executable ile talimatlarını birlikte günceller:

dockup update

Bu version coupling, geniş bir command surface içinde önemlidir. Bir agent, eski bir prompt'ta yer aldı diye hatırladığı bir flag'i asla doğrudan çalıştırmamalıdır. Codex, command authority olarak paketlenmiş skill'i ve güncel Dockup CLI reference dokümanını kullanmalıdır.

Skill'lerin tasarım gerekçesi için agent skills vs MCP yazısına bakın.

Codex interactive terminal olmadan nasıl authenticate olur?

Bir sandbox veya CI job'ı browser tabanlı login işlemini tamamlayamayabilir. Process environment içinde bir token tanımlayın:

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

DOCKUP_TOKEN, local config file'a göre önceliklidir. whoami response'u, aktif credential'ın environment'tan mı yoksa config'ten mi geldiğini bildirir. Bu bilgi, eski bir local token ile CI token'ının birlikte bulunduğu yaygın durumda Codex'in teşhis koymasına yardımcı olur.

Token'ı bir infrastructure secret olarak ele alın. Token'ı AGENTS.md, SKILL.md, source control, repository'ye commit edilen command example'ları veya agent'ın final transcript'i içine koymayın. CI ortamında platformun encrypted secret store'unu kullanın ve değeri yalnızca deployment step'ine expose edin. Tam non-interactive pattern, CI/CD with DOCKUP_TOKEN yazısında ayrıntılı olarak açıklanmıştır.

Codex'e write access vermeden önce permission envelope'unu belirleyin. Başlangıç için makul kapsam; service discovery, deployment, log reading ve status check'lerini içerir. Database deletion, service destruction, team changes ve config pruning approval-gated olarak kalmalıdır.

Codex doğru service'i nasıl bulur veya oluşturur?

Discovery işlemini ilk operation haline getirin. Codex'ten “Payments API” ifadesini tahminî bir slug'a dönüştürmesini istemeyin:

dockup services --json

Her sonuç, project/service formatında tam bir target içerir. Codex bu değeri sonraki komutlara kopyalamalı ve özetinde geri döndürmelidir.

Service mevcut değilse Git'ten bir service oluşturun:

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

Bu komut service'i oluşturur, deploy eder, deployment çözülene kadar bekler ve working directory içine bir .dockup link'i yazar. Bir Dockerfile mevcutsa kullanılır; aksi takdirde Nixpacks otomatik build detection gerçekleştirir.

Codex session state'ini kaybettiğinde veya bir workflow network interruption sonrasında yeniden çalıştırıldığında service'leri yeniden keşfetmeli ve herhangi bir mutation yapmadan önce tam target değerini incelemelidir. Target zaten mevcutsa yeni bir create request göndermek yerine mevcut status ve deployment history üzerinden devam etmelidir.

Repository-first sequence'in tamamına Git repository to production yazısından ulaşabilirsiniz.

Codex deploy öncesinde configuration'ı nasıl hazırlamalı?

Codex'ten configuration'ı değiştirmeden önce mevcut service metadata'sını incelemesini isteyin:

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

Environment response'u key'leri ve isSecret marker'larını içerir; secret value'ları ise masked olarak kalır. Codex, ordinary variable'ları ve secret'ları birbirinden ayrı şekilde ekleyebilir:

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'ını asla dockup.yaml içine koymayın; manifest, review edilebilir plain configuration için uygundur, credential'lar için değil. Mevcut secret variable'lar config-as-code workflow'u tarafından overwrite edilmez veya prune edilmez.

Biliniyorsa service'in listening port'unu ve readiness check'ini yapılandırın:

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

Bir readiness gate, production verification'ın anlamlı olmasını sağlar. Platform blue-green deployment gerçekleştirir ve yalnızca yeni version gate'i karşıladıktan sonra traffic'i yönlendirir.

Production verification terminal state'i nasıl doğrular?

Mevcut bir service için tek bir komut kullanın:

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

Explicit timeout, default değer olan 900 saniyeyle eşleşir ve workflow niyetini görünür kılar. Exit 0, deployment'ın başarılı olduğu anlamına gelir. deploy_failed ile birlikte gelen non-zero result, build veya deploy işleminin failure'a ulaştığını gösterir. deploy_timeout, wait period sona erdiğinde operation'ın hâlâ non-terminal olduğunu belirtir.

Doğru Codex branching logic, process status'a dayanır:

Result	Codex action
Exit 0, status:"success"	Health, uptime ve security verification'a devam et
deploy_failed	Build log'larını oku ve ilk actionable error'ı belirle
deploy_timeout	Belirsizliği bildir; status'u incele veya gerekçelendirilmiş bir timeout ile retry et
not_logged_in	Dur ve geçerli bir token iste
needs_confirm	Dur ve human approval iste

Başarılı bir Codex deployment sonrasında gözlemlenebilir kanıt toplayın:

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

Uptime check'leri her dakika çalışır ve p95 gibi response-time istatistiklerini içerir. Security sonuçlarında image CVE'leri ve configuration check'leri yer alır. Bu sinyaller business correctness'ı kanıtlamaz; bu nedenle mevcutsa Codex repository'nin kendi smoke test'lerini de çalıştırmalıdır.

Codex başarısız bir release'i nasıl teşhis etmeli ve kurtarmalı?

Build error'ları ile runtime error'ları farklı log'lar gerektirir. Deployment çalışabilir bir container'a ulaşmadıysa latest build output'u kullanın:

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

Image build edilmiş ancak application crash olmuş, yanlış port'a bind olmuş veya startup sonrasında failure yaşamışsa runtime log'larını kullanın:

dockup logs production/payments-api --json

Follow mode, uzun süren bir build sırasında kullanışlıdır:

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

JSON mode'da follow output NDJSON'dur; bu sayede Codex her batch'i gelir gelmez işleyebilir. Stream, terminal deployment state'inde sona erer ve gerçek failure exit code'unu korur.

Recovery, tahminî bir rollback target'ıyla değil history ile başlar:

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

Codex bilinen başarılı bir deployment'ı belirlemeli, seçilen ID'yi belirtmeli ve yeniden çalıştırmadan önce failure evidence'ı korumalıdır. Status ve timestamp'leri doğrulamadan asla “ikinci item”ı seçmemelidir.

Kullanışlı bir final report yedi alan içerir: target, branch veya commit, deployment ID, exit code, terminal status, production URL ve follow-up actions. Bu format, her Codex deployment'ın bir kişi veya sonraki bir automation step'i tarafından review edilebilmesini sağlar.

Kısa bir verification script'i

Bu shell pattern'i deployment ve diagnosis işlemlerini tek bir şeffaf control flow içinde tutar:

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 bir success sentence için grep yapmaz. CLI exit code'una güvenir, deployment JSON'unu saklar ve production success state'ine ulaşmadığında calling job'ı fail eder.

Retry işlemlerini görünmez değil, gözlemlenebilir yapın

Agent session'ları, bir operation başladıktan sonra ancak result transcript'e ulaşmadan önce kesilebilir. Sonraki Codex run'ı her mutation'ı körü körüne tekrarlamamalıdır. Service'i yeniden keşfetmeli, latest deployment'ı incelemeli ve önceki operation'ın terminal state'e ulaşıp ulaşmadığını belirlemelidir.

Bir Codex deployment runbook'u, command'ları tekrar edilmesi güvenli, yalnızca inspection sonrasında güvenli veya approval-gated olarak sınıflandırmalıdır. Read operation'ları tekrar etmek güvenlidir. Service creation öncesinde discovery gerekir. Yeni bir deploy yeni bir production event'idir ve bu şekilde kaydedilmelidir. Pruning ve diğer destructive work'ler human decision olarak kalır.

Platform verification'ı application verification'dan ayırın

Dockup, build'in tamamlandığını, container'ın ready hale geldiğini ve minute-level probe'ların public service'i gözlemlediğini kanıtlayabilir. Codex yine de application-specific check'leri çalıştırmalıdır: public health endpoint'i, authenticated test request'i veya customer data'yı değiştirmeyen repository-provided smoke test.

Final result her iki katmanı da belirtmelidir. “Platform deployment başarılı” ve “application smoke test başarılı” farklı iddialardır. Yalnızca ilk kanıt mevcutsa Codex bunu belirtmeli, belirsizliği green check mark'a dönüştürmemelidir.

Automation öncesinde kurulu command surface'i doğrulayın

Reusable bir Codex task'ı, dockup skill status --json komutunu kontrol ederek ve daha az bilinen bir option'a bağlıysa güncel CLI reference'ı açarak başlamalıdır. Bu, session'ın başka bir release için yazılmış bir example'ı takip etmesini önler.

Bu check, fresh global npm installation'ının developer laptop'ından farklı olabileceği ephemeral runner'larda özellikle kullanışlıdır. Codex, ilk production write işlemini gerçekleştirmeden önce skill state'ini raporlayabilir ve deployment record'unu reproducible hale getirebilir.

Final handoff

Kanıtları saklayın.

Target'ı görünür tutun

Final report içinde exact service target'ı döndürün.

Source kararını koruyun

Dockup'ın repository Dockerfile'ını mı yoksa Nixpacks'i mi kullandığını kaydedin. Bu bilgi, sonraki Codex session'ının doğru build log'unu seçmesine yardımcı olur ve source-layout değişikliğinin platform incident'ı sanılmasını önler.

Ayrıca automatic deploy on push özelliğinin etkin olup olmadığını da kaydedin. Aksi takdirde manual agent release ile push-triggered release çakışabilir ve aynı investigation'dan iki production event'i oluşabilir.

Workflow'u production'a taşıyın

İlk Codex deployment'ını disposable veya düşük riskli bir service üzerinde çalıştırın, ardından aynı doğrulanmış command contract'ını production'a taşıyın.

npm install -g dockup-cli
dockup skill install

İlk komut CLI'ı kurar. İkinci komut, Claude Code ve Codex için eşleşen Dockup skill'ini kurar. app.dockup.ai adresinden ücretsiz başlayın.

FAQ

Codex yeni bir Git repository'sini tek komutla deploy edebilir mi?

Evet. dockup create, --deploy, --wait ve --link ile kullanıldığında service'i oluşturabilir, deploy edebilir, terminal result'ı bekleyebilir ve mevcut directory'yi linkleyebilir.

Codex Dockup'a nasıl authenticate olmalı?

Process environment içinde DOCKUP_TOKEN kullanın ve bunu dockup whoami --json ile doğrulayın. Bu yöntem sandbox'larda ve CI ortamında interactive browser login gereksinimini ortadan kaldırır.

Bir Codex deployment'ın başarılı olduğunu ne kanıtlar?

Deploy command'ı --wait ile çalıştırıldıktan sonra exit 0 vermeli ve JSON çıktısı başarılı bir terminal status bildirmelidir. Ardından status, uptime ve application smoke check'lerini çalıştırın.

Codex Dockup'tan production secret'larını okuyabilir mi?

Hayır. Secret value'ları output'ta masked olarak gösterilir. Codex bir secret'ı set edebilir veya replace edebilir; ancak configuration listelenirken saklanan değeri alamaz.

Codex needs_confirm ile karşılaştığında ne yapmalı?

Durmalı ve explicit human approval istemelidir. Bu error, gerekli --yes confirmation'ı olmadan destructive bir command çalıştırılmaya çalışıldığını gösterir.