After a kickoff call for a new project the other day, I asked the person working with me to go ahead and set up the Deployment Dictionary. ‘Deployment Dictionary?’ was the response. Me: ‘Yeah, you know, a deployment dictionary?’ Co-Worker: ‘Uhm, nope, whats that?’
The same week I had another conversation with a community member regarding backing up the metadata before deployment and they said, ‘that’s actually something I hadn’t considered doing.’
So with those two conversations, thought it would be helpful to share the lessons I’ve learned from deployments over the years. I don’t possess special deployment powers; I’ve made or witnessed enough mistakes over the years that I picked up a few tools…like the Farmer’s quote:
I’ve found the below practices help me manage the deployment process much better than in the past. Hope they are helpful for you as well and please share your own tips too!
1 – Backup all your Metadata
Most users have plenty of available developer sandboxes in their org so use them as a safety net. Before deploying your new project to production, spin up a Dev Sandbox so you have a full metadata backup of your org. If things get a little squirrelly during deployment and you want to see ‘the way it was’ before, you are covered.
2 – Backup all your data too!
The chances of your deployment breaking anything regarding your data are really slim…but I’ve seen it happen. Along with a production deployment of various process automation that updates records you might also do some cleanup of managed packages, record types, etc. Ex: I’ve seen a process builder apply the ‘else action’ because the picklist values the previous steps referenced were not deployed in the change set.
Skip the pain, just mash this button.
3 – Get Organized, make a Deployment Dictionary
A Deployment Dictionary should be part of all of your projects. I say this knowing I am horrible with the details and rolled my eyes every time a project lead would tell me say, ‘update the deployment guide before you sign off today…’ You can format your document however you want, no magic bullet here other than to HAVE ONE.
My personal approach is format an Excel Spreadsheet like the columns in the the Change Set building screen. This way when I’m building my change set, I can work right down the list to make sure I have everything. This also becomes super helpful for documentation & data dictionaries.
4 – HAVE A PLAN! Create a Deployment Guide
Some people have a very cavalier approach to deploying change sets; I used to be guilty of this however pain and suffering turns out to be quite the effective motivation for change. Days before deployment, as testing is being finalized, I start drafting my Deployment Guide.
First, I always go through the Deployment Dictionary and mark my tabs by color to make change set groupings and set the order of deployment.
- Group 1: Fields, Objects, List Views, Layouts, Pages, & Picklist Values are Marked in one color.
- Group 2: Templates, Folders, Custom Settings, CMDT, and any other Metadata that is not related to automation or code is in Group 2
- Group 3: Workflows & Components, Flow Definitions
- Grup 4: All VF & Apex
My Deployment Guide would take shape around these four change sets, with various steps and checks along the way. Here is an example of what the high-level steps of my guide would look like:
- Create Backup Sandbox
- Run Full Data Export – store in backup sandbox
- Push User Freeze Data Update
- Complete any metadata cleanup (objects, fields, packages, record types, fields, etc)
- Install App Exchange Packages
- Create Change Set 1 – Validate & Deploy
- Add in Picklist Values for existing picklists
- Run necessary data updates for new fields & picklist values
- Create Change Set 2 – Validate & Deploy
- Complete Immovable Metadata (Territory Management for example)
- Create Change Set 3 – Validate & Deploy
- Activate all flows, process builders, workflows
- Create Change Set 4 – Validate & Deploy
- Update any security & permission settings
- Test New Deployment, End-to-End Testing as each profile
Now that this outline is complete, I would fill in more details like the profiles to be tested, the objects where data needs updated, etc. This does not have to be encyclopedic, but should have a bullet point for each step that needs to take place. You’ll find that you are constantly remembering steps and things to add to your dictionary & guide; much better to be updating an excel spreadsheet than forgetting those items and having to build a 47th version of your change set.
5 – Save Time & Suffering with Change Set Helper
The standard method of building change sets in Salesforce is maddening. You can’t sort or filter fields, once you hit add you have to constantly go back to the previous window, and you spend an hour waiting for it to be ready in production only to encounter an error during validation.
Enter the Salesforce Change Set Helper Chrome Extension. It gives you super powers like Org Compare, Validate Helper, filter and sort functions, and much more. You are costing yourself a lot of time, effort, and pain if you are not using Change Set Helper.