How to use Git and Blue Canvas to refresh metadata and compare differences between Salesforce Orgs.
It’s Monday morning and the start of a new sprint. Friday was a huge success: you did a major deploy and demo to your business stakeholders. It was a massive success. You emerge from the weekend’s celebratory bender in a state of peaceful, if a bit groggy, bliss. Despite your newly exalted place in the hearts and minds of your colleagues and loved ones, you sit down to start coding anew. You aren’t one to rest on your laurels after all.
But there’s something that kind of annoys you: your development sandbox is not in the same state as your production environment. Multiple sandboxes were involved in contributing to the last release. A few features came from your sandbox, some changes to Triggers and Workflows came from a colleague in India, another set of Apex changes came from a colleague in New York.
Before you start coding again, you want the metadata on your sandbox to be the same as what’s running in production now so you can avoid merge conflicts and code from a clean state.
But before you can even do that, how do you know what’s different between your Salesforce Orgs? What’s present in production that isn’t on your sandbox (and vice versa)?
Blue Canvas also makes it easy to compare what’s actually happening on various Orgs via Git diff. We offer a simple UI for comparing differences between Orgs in real time.
Knowing what is different between your production Org and a sandbox or UAT environment can be extremely useful. Blue Canvas tracks each Org with it’s own Git branch. When changes happen on the Org, whether through the Salesforce UI or dev console or are uploaded via the Force.com migration tool or MavensMate Blue Canvas automatically pics them up and commits them to Git. This happens in real time so you can be confident that your comparison is accurate.
Most importantly, Blue Canvas tracks metadata changes automatically. So if someone makes a change directly in production and forgets to commit it or tell anyone, it will still show in your version control history. If someone updates a field or changes a Layout, that will be captured automatically.
With Blue Canvas everything is automatically present and backed up in your Git history and fully available to pull and compare using our UI.
Now that you’ve seen the difference in states, how do you make them one again?
Some developers will use a Sandbox refresh to sync the metadata on an Org, but as any Salesforce developer knows, this is not an ideal solution to this problem. Refreshes are data intensive and so there are limits on how many refreshes you can do in a given month. Furthermore once you request a refresh it can take days to complete. In the meantime, any changes you made will be lost when the refresh eventually does happen.
This is a major constraint on velocity and an impediment to continuous integration for Salesforce.
It also causes many developers to not work on sandboxes which are not fully up to date. So they’re coding and running tests against an outdated Salesforce Org - a dangerous proposition. When they eventually release to production, the tests run against the real version and may now fail.
Or let’s say you are about to do a release. You want to see what’s different between your Org and your colleague’s Org. You want to merge the code together and test it before pushing it to UAT or Production. How do you get data from an Org into your local environment?
Blue Canvas offers a Salesforce specific implementation of Git that provides a solution to this problem.
Blue Canvas creates a Git repo for you that is connected directly to your Salesforce Org. Refreshing the metadata on your sandbox is then as simple as issuing a git pull from a given Git branch (in this case your production or master branch). This takes a few seconds with Blue Canvas rather than a few days.
Because Blue Canvas automatically tracks all metadata changes that happen on your Org, we can help speed up the development process by keeping your various orgs in sync.
This is a best practices for CI and Salesforce development generally and will prevent innumerable headaches down the line.
git clone -o salesforce -b demo1 https://git.bluecanvas.io/YOUR_USERNAME/YOUR_REPO_ID.git
git remote add salesforce https://git.bluecanvas.io/YOUR_USERNAME/YOUR_REPO_ID.git
git fetch salesforce
git diff master...salesforce/BRANCH_NAME
Does the "power law" math that VCs espouse really work for founders?
Move over scratch orgs, make way for Lightning Developer Pro Sandboxes.