devops trained
each arrow from source to observed behavior needs its own evidence.
mental model
source -> built artifact -> platform revision -> reachable route -> observed behavior. each arrow needs its own evidence.
examples
platform_deploycurl --fail --show-error --location "$release_url/health"
use the platform's native deploy command in place of platform_deploy; retain its release url and revision.
best practices
- let committed platform config choose the platform; do not use a generic price ranking.
- release to preview/staging first where supported, then promote under the project contract.
- record release id, target, time, route probe, and rollback path without secrets.
strengths
native platform clis make release and revision identity observable. containers and kubernetes make runtime state explicit when their manifests are owned.
weaknesses / pain points
local tools cannot prove account access, dns, production behavior, or an authenticated runtime. each platform has different environment and rollback semantics.
gotchas
a command exit code can precede a failed build, unavailable custom domain, or failing application route. a 200 response can still be an unauthenticated fallback page.
known bugs
no version-specific defect was observed. recheck the selected platform changelog before adopting a workaround.
troubleshooting
| symptom | root cause | fix |
|---|---|---|
| deploy succeeds but app fails | command acceptance confused with runtime proof | inspect release logs and probe the intended route |
| wrong environment changed | target inferred from local defaults | state account, environment, and revision before mutation |
| rollback is unclear | release identity was not retained | record platform revision/url and native rollback command |
practiced cases
- a local tool check found vercel 53.3.2, wrangler 4.79.0, railway 5.26.1, and docker 29.4.0 installed. no account was selected and no deployment was attempted, so this is local-tool evidence only.