Develop, Test, Deploy, Refresh, Success!

You’re an Awesome Admin or a Rockstar Developer. You have worked your magic yet again creating your latest masterpiece in your Salesforce sandbox. You sit there and admire your work in all its beauty, testing finished the time has now arrived - a Production deployment. 

You double check your change set, all is there… this is going to be absolutely amazing! - you press deploy and sit back in anticipation as you watch the ‘green donut of joy’ tick through. 6 components deployed; 10 components deployed. Suddenly, joy turns into despair… this cannot be? Deployment failed fills your eyes as you break into a sweat. What is this validation rule? What do you mean this field I have referenced in my code does not exist? WHY IS MY APEX UNIT TEST FAILING?!

Sandboxes allow you to develop, test and ensure new processes meet your exacting requirements before you roll this out in production. They alleviate risk and impact to day to day operations. They’re FANTASTIC! 

However, Sandboxes are also there to allow you to accurately develop in the comfort that, once you have tested and are happy all is working, everything can be deployed to production in its final working form. An outdated sandbox that has not been refreshed in a few months however can be the difference between the click of a button and many hours of rework.

How does this happen? Well its quite simple really - A sandbox is a snapshot of your production org at the time it was created. With time things can get a bit messy and lose alignment with numerous developers and admins constantly making changes. This could be anything from creating validation rules, changing page layouts and creating/deleting fields in Production without retrospectively adding these to your sandboxes, to trying out fancy flows and pretty process builders in Sandboxes that affect automation which never make it to Production. Before you know if you could be looking at two completely different looking Orgs which can lead to deployment failures!

A simple resolution? Regularly refresh your Sandboxes!

Refreshing your sandbox means you have the most accurate copy of your live environment and reduces the risk of nasty surprises when deployment day arrives. Of course, planning is essential to ensure this process doesn’t become counter-intuitive:

1. Timing is everything!

When a sandbox is refreshed, any development in progress will be overwritten. It is essential that any approved development or configuration pieces on the sandbox are moved to your production environment before it is lost. Don’t make the mistake of running your refresh in the middle of development or testing!

2. Backup your data!

Always make a backup of your data, settings and metadata. Usually as part of testing you have created or made changes to settings or records for testing and you may not remember the changes you made when refresh time comes! – time spent here can save hours of headaches figuring out what is missing post refresh!

3. Get your Sandbox ready for action!

It is important to ensure any information now in your sandbox doesn’t affect your production processes. Tasks such as ensuring email deliverability is turned off, update any live URLs to their test counterparts, update relevant users’ information so they can access the sandbox and restore any test data you need is the first port of call before embarking on your next adventure.

By sticking to regular refreshes and following these tips you will always be ready for action! Spending just a few hours every couple of months can keep those green donuts of joy ticking strong and beat the botched deployments once and for all!