Posted by Meryl Flynn
Your company has just completed their initial implementation of Salesforce.com. You’ve been tasked with the challenge of setting up and managing environments to allow for new functionality to be built, tested and deployed down into your Production environment. Where do I start? You might ask.
A first step in understanding how to set up environments for your Salesforce.com instance is to understand the different types of environments available. Salesforce.com has three different types of environments:
- Production Environments: This is your live environment where your business users are actively logging in and using the system.
- Development Environments: These environments allow you to customize existing and build new applications without affecting anything in your Production environment. Salesforce.com has two types of Development environments – ‘Sandboxes’ and ‘Developer edition environments.’ A Developer edition is a free copy of your Production environment with less data and storage. Sandboxes allow you to replicate an exact copy of your Production environment to include all of the data.
- Test Environments: These can be used for testing new functionality prior to releasing it into your Production environment.
You can have many development and testing environments enabled for your organization in addition to your Production Environment. Managing these environments and the migration and testing of your functionality successfully is not quite as straight forward as just enabling the environments themselves. This brings me to the next question that I wanted to address: ‘If I have multiple different types of environments enabled, how should I set them up to successfully manage the migration and testing of new functionality moving forward?
It is a common best practice to manage your ongoing development and testing in these environments by setting up a Deployment Schedule and Deployment Release Paths. Taking the time to set these up will have many benefits, including:
- Clear Communication of deployment releases to other team members working within the same Salesforce.com organization as you.
- Effective management of refreshes from Production into necessary environments in way that allows you to test your code and functionality against other functionality and code being built which will ultimately avoid functionality/code conflict.
If this sounds like an effective solution for you then read no further than the next few paragraphs to find out how you can set this up for your organization.
Setting a Deployment Schedule
Depending on the frequency, volume and priority of how soon your users want to see new functionality, you’ll want to set a recurring date for deploying new functionality into your Production environment. This is usually once or twice a month depending on the volume of functionality that needs to be migrated and the Priority of the functionality that needs to be deployed. Whatever that date may be, set it in stone by marking it on everyone’s calendars. Your work load every month or every couple of weeks should be focused on refining what needs to go into the next release and getting it ready to be deployed. Communicate the new changes coming via Release notes and no later than your scheduled recurring date should the new functionality be ready for your users to play with in their Production environment.
Defining a Deployment Release Path
Once you’ve defined your deployment schedule and you have a good grasp on how much functionality will need to be tested and deployed on a recurring basis, you should be ready to define your deployment release path. Defining a Deployment Release Path will allow you to create an infrastructure for migrating your functionality through necessary testing and training environments prior to deploying it into Production. Your deployment release path is going to depend entirely on the number of environments you have, the number of development projects that your company is executing at one time, the frequency of bug fixes and ad-hoc releases being deployed into your Production Environment and last but certainly not least - your IT departments and Change Management Teams policies and procedures.
Because every organization is vastly different, I’m going to use a sample scenario based on some of my prior experiences with managing environments within different organizations. I’m hoping to demonstrate how different types of environments can be set up with a Deployment Release path to meet the needs of ongoing development projects, bug fixes and ad-hoc functionality releases and the needs of an organizations IT and Change Management policies and procedures:
Overview:
I’m a Salesforce.com Development Manager working for ABC Solutions. I’m responsible for managing the development, testing and deployment of ad-hoc pieces of functionality and ongoing bug fixes within ABC Solutions’ Salesforce.com environment. I work alongside John Williams; who is responsible for managing the development, testing and deployment for larger, more complex projects within ABC Solutions’ Salesforce.com environment.
The need(s):
John and I each have our own development environment for managing the ongoing development of our teams’ functionality. It is Important to note here that John and I are working completely in Silo. If John and I were to both deploy our functionality to the Production environment tomorrow without first merging together our functionality and testing it in a single instance we might face a few challenges when our code reaches the Production environment. We must have a method in place to make sure that our functionality is tested in one single instance prior to deploying it to the Production environment. Our Change Management department requires that everything must pass at least one cycle of user acceptance testing prior to being deployed to the Production environment. They also require a training environment to train users on any new functionality released to the Production environment.
Our Solution:
Our Deployment Release Path into Production looks something like this:
As you can see from the diagram above, we have 6 environments enabled within our organization:
- Production Environment: This is our live environment where business users are actively logging in and using the system.
- UAT/Testing Environment: All functionality will be tested here prior to the final deployment to the Production Environment. This is a full copy Sandbox with all data copied from Production.
- Staging Environment: This will be leveraged for deploying both mine and John’s development functionality into a single instance to test it prior to deploying it to the UAT environment. This is a partial copy Sandbox with only a sample of the data copied over from Production.
- Dev Environment 1: This is John’s development environment. His team develops all of their functionality in here. This is a Developer Sandbox that copies the metadata from Production but no data is copied.
- Dev Environment 2: This is my development environment. My team develops all of their functionality in here. This is also a Developer Sandbox.
- Training environment: This is used for training users on new functionality that has been released into the Production environment.
Both mine and John’s downstream deployment cycle’s follow the same path:
- Metadata changes (new functionality) are migrated from the Developer Sandbox down into the Staging environment. Here the functionality is tested against the latest refreshed copy of the Production data.
- Once SIT/Stage testing is complete, the metadata is then migrated down to the UAT Sandbox for User Acceptance Testing.
- Once User Acceptance Testing is complete, the metadata is migrated down into the Production environment available for the use of our business users.
- Once all metadata is migrated to the Production environment, refreshes are made to all necessary Sandboxes. There is more information regarding refreshes in our Production Refresh Cycle below.
- The cycle starts again once more metadata is ready to be deployed from one or more of our Developer Sandboxes down to Production.
Refreshing our Sandboxes:
It is important to note that an environment refresh (complete copy and migration of an entire environments metadata and data) can only be achieved from your Production environment to a sandbox (not the other way around). Once we have completed the deployment of functionality to our Production environment, one of the first things we do is complete a refresh of all necessary environments to make sure they are all in sync with the latest and greatest copy of the Production metadata. Our Refresh from Production path looks something like this:
- To refresh one or more of your Sandboxes, go to Setup > Deploy > Sandboxes. Click ‘Refresh’ next to the Sandbox that you wish to deploy.
Note: To prevent losing any development work, be careful not to refresh your Production data over any new functionality that hasn’t been deployed.
Once the refresh of all environments is complete, we are ready to start another deployment cycle when new functionality is ready to be released.
Please note: The scenario and solution outlined above are to provide an example that can be leveraged to help you define your own deployment release path and schedule. When defining a Deployment Release Path and Schedule of your own, you will need to consider the different development cycles within your organization, the needs of your change management and IT teams and which environments will be necessary for use within your organization.
For more information on the different types of environments that the Force.com platform provides, please visit the following URL https://developer.salesforce.com/page/An_Introduction_to_Environments or contact your Buan consultant for more information.
References:
Developer Force: An Introduction to Environments:
https://developer.salesforce.com/page/An_Introduction_to_Environments