Plan requirement
| Subscription | Suite Growth or higher, Support Professional or higher |
| Access | Admin |
Keeping a record of what was deployed and when. The thing you want when something behaves oddly next month.
Review them
- Open Admin Center, then Account, then Sandbox, then Deployments.
- Read each deployment's source, destination, status and the date it last changed.
- Compare that against when the behaviour changed.
What it shows, and what it does not
Per deployment: source, destination, status, and the date it last changed. Status is one of Draft, Deploying, Deployed or Failed.
What it does not show is who did it. Check this before you rely on this page to settle a question about who changed what.
A deployment can be reverted
Before it changes anything, Zendesk saves a snapshot of the destination environment. A deployment that reached Deployed or Failed can then be reverted from its own menu.
So this page is not only a record of what happened. It is also the way back, which is a better position than reconstructing the previous configuration by hand.
The question it answers
"Something started going wrong around the eleventh." The deployment history either names the change or rules it out, and both are progress.
Without it, that question turns into reading every trigger.
Record the why separately
The history shows what changed. It does not say what problem you were solving or who asked, and that is what the next person needs.
One line per deployment, wherever your team keeps notes.
One change at a time
Three deployments in an afternoon means you cannot attribute an effect to any of them. Slower is genuinely faster once something is wrong.
Read it after any incident
Before investigating anything else, look at what was deployed recently. A surprising share of "Zendesk is behaving strangely" is a change somebody made and did not mention.
If several people deploy
The history will show you two changes landing close together, which is how conflicting work gets noticed. It will not tell you which of your colleagues to ask about them.
That is the practical reason to keep your own line per deployment. With one person deploying it is a nicety; with three it is the only record of who.
Comments
0 comments
Article is closed for comments.