blue canvas dashboard

948 (and counting) Salesforce developers agree: Salesforce needs a source control solution. All modern development shops use some kind of version control system. Most new and modern projects are leveraging Git to handle this.

Without a version control system you have no way to handle merge conflicts. Without a clear record of what has changed on your Org, it’s hard to deploy safely. And without the ability to compare what is different between your sandboxes and production makes implementing code reviews becomes very difficult. Basically, collaborative coding is impossible without source control.

948 (and counting) Salesforce developers agree: Salesforce needs a source control solution. All modern development shops use some kind of version control system

After talking to over 100 Salesforce developers over the past month an even more straightforward frustration became clear about challenges associated with versioning and the Force.com platform: forget merge conflicts for a second, there is still no good way to see who changed what when.

It seems obvious that teams would want the ability to track changes on their Salesforce instance, but the majority of teams have no way of seeing this. It causes problems in myriad ways.

Did a bug make it to production? It’s useful to have a clear audit trail in order to see what happened. One of the best ways to debug an issue is to take a look at how an Apex Class or Visualforce page has changed over time. What was the original intent of the Class? What is it doing now? It’s also helpful to know who made the change. Maybe it’s a colleague sitting next to you or maybe the author is long gone, but it’s good to know whether there is someone you can go talk to about it.

Many Salesforce developers and admins are working with external consultants on their applications. Outside consultants are one of the great things about the Salesforce ecosystem. There are so many great teams you can work with like CRM Science and Code Science. But collaboration between internal and external teams has it’s own challenges. Having a clear record of what has changed on your Orgs and by who become especially important when working with outside consultants.

Many of the most hardcore Force.com developers we talk to still do over 50% of their work in the developer console.

Many Salesforce teams now have a release manager who is responsible for deploys. Often this is done in order to maintain SOX compliance. Many release managers struggle to keep track of what has changed over time. Maybe a new Apex Trigger has been added or there was a change to a PersmissionSet and they want to ask about it. Who should they ask?

Or maybe you’re a developer trying to compare the differences between your sandbox and production or between your staging environment and your coworker’s sandbox. It’s useful to have a visual tool that can show you where the code is different.

If there are so many reasons to implement source control for Salesforce, why are so few lacking this basic reporting?

After talking to over 100 Salesforce developers over the past month something else became clear about challenges associated with versioning and the Force.com platform: forget merge conflicts for a second there is still no good way to see who changed what when.

Salesforce doesn’t have a native source control system today. Many teams are turning to GitHub or Bitbucket to provide this kind of functionality. But one of Salesforce’s greatest assets - it’s “no software” philosophy - becomes a major pain when it comes to this kind of tracking. GitHub and Bitbucket do not track declarative changes made through the developer console or UI. And a lot of work gets done through the UI. Many of the most hardcore Force.com developers we talk to still do over 50% of their work in the developer console. Salesforce just makes it so easy to do so.

How can you get better visibility into what’s happening on your Salesforce Orgs without losing the benefit of declarative changes or making everyone on your team learn Git?

Introducing Blue Canvas History Tracking

Blue Canvas has a new tool in beta that provides automatic tracking of everything that happens on your Org. Whether someone makes a change in the Force.com IDE and pushes it to production using the Ant tool or logs into the developer console and makes a change directly on the Org, Blue Canvas is constantly polling your Salesforce Orgs for changes. When the tool discovers changes, it automatically commits those changes into Git. This way you get a full history of what has changed on the Org.

Blue Canvas also shows you who has made the change. This makes it easier to collaborate and see who is responsible for which code changes. You can even see time stamps.

Because Blue Canvas is built on Git, it’s very easy to see detailed diffs of what has actually changed in the code such as:

git diff blue canvas

Getting this kind of tracking is as simple as logging into to a webpage. No one needs to learn Git or remember to commit things. You don’t have to make any changes to your workflow. Everyone with access to your Org can have their changes tracked whether it’s an external consultant or a business analyst who just came into change one or two reports.

This kind of visibility should let you sleep easier at night knowing what is going on with your Salesforce Orgs and help you avoid deploying bugs to your mission critical apps.

To get access to this tool signup for our beta list below.