Ανάπτυξη Codex: End-to-End ροή εργασίας στο Dockup

Μια ανάπτυξη Codex πρέπει να ολοκληρώνεται με τεκμήρια και όχι με υποθέσεις. Η πρακτική πρόκληση δεν είναι να ζητήσετε από το Codex να εκτελέσει μια εντολή deploy· είναι να δώσετε στον agent ένα interface που προσδιορίζει τον ακριβή στόχο, περιμένει μια terminal κατάσταση, επιστρέφει πραγματικούς κωδικούς εξόδου και εμφανίζει λεπτομέρειες αποτυχίας χωρίς browser.

Το Dockup είναι το deployment layer αυτής της ροής εργασίας. Το CLI του παρέχει στο Codex δομημένο JSON για κάθε υποστηριζόμενη εντολή, ενώ το ενσωματωμένο skill μαθαίνει στον agent πώς να κάνει authentication, να εντοπίζει services, να εκτελεί deploy, να διαγιγνώσκει προβλήματα και να σταματά πριν από destructive operations.

Πώς εγκαθιστάτε το Codex CLI skill;

Εγκαταστήστε το CLI globally και στη συνέχεια εκτελέστε τον μοναδικό installer του skill. Γράφει το canonical skill και δημιουργεί links προς αυτό τόσο στο Claude Code όσο και στο Codex:

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

Το canonical skill βρίσκεται στο ~/.agents/skills/dockup/ και συνδέεται συμβολικά με το ~/.codex/skills/. Περιλαμβάνεται στο dockup-cli, επομένως μια κανονική ενημέρωση αλλάζει ταυτόχρονα το executable και τις οδηγίες του:

dockup update

Αυτή η σύζευξη εκδόσεων είναι σημαντική σε ένα μεγάλο command surface. Ένας agent δεν πρέπει ποτέ να εκτελεί μια flag που θυμάται απλώς επειδή εμφανιζόταν σε ένα παλιό prompt. Το Codex πρέπει να χρησιμοποιεί το packaged skill και την τρέχουσα αναφορά του Dockup CLI ως πηγή αλήθειας για τις εντολές.

Για το σκεπτικό σχεδιασμού πίσω από τα skills, δείτε το agent skills vs MCP.

Πώς κάνει authentication το Codex χωρίς interactive terminal;

Ένα sandbox ή ένα CI job ενδέχεται να μην μπορεί να ολοκληρώσει login μέσω browser. Ορίστε ένα token στο environment του process:

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

Το DOCKUP_TOKEN έχει προτεραιότητα έναντι του local config file. Η απόκριση του whoami αναφέρει αν το ενεργό credential προήλθε από το environment ή από το config, βοηθώντας το Codex να διαγνώσει τη συνηθισμένη περίπτωση όπου συνυπάρχουν ένα παλιό local token και ένα CI token.

Αντιμετωπίστε το token ως infrastructure secret. Μην το τοποθετείτε στα AGENTS.md, SKILL.md, στο source control, σε command examples που γίνονται commit στο repository ή στο final transcript του agent. Στο CI, χρησιμοποιήστε το encrypted secret store της πλατφόρμας και εκθέστε την τιμή μόνο στο deployment step. Ο πλήρης non-interactive τρόπος περιγράφεται αναλυτικά στο CI/CD με DOCKUP_TOKEN.

Πριν δώσετε στο Codex write access, καθορίστε το permission envelope του. Ένα λογικό αρχικό scope περιλαμβάνει service discovery, deployment, ανάγνωση logs και status checks. Η διαγραφή database, η καταστροφή service, οι αλλαγές ομάδων και το config pruning πρέπει να παραμείνουν gated από approval.

Πώς εντοπίζει ή δημιουργεί το Codex το σωστό service;

Κάντε το discovery την πρώτη operation. Μην ζητάτε από το Codex να μετατρέψει το “Payments API” σε ένα slug που έχει υποθέσει:

dockup services --json

Κάθε αποτέλεσμα περιλαμβάνει ένα ακριβές target στη μορφή project/service. Το Codex πρέπει να αντιγράφει αυτή την τιμή στις επόμενες εντολές και να την επιστρέφει στη σύνοψή του.

Όταν δεν υπάρχει service, δημιουργήστε ένα από Git:

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

Η εντολή δημιουργεί το service, εκτελεί deploy, περιμένει μέχρι να ολοκληρωθεί το deployment και γράφει ένα link .dockup στον working directory. Όταν υπάρχει Dockerfile, χρησιμοποιείται αυτό· διαφορετικά, το Nixpacks πραγματοποιεί automatic build detection.

Όταν το Codex χάσει το session state ή όταν μια ροή εργασίας εκτελεστεί ξανά μετά από network interruption, πρέπει να κάνει ξανά discovery των services και να ελέγξει τον ακριβή στόχο πριν τροποποιήσει οτιδήποτε. Αν ο στόχος υπάρχει ήδη, συνεχίστε από το status και το deployment history του αντί να εκδώσετε νέο create request.

Η πλήρης repository-first ακολουθία είναι διαθέσιμη στο Από Git repository σε production.

Πώς πρέπει να προετοιμάζει το configuration το Codex πριν από το deploy;

Ζητήστε από το Codex να ελέγξει τα τρέχοντα service metadata πριν τα αλλάξει:

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

Η απόκριση του environment περιλαμβάνει keys και markers isSecret, ενώ οι secret values παραμένουν masked. Το Codex μπορεί να προσθέτει ordinary 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 είναι κατάλληλο για plain configuration που μπορεί να ελεγχθεί, όχι για credentials. Τα υπάρχοντα secret variables δεν αντικαθίστανται ούτε γίνονται 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. Η πλατφόρμα εκτελεί blue-green deployment και δρομολογεί traffic μόνο αφού η νέα έκδοση ικανοποιήσει το gate.

Πώς επιβεβαιώνει η production verification την terminal κατάσταση;

Για ένα υπάρχον service, χρησιμοποιήστε μία εντολή:

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

Το explicit timeout αντιστοιχεί στα προεπιλεγμένα 900 δευτερόλεπτα και κάνει εμφανή την πρόθεση της ροής εργασίας. Το exit 0 σημαίνει ότι το deployment ολοκληρώθηκε επιτυχώς. Ένα non-zero αποτέλεσμα με deploy_failed σημαίνει ότι το build ή το deploy απέτυχε. Το deploy_timeout σημαίνει ότι η operation δεν είχε φτάσει ακόμη σε terminal κατάσταση όταν έληξε η περίοδος αναμονής.

Η σωστή branching logic του Codex βασίζεται στο process status:

Αποτέλεσμα	Ενέργεια Codex
Exit 0, status:"success"	Συνεχίστε σε health, uptime και security verification
deploy_failed	Διαβάστε τα build logs και εντοπίστε το πρώτο actionable error
deploy_timeout	Αναφέρετε την αβεβαιότητα· ελέγξτε το status ή επαναλάβετε με αιτιολογημένο timeout
not_logged_in	Σταματήστε και ζητήστε έγκυρο token
needs_confirm	Σταματήστε και ζητήστε ανθρώπινη έγκριση

Μετά από μια επιτυχημένη ανάπτυξη Codex, συλλέξτε observable evidence:

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

Τα uptime checks εκτελούνται κάθε λεπτό και περιλαμβάνουν στατιστικά χρόνου απόκρισης, όπως το p95. Τα security results περιλαμβάνουν image CVEs και configuration checks. Αυτά τα signals δεν αποδεικνύουν την ορθότητα του business logic, επομένως το Codex πρέπει επίσης να εκτελεί τα smoke tests του repository, όταν είναι διαθέσιμα.

Πώς πρέπει να διαγιγνώσκει και να επαναφέρει το Codex μια αποτυχημένη release;

Τα build errors και τα runtime errors απαιτούν διαφορετικά logs. Χρησιμοποιήστε το πιο πρόσφατο build output όταν το deployment δεν έφτασε ποτέ σε runnable container:

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

Χρησιμοποιήστε runtime logs όταν το image έγινε build αλλά η εφαρμογή καταρρέει, κάνει 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 και να διατηρεί τα failure evidence πριν το εκτελέσει ξανά. Δεν πρέπει ποτέ να επιλέγει «το δεύτερο στοιχείο» χωρίς να επαληθεύσει το status και τα timestamps.

Μια χρήσιμη τελική αναφορά έχει επτά πεδία: target, branch ή commit, deployment ID, exit code, terminal status, production URL και follow-up actions. Αυτή η μορφή κάνει κάθε ανάπτυξη Codex ελέγξιμη από άνθρωπο ή από επόμενο automation step.

Ένα σύντομο 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 δεν αναζητά με grep μια φράση επιτυχίας. Εμπιστεύεται το exit code του CLI, διατηρεί το deployment JSON και αποτυγχάνει το calling job όταν το production δεν έφτασε σε επιτυχή κατάσταση.

Κάντε τα retries observable αντί για αόρατα

Τα agent sessions μπορεί να διακοπούν αφού ξεκινήσει μια operation αλλά πριν φτάσει το αποτέλεσμά της στο transcript. Η επόμενη εκτέλεση του Codex δεν πρέπει να επαναλαμβάνει τυφλά κάθε mutation. Πρέπει να εντοπίζει ξανά το service, να ελέγχει το πιο πρόσφατο deployment και να διαπιστώνει αν η προηγούμενη operation έφτασε σε terminal κατάσταση.

Ένα runbook ανάπτυξης Codex πρέπει να κατηγοριοποιεί τις εντολές ως ασφαλείς για επανάληψη, ασφαλείς μόνο μετά από inspection ή gated από approval. Τα reads είναι ασφαλή για επανάληψη. Η δημιουργία service απαιτεί πρώτα discovery. Ένα νέο deploy είναι ένα νέο production event και πρέπει να καταγράφεται ως τέτοιο. Το pruning και κάθε άλλη destructive εργασία παραμένουν ανθρώπινες αποφάσεις.

Διαχωρίστε την επαλήθευση πλατφόρμας από την επαλήθευση εφαρμογής

Το Dockup μπορεί να αποδείξει ότι ένα build ολοκληρώθηκε, ότι το container έγινε ready και ότι probes σε επίπεδο λεπτού παρατηρούν το public service. Το Codex πρέπει και πάλι να εκτελεί application-specific checks: ένα public health endpoint, ένα authenticated test request ή ένα smoke test του repository που δεν τροποποιεί δεδομένα πελατών.

Το τελικό αποτέλεσμα πρέπει να δηλώνει και τα δύο επίπεδα. Το «το platform deployment ολοκληρώθηκε επιτυχώς» και το «το application smoke test πέρασε» είναι διαφορετικοί ισχυρισμοί. Όταν είναι διαθέσιμο μόνο το πρώτο, το Codex πρέπει να το δηλώνει αντί να συμπυκνώνει την αβεβαιότητα σε ένα πράσινο check mark.

Επιβεβαιώστε το εγκατεστημένο command surface πριν από το automation

Μια επαναχρησιμοποιήσιμη εργασία Codex πρέπει να ξεκινά ελέγχοντας το dockup skill status --json και ανοίγοντας την τρέχουσα αναφορά CLI όταν εξαρτάται από μια λιγότερο γνωστή option. Έτσι αποτρέπεται το ενδεχόμενο ένα session να ακολουθήσει ένα παράδειγμα γραμμένο για άλλη release.

Ο έλεγχος είναι ιδιαίτερα χρήσιμος σε ephemeral runners, όπου μια νέα global npm installation μπορεί να διαφέρει από αυτήν σε laptop developer. Το Codex μπορεί να αναφέρει την κατάσταση του skill πριν εκτελέσει το πρώτο production write, κάνοντας το deployment record reproducible.

Τελική παράδοση

Διατηρήστε τα τεκμήρια.

Κρατήστε τον στόχο ορατό

Επιστρέψτε το ακριβές service target στην τελική αναφορά.

Διατηρήστε την απόφαση για την πηγή

Καταγράψτε αν το Dockup χρησιμοποίησε το Dockerfile του repository ή το Nixpacks. Αυτή η πληροφορία βοηθά το επόμενο session του Codex να επιλέξει το σωστό build log και αποτρέπει την εσφαλμένη αντιμετώπιση μιας αλλαγής στη διάταξη του source ως incident της πλατφόρμας.

Καταγράψτε επίσης αν είναι ενεργοποιημένο το automatic deploy on push. Διαφορετικά, μια manual agent release και μια push-triggered release μπορεί να επικαλυφθούν και να δημιουργήσουν δύο production events από την ίδια διερεύνηση.

Βάλτε τη ροή εργασίας σε production

Εκτελέστε την πρώτη ανάπτυξη Codex σε ένα disposable ή χαμηλού ρίσκου service και στη συνέχεια προωθήστε το ίδιο επαληθευμένο command contract σε production.

npm install -g dockup-cli
dockup skill install

Η πρώτη εντολή εγκαθιστά το CLI. Η δεύτερη εγκαθιστά το αντίστοιχο Dockup skill για Claude Code και Codex. Ξεκινήστε δωρεάν στο app.dockup.ai.

Συχνές ερωτήσεις

Μπορεί το Codex να κάνει deploy ένα νέο Git repository με μία εντολή;

Ναι. Το dockup create μπορεί να δημιουργήσει το service, να εκτελέσει deploy, να περιμένει το terminal result και να συνδέσει τον τρέχοντα directory όταν χρησιμοποιείται με τις --deploy, --wait και --link.

Πώς πρέπει να κάνει authentication το Codex στο Dockup;

Χρησιμοποιήστε το DOCKUP_TOKEN στο environment του process και επαληθεύστε το με dockup whoami --json. Έτσι αποφεύγεται το interactive browser login σε sandboxes και CI.

Τι αποδεικνύει ότι μια ανάπτυξη Codex ολοκληρώθηκε επιτυχώς;

Η εντολή deploy πρέπει να τερματίσει με exit 0 αφού εκτελεστεί με --wait, και το JSON της πρέπει να αναφέρει επιτυχημένο terminal status. Συνεχίστε με status, uptime και application smoke checks.

Μπορεί το Codex να διαβάσει production secrets από το Dockup;

Όχι. Οι secret values είναι masked στο output. Το Codex μπορεί να ορίσει ή να αντικαταστήσει ένα secret, αλλά δεν λαμβάνει την αποθηκευμένη τιμή όταν κάνει listing του configuration.

Τι πρέπει να κάνει το Codex με το needs_confirm;

Πρέπει να σταματήσει και να ζητήσει explicit human approval. Το error υποδεικνύει ότι επιχειρήθηκε destructive command χωρίς το απαιτούμενο --yes confirmation.