Salesforce developers can leverage pre-existing functionality on the platform through the UI to reduce the cost of development and maintenance. Blue Canvas offers a solution to bring Salesforce declarative and configuration changes into source control and a continuous integration workflow.
With this article, learn about the importance of treating declarative changes in Salesforce as equal citizens to code changes, and the benefits of keeping them in source control. I also discovered how different types of developers can contribute to Salesforce apps, and how Blue Canvas can simplify the process of integrating declarative changes into a continuous integration workflow.
Here are our 5 Key Takeaways:
- Declarative changes in Salesforce are just as important as code changes and should be treated as such.
- Different types of developers can contribute to Salesforce apps, from Apex coders to business analysts making declarative changes through the UI.
- The Salesforce platform democratizes technology by reducing the technical requirements to harness its power.
- Blue Canvas is a solution that can automatically commit declarative changes into Git, simplifying the process of integrating them into a continuous integration workflow.
- Configuration and declarative changes affect end-users' experience just as much as code changes, and should be kept in source control in real time.
At this week’s Spring 17 launch event, Salesforce senior management demoed some amazing new capabilities and tools associated with AI and Salesforce Einstein. They also briefly mentioned Salesforce DX and what an important step it would be for Salesforce developers of all stripes. In doing so, they briefly acknowledged just how many different types of developers there were on the Salesforce platform from hard-core Apex coders to business analysts making declarative changes through the UI. There are so many ways for different developer profiles to contribute to Salesforce apps it’s actually quite amazing.
In fact, one of the primary drivers of the success of the Salesforce platform is the “clicks not code” philosophy. A key tenant of software development is the DRY principle: Don’t Repeat Yourself. Some developers take this to an extreme but it’s generally a very useful concept. Salesforce makes great use of this philosophy through their powerful declarative user interface. Instead of reinventing the wheel every time, Salesforce developers can leverage pre-existing functionality on the platform through the UI to reduce the cost of development and maintenance while making their contributions simple and scalable as their business grows.
Configuration and declarative changes in Salesforce are just as important as code changes and should be treated as such.
The Salesforce platform democratizes technology by reducing the technical requirements to harness its power. You do not need to be a computer science PhD to build powerful Salesforce apps.
Many different stakeholders can contribute value to Salesforce applications. Salesforce developers can write Apex code that looks a lot like Java. Admins can make configuration changes to Workflow Rules that improve businesses processes. Technical architects and consultants can also add value to Salesforce without having to dive into the command line. And business analysts and sales operations staff can likewise amplify their business acumen through technology without having to enroll in a 6-month intensive “coding bootcamp.”
As more and more Salesforce development teams have worked to achieve continuous integration, more have started to put their code into source control. This typically takes the form of some ant scripts and getting Apex into GitHub or Bitbucket. But maintaining declarative changes is something that is done less often. Some teams do a weekly backup; few do much more than that.
Configuration and declarative changes in Salesforce are just as important as code changes and should be treated as such. They should be kept in source control in real time. They should be attributed to the user that made the change. They should be protected from merge conflicts and code clobbering. And there should be a clear history of what has changed when and where.
Declarative and configuration changes affect your end-user’s experience just as much as code changes, possibly more so. Many development teams do the majority of their customization with Salesforce as declarative work. We regularly talk to consultants who see a minor change to a picklist have drastic effects on their clients businesses.
It’s hard to find Salesforce developers who don’t agree that code and configuration changes are equal citizens. The main reason that teams don’t treat them that way is hardly philosophical: it’s technical. Setting up and maintaining scripts with the Force.com migration tool is painful and expensive. Teaching non-technical users to use the command line can be painful. Yes you can use tools like Source Tree with Salesforce but Git can be confusing. Admins have enough on their plate without having to adopt a new paradigm for software development. Who feels they have enough time in the day to accomplish the already myriad tasks required by modern business?
Fortunately, there are solutions out there to bring Salesforce declarative and configuration changes into source control and a continuous integration workflow. Blue Canvas automatically commits declarative changes into Git so that no one needs to learn Git or command line tools. You can simply keep your Salesforce declarative workflow and rest assured that your Salesforce metadata is getting backed up.
Are you treating code and clicks as equal citizens? To bring declarative and configuration changes into source control, check out Blue Canvas.
.png)