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.com you will have different options to consider. For example, the Enterprise edition of salesforce.com 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.com 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.

Dev_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.

Written by Matt Smelser, Developer / Service Cloud Expert at Demand Chain Systems

Matt is highly skilled in enterprise software implementations, identification of business requirements, team leadership, and project management and brings more than seven years of experience to the team. At Demand Chain Systems, Matt is responsible for all aspects of new and existing client engagements including pre sales engineering, strategy creation, requirement gathering, process engineering, system design and integration, testing, data migration, training and go-live support. 

For more information read: Salesforce.com Change Management Process (Part 2)

 

Facebooktwittergoogle_plusredditpinterestlinkedinby feather
Facebooktwitterlinkedinby feather

No Comment

Comments are closed.

You may also like

Lube-Tech

Case Study: Lubrication Technologies Solution: Salesforce Sales Cloud Lubrication Technologies, Inc. (Lube-Tech) is an innovative lubricants ...
Read More
Industrial Turf Equipment

Case Study: Industrial Turf Equipment Solution: Salesforce Service Cloud Global provider of innovative turf, landscape, rental ...
Read More