This model is a framework for how we think a best-practice release flow should integrate with version control. Of course, each business is different, and the model is designed to provide flexibility for teams to customize to suit their specific regulatory or business needs.
Consider it a starting point for developing your own DevOps process, and not a prescribed format that must be adhered to.
The DevOps model
This model is taken using excerpts from our whitepaper on git-based development. For more detail on any of these steps, consult the whitepaper.
Step 1 — Environment setup
Create a new developer sandbox or refresh an existing one from your master branch or production environment. This gives all developers a consistent starting point.
Create a new branch from master on the developer's local machine. Name it descriptively, either referencing your user story or the bug being fixed (e.g.
feature/userstoryorbugfix/fix-account-visibility-for-sales-profile).Publish the branch to your central repository.
Step 2 — Development
Developers work on the changes in their developer sandboxes, or use a local IDE and a sandbox. Tests should be run locally on a regular basis to check for regressions.
Changes are periodically committed to their branch and published to the central repository. Publishing the branch gives visibility to other developers and provides backup in the event of local data loss.
When the changes are complete, a pull request is opened to merge the branch back into master. All changes must be reviewed by at least one assignee prior to merging. This helps to maintain code quality and catch bugs. The notes and feedback during a pull request also produce an audit trail if the changes need to be revisited in the future.
After review, the branch is merged into master.
Step 3 — Release
A CI job detects the new changes in master, and automatically deploys them out to an integration testing sandbox (usually a partial copy) for rapid testing.
Any test failures or changes via user feedback should be fixed, committed, and submitted using a pull request.
After passing integration testing, deploy the changes from master to UAT / QA environments in turn. The number of environments between integration testing and production will vary based on company and team size, but your final pre-production environment should at the very least be a partial copy sandbox that's in sync with production.
After final approval, the changes are pushed from master to production. Releases to production should always be a manual process to ensure appropriate oversight.
Deployment reports from the final release should be stored with any user stories, to add an extra level of audit trail for business owners.
Dealing with hotfixes
No matter how good the release model is, changes will sometimes be made outside the defined process. An urgent bug fix in the production org may need to be rushed through to release, or an admin may make a small configuration change in a UAT org through the Salesforce UI.
The ability for users to rapidly make these small changes is one of the strengths of Salesforce, and it allows businesses to respond to user requests more quickly than is typically possible with other platforms.
Rather than attempting to stop users from working this way, a good release process should have an effective way of quickly identifying these hotfixes and incorporating them back into the defined development model. Tracking hotfixes in this way avoids them being overwritten during the next scheduled feature release.
Common alterations to the model
Much like the default Salesforce orgs, this model is a starting point for git-based development. Below are a couple of the common changes we've seen teams make:
Adding a second
integrationbranch alongside master. This branch points to the integration environment via a CI job. Once the changes have been verified in the integration environment, the dev branch is merged into master, and a deployment is then run from master to production.Using a manual CI job to push into production. This utilizes a pre-configured deployment plan to be executed with the click of a button, rather than running a manual deployment to speed up the process a little.
Want to learn more?
Read our whitepaper on version control for Salesforce for more information about this process.