Deploying a configuration from one environment to another

Moving tested changes into production. The step where a careful process pays for itself.

Moving tested changes into production. The step where a careful process pays for itself.

Deploy it

1. Take a snapshot of production first.
2. Compare the two environments and read what will change.
3. Select what to deploy.
4. Deploy.
5. Verify in production with a real ticket.

Snapshot first, always

Step one, before anything else. It is the route back, and it takes a minute.

Deploy deliberately, not everything

A sandbox accumulates experiments: half-built triggers, a field somebody was trying out. Select what belongs to this change and leave the rest.

Read the list before confirming

The comparison tells you what will change in production. Anything on it you do not recognise is a reason to stop, not a detail to accept.

Mind the order of triggers

A trigger arriving in the wrong position behaves differently from the one you tested, and the deployment does not necessarily place it where you expect. Check the order afterwards.

Verify with a real ticket

Not by rereading the configuration. Send one that should match and one that should not, and watch what happens to each.

Deploy when it is quiet

Not before a peak, not at the end of the day, not on a Friday. If something is wrong you want time and a small queue.

Tell the team

Anything agents will see should be announced before it appears. A form that changes without warning generates tickets about your own change.

See also

• Managing configuration deployments
• Saving and managing configuration snapshots
• Comparing sandbox and production configurations