What do you need help with?

Sandbox Environments in ALM


Using Sandbox Environments in Application Lifecycle Management

Production: This is the main environment for business transactions, and should be maintained in a pristine state. Refreshes are only available from production into the sandboxes. Therefore your code and configuration changes are “swimming upstream” – trying to migrate successfully to the production environment from the lower sub-prod environments.

Developer Environments: Each developer needs a dedicated sandbox to build his feature. Typically these environments are Developer Sandboxes. The maintenance of this environment is usually done by the developer.
If you are customizing an application, we recommend to install the application in production and refresh the developer org to get access to the application.

Managed Project Environments: Each project should have an environment that can isolate changes from other projects. Many projects may be occurring at the same time and on different release schedules. These managed environments are the holding grounds for project features that are not ready for release. The functional testing of the feature or the project should happen in this environment.
After this feature has been deployed to production, this org should be refreshed.

System Integration: This environment should be used for parallel projects. Code coverage should be ensured in this org to ensure that the overall system is healthy. Automated apex tests should be continually run in this environment to ensure a project has not broken something. The refresh schedule for this environment should be aligned with overall sprint cycle schedule. For ex- ample, if you have a 2-week sprint cycle, it is recommended to refresh this org every two weeks.

User Acceptance Testing: The users should test their new features and projects in this environment. The end-to-end testing of the business processes should be done in this environment. It is recommended to use a full-copy sandbox so that the business users can test on a real data set.

Stage: The purpose of this environment is to ensure that your production deployments will not fail. It is recommended to refresh this environment prior to each production deployment.

The purpose of this environment is to ensure that there are no code errors, hence this could be a developer Pro environment.

Training Environment: Depending on the training schedules, this environment should have “pre-prod” changes or it could be a refresh from production, if the changes are already deployed to production.

Reference Environment strategy

This is an example of the reference implementation model.


Print Friendly and PDF
Was this article helpful?
0 out of 0 found this helpful