Salesforce developers need a source control solution to handle merge conflicts, track changes, and deploy safely. Blue Canvas offers a tool for this.
With this article, learn about the importance of version control for Salesforce development and the challenges associated with versioning on the Force.com platform. I also discovered a new tool in beta called Blue Canvas History Tracking that provides automatic tracking of everything that happens on your Org, making it easier to collaborate and see who is responsible for code changes.
Here are our 5 Key Takeaways:
- Salesforce needs a source control solution to handle merge conflicts and deploy safely.
- There is still no good way to see who changed what when on the Force.com platform.
- Blue Canvas History Tracking is a new tool in beta that provides automatic tracking of everything that happens on your Org, making it easier to collaborate and see who is responsible for code changes.
- Blue Canvas History Tracking is built on Git, making it easy to see detailed diffs of what has actually changed in the code.
- Getting this kind of tracking is as simple as logging into a webpage, and no one needs to learn Git or remember to commit things.
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 version 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 version 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 version 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?
Blue Canvas has a new tool 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:
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.
You can sign up now for a free 14-day trial at https://accounts.bluecanvas.io/signup .
.png)