JIRA and Blue Canvas are recommended for better ALM in Salesforce development. Blue Canvas solves the "source of truth problem" by connecting each org to a branch in Git. The recommended agile flow involves creating a sandbox for each epic in JIRA and attaching it to a branch in Blue Canvas. Developers work in their own sandboxes and create a Deployment Request in Blue Canvas to integrate features into the sandbox for the appropriate Epic. When the epic is finished, a final Deployment Request is opened to Production or the next stage of development. This model works with every ALM software and allows teams to leverage their available sandboxes for smoother deployment and issue tracking.
With this article, learn how to set up an agile flow with JIRA, Salesforce, and Blue Canvas, and how to solve the "source of truth problem" in Salesforce development.
Here are our 5 Key Takeaways:
1. Atlassian's JIRA is a highly customizable and configurable tool for better planning and tracking of features in a given project.
2. Blue Canvas allows you to know who has changed what and when, and gives a running stream of all changes on your orgs for planning, debugging, auditability, and collaboration.
3. Blue Canvas has a unique branching model based on Git that connects each Salesforce org to a single Git branch to ensure that your source control is a source of truth.
4. JIRA's concept of Epics can be used to group features into a single project, and each Epic can be tied to a sandbox in Blue Canvas for integration and deployment.
5. This flow and model works with every ALM software and allows you to leverage sandboxes in a way that makes your deployment process and issue tracking much smoother.
Many of our customers are looking to implement a better ALM (application lifecycle management) process for their Salesforce development. Atlassian’s JIRA is one of the best tools for the job. It’s highly customizable and configurable. Using a product like JIRA gives you a better sense of what work is being done by whom. It also allows for better planning and tracking of features in a given project and you can use it to estimate more accurately when work will be done.
Blue Canvas does the same for your Salesforce code and metadata. It lets you know who has changed what and when, and gives a running stream of all changes on our orgs which helps with planning, debugging, auditability, and collaboration.
So using them together is a no-brainer. So what is the best way to set up an agile flow with JIRA, Salesforce and Blue Canvas?
Blue Canvas has a unique branching model based on Git. We allow you to connect each Salesforce org to a single Git branch.
We do this to solve the “source of truth problem” in Salesforce. Unlike many other software development environments, Salesforce developers and admins are empowered to make changes directly in various environments (production as well as developer sandboxes). If someone makes a change in a sandbox without committing to source, you can quickly have a discrepancy between your org and your source control. Your records (source control) may say one thing, but your app behaves differently. And app behavior should be seen as the source of truth because that is what your end users see. The best you can do is hope that your source control remains a faithful representation overtime.
The only way to ensure that your source control is a source of truth is to ensure that it is synced with the org in real time. Blue Canvas accomplishes this automatically by connecting each org to a branch in Git. When changes happen, they are automatically in source control and there is no longer a discrepancy.
While this solves the “source of truth problem”, it can make feature branching - a typical model for many agile teams - a bit more complicated. So how do you work with issue trackers like JIRA?
JIRA has a concept of Epics for grouping features into a single project. We recommend you create a sandbox for each epic and attach it to a branch in Blue Canvas. Name the branch something that associates it with that Epic. Set it up as an integration environment for all code and configuration in that epic in the UAT column of the Blue Canvas Dashboard.
Have developers work in their own sandboxes and add features. When they have a feature ready, they should create a Deployment Request in Blue Canvas from their developer sandbox to the integration sandbox associated with the Epic. Be sure to include the JIRA ticket ID and number in the title or description of your Deployment Request.
As you are integrating features into the sandbox for the appropriate Epic, Blue Canvas will automatically deploy for you. You can also trust that Blue Canvas will catch merge conflicts and surface them for you to resolve rather than blindly overwriting your code. It also allows you to keep a detailed history of changes in case you ever need to rollback.
When the epic is finished, open a final Deployment Request to Production or your next stage of development (UAT for some, Prod for others). Now you can close the Epic branch.
A good reason to tie your integration sandbox to an Epic, is that you can start with a new sandbox as you move onto new projects. This ensures that your sandbox is always closely mirrored to production to prevent dependency issues.
Though we have focused on JIRA and it’s concepts of Epics, this flow and model works with every ALM software whether it’s TFS, Visual Studio Team Services, Rally (now CA), or others. Most teams have far more sandboxes available to them than they are using. This model allows you to leverage them in a way that makes your deployment process and issue tracking much smoother.
