Your ALM Tool indicates that a new User-Story has to be implemented, you are assigned a new task:
“New Custom Fields need to be added to existing custom Objects, some Profile changes need to be applied and Apex classes have to be modified.”
The Sandbox you work in is not your own. Other members of your international team, working in different time zones, need to use it as well. But that does not worry you.
No one on your team can even remember the last time anyone has overwritten someone else’s code. The Version Control System (VCS) together with timestamps and User ID records prohibit that from happening.
This is guaranteed by your cloud hosted Salesforce Release Management Automation Suite which makes logical connections between SFDC – the user of the Salesforce Release Management Automation Suite – as well as all Version Control commits.
You log into your Sandbox and start working on your task. Once done, you save your changes, update your User Story – and, log out.
You do not prepare change sets. Nor will you be updating elaborate excel sheets, you definitely don’t move anything between Orgs manually, and you definitely won’t be caught writing scripts for functional test cases either.
Your work is done for the day. Go have a few drinks with your friends.
The next day.
Your inbox has a new email stating that your changes have been moved through your SIT and QA/UAT, instance without a problem. Currently, they are already being used by many happy end users in production:
Metadata Migration (120 types) – Successful
Static Code Analysis – Successful
Code Coverage – Successful
Full Permission Set Migration – Successful
Full Profiles Migration – Successful
Functional Tests – Successful
Child/Parent Relationship Migration – Successful
Data Migration – Successful
ALM User Story Update – Successful
How did that happen?
While you were asleep AutoRABIT which is your end to end Release Management Automaton Suite ran a comparison between your Sandbox and VC. Triggered by your User Story Update it fetched all your latest changes and did a commit to your SIT branch.
Once complete, a predefined Salesforce Continuous Delivery (CD) process executed the deployment from VCS (SIT Branch) into the Staging and Integration Instance (SIT). It checked on your Code Coverage, emailed all concerned parties about its success and generated a detailed report.
The success triggered the next CD process, by first committing the changes to the QA/UAT Branch in Version Control and then promoting the updated metadata into the QA/UAT Instance. There the Static Code Analysis of Apex classes has been performed. In addition it ran all Functional Test Scripts, emailed all concerned parties about its success and generated a detailed report.
After successfully completing these tasks AutoRABIT – your end to end Salesforce Release Management Automation Suite, once again committed the changes, this time to the Production Branch. Then the metadata was pushed into Production, emails went out to all concerned parties about its success, a detailed report was generated, and the ALM User Story updated.
If this sounds too good to be true I invite you, no dare you to contact us. email@example.com. You will be surprised…