How Blue Canvas enables feature branches with our Virtual Packaging concept.
Salesforce teams are busy. At any given time there are multiple projects from multiple stakeholders across the business. And every project is complex and has multiple moving pieces. Business moves at an unpredictable pace so it can be hard to bring predictability to your Salesforce release management process.
To help with predictability, velocity, and measurement, most Agile software teams leverage source control and in particular feature branches. Feature branches allow teams to work on multiple work items or tickets in parallel. With feature branches you can stash your changes and switch contexts throughout your day. They are designed to make project management simpler and more effective.
However, as we’ve written at length, getting a proper Git flow to work with Salesforce can be a pain. And when you bring admins and BAs into the picture it gets even muddier. This means that getting to feature branching in the traditional Git flow is nearly impossible for most teams.
But it’s not necessary - there are other branching paradigms that work as powerful tools for complex project management. Blue Canvas has developed a new branching concept that actually works for Salesforce admins, BAs and developers without introducing complicated and expensive overhead like training to use new command-line based tools.
We do this with our concept of “Stories” which allow you to bundle changes into virtual packages that can be shipped around in multiple directions to multiple environments.
A story is many things. But you can basically think of it as a ticket or a work item in an ALM tool like JIRA or VSTS. It starts with a Title and Description of the work involved.
Because Blue Canvas also operates as a source control tool you can also leverage Git to pin various components to the ticket as you work. This allows you to create and maintain context in your org over time in a self-documenting way.
The story also has a lot of other associated metadata for organization and tracking such as a trail of comments and actions (great for Salesforce metadata code reviews and SOX auditing). It also includes information about where it was deployed from and to, when it was deployed, who made the deployment and who approved it.
Stories become the basic building block of changes to your Salesforce org.
For each change, you create a Story and give context about the work it will contain. This includes a Title and Description. Often, you’ll want to paste the URL to any tickets you have in external management systems (JIRA integration is on the roadmap let us know if you have requests!). The smaller the units of change the better because it allows you to be extra granular about changes.
Sometimes, developers or admins will create a single ticket and work on it end to end. Other times, they will create several at once for their sprint.
Blue Canvas allows you to create and manage these tickets as well as to save tickets as Drafts so that you can come back to it over time.
As you make changes in Salesforce as you normally would, Blue Canvas is listening in the background and committing those changes into a Git branch on your behalf. Each change is logged as a commit which can be viewed as a diff between other orgs. This makes deployment between orgs as simple as comparing Git diffs and issuing Pull Requests.
When a change to a component is ready to move up the deployment pipeline, you can quickly return to your Draft Story and pin the changes like so:
You can filter for components and search on various different levels.
Pinning changes to your Stories is a core value prop of Blue Canvas as it allows you to associate the what with the why. The Story contains the reasoning for the change as well as the code review associated with it. It also contains the actual code that was update which allows you to document your business process in real time. So in two years if you want to understand why a Class was created or altered, you can see the logic behind it. This can reduce technical debt and keep your Salesforce org in good health.
When you are ready you can submit your story for validation and code review. At this point you can set the level of tests you want to run, and can even specify which tests you want to include.
The Story can now be found on your list of Open Stories with its status. The Story now has a list of components pinned to it, a build status (i.e. did it validate successfully), a test report if you elected to run tests, and a comments section. Other team members can look at the test reports and Git diffs included in this virtual package of sorts and give their feedback.
If it passes code review and validation, it can be Deployed. Blue Canvas offers multiple permission types to customize who is allowed to approve deployments and to where.
Once it’s been deployed you’ll see it on your list of previous Deployments.
For any given release you may have multiple stories. Again, this is where the concept of feature branching or virtual packaging comes in. When it’s time to do a larger release to production at the end of a sprint, Blue Canvas allows you to select multiple stories and pin them to a release just as you did with components for your individual stories.
You can bundle the stories and move them other environments like Production or UAT:
You can even clone stories and deploy them to other sandboxes or downstream after a production release to ensure that your sandbox metadata is synced with production.
Leveraging Blue Canvas for release management makes organization of releases much simpler. Instead of juggling spreadsheets you can now connect your version control, code changes, code reviews, releases and ticketing system into a single unified system based on Agile best practices. This also creates an audit trail that you can use for compliance or just general system audits and reducing technical debt.
You can also release faster as you spend less time debugging deployments and creating change sets.
Finally, you can trust that your releases are safe because you can rollback these Stories as needed.
Is there a better way to do Salesforce release management?
A quick look at the best practices for Salesforce development that have emerged in the past 3 years and in the era of Salesforce DX.