Change Management Process (Part 1)

Salesforce

Have you ever made a change in Production? How many times has that change caused more issues than you fixed? You’re not alone, many individuals have reached this point of frustration. Yet, I am here to tell you that there is a process that can help prevent this! Creating a change management process can be broken down into 3 parts: Environments, Deployment, and the Process.

First up is the Environments that you might want to consider using for development. Depending on your edition of Salesforce you will have different options to consider. For example, the Enterprise edition of Salesforce gets only a single developer sandbox, whereas the Unlimited edition gets 15 developer sandboxes, 5 Developer Pro sandboxes, and 1 full sandbox. However, you can always purchase additional sandboxes. Currently Salesforce allows organizations to purchase additional Developer Pro, Partial Copy, or Full sandboxes. You might ask what the difference is between these types of sandboxes. Here are a few quick differences:

• Developer Pro
  • Refresh Interval: 1 day
  • Data Storage: 1 GB
  • File Storage: 1 GB
  • Metadata Only copied
• Partial Copy
  • Refresh Interval: 5 days
  • Data Storage: 5 GB
  • File Storage: 5 GB
  • Metadata and sample data copied
• Full
  • Refresh Interval: 29 days
  • Data Storage: Same as Production
  • File Storage: Same as Production
  • Metadata and all data copied

When you purchase one of the above sandboxes as an addition to what your organization currently has, you will receive additional developer sandboxes.

The structure of the sandboxes can be very simple to very complex depending upon your needs. I would recommend starting simple and expanding the structure as needed. Below is an example of a structure using four developer sandboxes and one developer pro sandbox. This structure keeps all of the sandboxes in sync with minimal refreshes.

Environments

• Code (Developer Edition)
  • This environment should be used for developers only.
  • This environment is to be where the programmatic solutions are developed.
  • Once code and required test classes have been created they can be moved to Development environment using change sets.
• Development (Developer Edition)
  • This environment should be used for creation of declarative solutions and additional verification of programmatic solutions.
  • Once solutions have been verified, changes should be moved to the Sandbox environment using change sets when possible.
• Sandbox (Developer Pro Edition)
  • This environment will be used for verification of solutions only no development should take place in this environment.
  • Once solutions have been verified, changes will be moved to Production using change sets when possible.
  • If there are any Integrations this would be the environment to test them in before moving the changes to Production.
• Hotfix (Developer Edition)
  • This environment should be refreshed before each set of changes are moved to production to have a backup of production in case there are any issues with the new changes.
  • There should be no work done in this environment, it is strictly for a backup of production before making changes.
• Major Release (Developer Edition)
  • This environment will be used for the Major releases
  • All code and declarative work will happen here as well for this major release

Once the release is ready it should be deployed to SBX for QA testing and then moved to production.

Now that we have covered the environment setup, the next steps are to develop the solution deployment and the process to go along with it. However, that will have to wait till next time

by