Blue Canvas introduces Work Items, a tool for faster and safer Salesforce development. It allows for bundling changes and easy conflict resolution.
With this article, learn about Blue Canvas' new tool, Work Items, and how it can improve the workflow for Salesforce development. I now understand how to set up a Release, pin changes to Work Items, submit them for review, and push changes upstream. This process can protect my Salesforce instance from errors and streamline the deployment process.
Here are our 5 Key Takeaways:
Work Items are a new tool in Blue Canvas that can improve the workflow for Salesforce development. A Release is a collection of changes that make their way to Production or another upstream environment. Work Items can be used to bundle groups of changes to Salesforce code and metadata together in units that can correspond to features or tickets. Once a Work Item is complete, it can be submitted for review and checked for merge conflicts and validation. Changes staged in the Integration Org can be pushed upstream to other environments by creating a Deployment Request and selecting a destination in your Blue Canvas account. FREE TOOL
Profiles & Permissions Deployer
Easily compare and deploy Profiles, Permission Sets, and Field-Level Security (FLS) between any two Salesforce organizations.
Get Started
Made with love by the Blue Canvas team ❤️
This week we introduced Work Items : our new tool for speeding up and taking a quantum leap forward for Salesforce development. It opens up a number of exciting workflows for your team. This article is designed to provide more detail on the ideal workflow opened up by using Work Items.
A New Flow for Salesforce Releases Releases
With Work Items you now have a concept of a Release in Blue Canvas. A Release can be whatever your organization wants it to be but typically it is a collection of changes that make their way to Production or another upstream environment like full copy or partial copy sandbox that you use for user acceptance testing. For most teams, this will correspond to a sprint and might be a 1-2 week cycle.
Setup As a best practice, each developer and admin should have their own sandbox. We’ve seen some teams combine all admins into a single sandbox but the more separation the better for handling merge conflicts and work between colleagues.
To use Work Items, you’ll need to designate an Integration Org for your release. This is a sandbox where you can merge and deploy changes to before releasing it upstream. It’s in this org where you will manage merge conflicts and validation and ensure that all of your most recent changes work smoothly together before you move on to testing upstream.
Pin Changes to Work Items
Work Items are kind of like tickets in a user management system like JIRA. You can even attach your JIRA stories to Work Items for enhanced tracking. They are not meant to replace your ticketing system, but instead to allow you to bundle groups of changes to Salesforce code and metadata together in units that can correspond to features or tickets depending on your workflow.
Blue Canvas automatically tracks all code and metadata changes that happen in your orgs as commits in Git. Devs and admins can now pin these automatically generated commits to Work Items. So each Work Item will typically get associated with several commits. This could be several changes to one file or changes to several files.
As an example, let’s say we have a feature that requires a new field and new trigger and an update to an existing class test class. You can just pin all of these things to the Work Item for that change.
(You can also do this retroactively create these Work Items and pin things to them if that’s more your jam.)
Submit Work Items for Review
Once a Work Item is complete, a developer or admin can submit it for review. This will run a lightning quick merge conflict check. If there are merge conflicts with the code in the Integration Org, it will surfaced here and you can quickly resolve it in the Blue Canvas UI without having to go to the command line or deal with Git. This prevents you from having to untangle messy code and conflicts too far upstream.
If it passes merge conflict review you can run a Salesforce validation to make sure it’s valid code or you can just push to the Integration Org directly. The submitted Work Item will show a status of Ready for Review. The ticket will show the Git diff so that a code reviewer or release manager can take a look and confirm that this is in fact a change they want to promote to the Integration Org.
If a validation was run, they can also see the results of the validation in the Work Item itself and get a sense for whether the code is valid.
Repeat
Once a Work Item is integrated into the Integration Org. You can continue to push additional Work Items as part of the Release. This is nice because you can have a bunch of developers doing a bunch of work and pushing the code in a safe way, trusting that merge conflicts will be caught before they become a problem.
When the change has been delivered to the Integration Org you now have successfully merged the code and deployed to integration in a single automated step.
You can do this for the duration of the Release until you are ready to move some of your Work Items upstream.
Push the Changes on the Integration Org Upstream
Now that our changes are successfully deployed to the Integration Org and cleared of any merge conflict concerns, you can push these Delivered Work Items upstream to other environments to UAT, QA or even straight to production.
When you are ready to push the changes staged in the Integration Org upstream you can do that by simply creating a Deployment Request and selecting a destination in your Blue Canvas account. This can be production or a full copy sandbox or even a dev sandbox. The push will only include the features that were successfully delivered to the Integration Org. (In the future, we’ll allow you to select and deselect which Work Items get pushed based on business/tester feedback).
You can then end the Release, refresh your sandboxes and start anew.
Benefits to this Flow We believe that this is the ideal process because it protects your Salesforce instance from code clobbering, bugs, and other gotchas. It’s automated so everything is tracked and nothing is missed. It’s also a very fast workflow relative to change sets.
But to accomplish all that you don’t have to add a lot of process. And key steps are automated (like automatic commits of declarative changes) to ensure that what you have in your Git stream is an accurate reflection of what is present in the org.
This allows you to trust that your Salesforce source control is now a source of truth. It also allows you to deploy quickly, cleanly and safely and with minimal overhead. And that is the holy grail for Salesforce deployments. More to come soon!
