Deployment
deploy, deploys, deploymentsDefinitions
Putting a built version of the software onto an environment where it runs — distinct from a release, which is the moment users can reach it
Separating the two is what makes a feature flag worth having: the code deploys on Tuesday and releases on Thursday, and the risky half of that pair is already behind you. Most incidents attributed to releases are really deployment-shaped — a migration, a config value, a dependency that resolved differently in the build than on the laptop.
On this site, a push to a branch that a Railway environment watches: develop builds next, main builds production, and promotion between them is a pull request
Migrations run in preDeploy, not in the start command, so a failed migration aborts the deploy and leaves the running version up — the deploy is the gate, and a half-migrated database never serves traffic. The practical consequence for a session: merging to develop is not shipping, and the thing to verify after a merge is next, not production.
Moving the code to where it runs. Users finding out is a separate event, and treating it as separate is most of what makes deploying boring.
Avoid: using deploy and release interchangeably in an incident review. The question when did it deploy and the question when could people see it have different answers, and the gap between them is usually where the cause is hiding.
On this site, deploying and releasing are two different steps. A merge to develop
deploys to next; production changes only on a promotion PR into main. A failed
migration never replaces what is running:
flowchart TD
PR[PR merged] --> D[develop]
D -->|Railway deploys| N[next]
D -->|promotion PR| M[main]
M -->|Railway deploys| P[production]
N -.- B
P -.- B
subgraph each [every deploy]
B[build] --> PD{preDeploy:<br/>migrations}
PD -->|ok| S[new version starts]
PD -->|fail| A[deploy aborts,<br/>old version stays up]
end