In this series of blogs/whitepapers, we are going look at how MBOLT deployment automation suite can solve the everyday needs of sandbox synchronization. The inspiration for this use case lies in the absence of source control tools along with processes to migrate code and configuration across various salesforce environments. Typically, developers & business users work on Dev Environments, and the changes made by this group of people need to be migrated to QA sandbox and subsequently to UAT sandboxes. Finally, the verified and certified changes are deployed to the production environment. Customers who are not following the technology and process advances are still using either manual ways or change sets to transfer the changes to one environment to another. This manual or semi-manual process is not only erroneous, but also requires close co-ordination between teams. Developers are requested to stop their work during the actual deployments to enable choosing the right artefacts from the source or the development sandbox. Since there is no version control in place, implementing the tool along with the automation process pose great challenges as most of the changes are actually driven and executed by business users who are not tech-savvy and do not know how to use version control systems.
Considering all these problems and practical limitations of people who are involved, Salesforce IT owners are on a constant look out for a tool that will solve the problem without causing too much of change in processes for business users. Here, the MBOLT feature for Sandbox synchronization can solve this issue. Before diving deep into this feature, let’s find out some details of MBOLT.
How MBOLT Is a Beneficial Tool for Sandbox Synchronization:
MBOLT is a collection of tools & strategies designed to help the implementation of Salesforce DevOps tooling & process. MBOLT contains a next generation deployment automation framework that will allow one-click deployment across all Salesforce environments. The MBOLT toolset also provides best practices around the Salesforce sandbox management strategy that includes optimized sandbox usage for specific use based on the size, sandbox cost optimization, sandbox refresh calendars etc. MBOLT also contain two important tools to ensure code quality. These two tools are Static Code Analysis for Salesforce and Regression Automation Framework to automate regression testing which is time-consuming.
One of features of MBOLT that solves the problem which has been discussed above is sandbox synchronization. Using this feature, a deployer can choose the source and target sandbox and a few more specific details such as the kind of code/configuration that needs to move across the sandbox.
The above screenshot shows how MBOLT can be launched by specifying the source and target sandboxes, along with other build settings.
MBOLT will take care of rest. It will pull the code and configuration from the source sandbox, check in the artefacts to the source control system and then deploy changes to the target sandbox with a single click.
The above screenshot shows how MBOLT pulls the source and artifacts from the source sandbox.
The above screenshot shows that MBOLT has pushed the code to GIT (or choice of Source Control tool) and deployed the code & configuration to the target sandbox.
The advantage that is offered by this approach is that, since MBOLT works behind the scenes, business users who are busy making functional changes to source sandbox are not required to follow a separate technical deployment process. This will also add source control capabilities in the whole engineering process followed by the team.
Some of the other features that are available with MBOLT tooling are:
- Retrieve code & configurations from Dev sandbox
- Migration of code & configurations across the sandbox
- Compare sandbox code & configurations
- Post refresh configurations of the sandbox
- Post refresh code deployment on the sandbox
- Push code to SCM from Dev sandbox
- Delta (change) ONLY deployments
- Nightly Code Coverage Report