A list of the top open source tools that every Salesforce Developer should know about.
Probably the coolest thing about software as a discipline is the concept of Open Source. In what industry or trade have people so willingly and freely give their work to others?
And Open Source Software (OSS) is having a really great influence on the rest of the world. Until recently it was hard to imagine a lawyer sitting down at his computer and typing up legal docs for free. Now through the influence of software, law firms are starting to open source their common documents.
Git, the very tool on which Blue Canvas is built, is open source and was built over a weekend.
Over the past few weeks, we’ve talked to over forty Salesforce developers. We’ve heard some great stories and learned about a lot of great open source tools. We thought we’d do a brief review of some of the best here.
First we have an amazing workflow put together by our friend Melanie Wright at Atlassian. The Atlassian team has written extensively about how Atlassian does Salesforce development. This document is a must-read.
The workflow describes everything from how to set up your Salesforce Orgs, to how to track change requests and the results with tools like JIRA. They even go into detail about the different workflows required for Salesforce Administrators compared to Salesforce Developers.
One of the most interesting aspects of their workflow is how they have implemented a source control solution running on Bitbucket Server (formerly known as “Stash”), their on-premise Git service. Every feature ends up on its own branch and developers can work on it isolated from other changes. Once it’s ready, the feature is merged into a master branch on a Developer Sandbox. When tests pass they merge features into their UAT and Production Orgs.They also cover how they use Bamboo to do Continuous Integration.
Two of the developers that helped create this workflow gave a great presentation at Dreamforce ‘15 on Atlassian’s developer workflow that we highly recommend.
Another up-and-coming Salesforce developer workflow that we have been keeping track of is Ted Husted’s appropriately named DreamOps. The goal for DreamOps is to facilitate Salesforce Developers who are looking to implement Continuous Delivery for their Salesforce teams.
The guide is a fantastically well thought out document, that explains in detail and with lots of background information how a great CI/CD pipeline for Salesforce could look like. It covers a wide range of topics all the way from user roles to tools and setup.
It’s really easy to contribute if you have best practices that you’ve found that you want to share with the developer community.
One of the most popular tools we hear about is Joe Ferraro’s excellent MavensMate. MavensMate is actually three pillars of technology that handle communication between your text editor, your local file system, and a remote Salesforce Org. The three components include a local coordination server written in Node.js and Express; several text editor plugins for different IDEs; and a desktop application to make it easy to install and run everything.
MavensMate comes with plugins for Sublime Text, Atom and Visual Studio Code(coming soon). The plugins send requests to the coordinator, such as “compile this file”. The coordination server then handles the actual communication with your Salesforce Org. This allows MavensMate to reuse the common base system with multiple different IDEs without having to maintain them as different versions. DRY–Don’t repeat yourself!
Many developers are using MavensMate as their primary development environment for Salesforce. Also, MavensMate is always looking for contributors!
You probably know it. You have probably used it. Maybe you feel strongly about it. The “Force.com IDE” is an editor plugin for Eclipse, written and maintained by Salesforce. It’s the reference implementation of a desktop IDE with many useful features.
From what we hear, it’s also the most popular deployment tool.
The Force.com Migration Tool, running on Apache Ant and Java, is another popular deployment tool we encountered in our conversations. The Force.com Migration Tool helps deploy Metadata between different Salesforce environments. It’s built and maintained by Salesforce directly. (Note: it’s not technically open source, but it is Salesforce maintained freeware and worth knowing about.)
All things considered, the Force.com Migration Tool is really just a CLI that lets you work with the Metadata API doing Metadata things: inspect settings, copy between Orgs, or retrieve and deploy components.
If you want to learn more, Iain Clements wrote a great post introducing the Force.com Migration Tool for Salesforce admins. It’s published over at the Salesforce Ben blog, which we think has a lot of great Salesforce material in general. Another great read from Jitendra Zaa is his Complete Guide to Salesforce Deployment which offers a step-by-step tutorial to get you started.
For those using Jenkins for Salesforce deployments, there is a relatively new Jenkins plugin available. The Salesforce Migration Assistant deploys metadata changes to Salesforce Orgs by looking at diffs between commits in Git.
The plugin handles test runs for you and will run your Apex unit tests for you ondemand. The plugin also allows users to create a “rollback zip” if you ever want to go back to an older version of the code base.
It doesn’t yet support Lightning, but is still very cool and worth a look!
As the project README succinctly explains: “dmc is a cross-platform, CLI developer tool for Salesforce.com.” The project’s goal is to make dealing with Salesforce’s APIs and Metadata much simpler. The tool is designed to make working with Metadata feel like “local and remote file system operations.”
This is a great tool for developers who want to work primarily at the command line and are looking for a more Unix-style approach to development. It’s also suitable for a continuous integration setup!
The good folks at Red Hat love open source and have given the world Solenopsis. Solenopsis (which is the genus name for Red Ants–referring to Red Hat and the Ant Migration Tool) is a command line interface that allows you to deploy Salesforce code. It basically combines some Ant and Python scripts in a simplified CLI.
For example, if you modify, add or delete Apex or Visualforce code, Solenopsis can automatically build the necessary manifests for deployment. It can also run your tests for you and gives you some flexibility in which tests you want to run.
One of the coolest features is that it lets you generate reports showing you differences between your Salesforce Orgs.
Solenopsis has been around since 2013 and is one of the older tools in the ecosystem. Check it out!
Anything we forgot? Let us know if we are missing your favorite open source tool for Salesforce. You can reach us via firstname.lastname@example.org.
Special thanks to Salesforce MVP Anup Jadhav for his feedback on this post.
Is there a better way to do Salesforce release management?
What is the Salesforce Lightning Design System? Should I use it?