Date published • 31st July 2018
After rambling about my views for a while in the start of this series, I thought I'd take it down a couple of levels and talk about the tools that I've used or know about that are compatible with Salesforce and DevOps.
This will be a long post, so I divided it in 2, one for Dev, one for Ops. But please bear with me, as it's important and will be needed for the next posts in the series and it can be useful for people as a go-to list. In that spirit, please send me info in the comments about other tools that I missed and you use and love, and I'll keep updating after checking them out.
I'll break these 2 posts down into a few categories, as much for ease of reading as for highlighting the importance of each and the width that DevOps brings into any engagement.
Of course, this is not a definitive list, as there are a lot of tools that do super cool things, but either I haven't used them, or they don't apply to Salesforce (usually because they're infrastructure related - Salesforce is fully managed - and I'll probably cover a few of those in a future post about DevOps in general, outside of only Salesforce, stay tuned), or both. For more information on the set of tools that exist out there and are widely used, check out the periodic table of DevOps, for example.
Note: this post and the ones that follow will be related to Salesforce's core platform, not touching on other areas like Marketing cloud, B2C commerce cloud (what was Demandware), Heroku and so on.
Ok, let's get straight to it.
As I mentioned lightly in my previous post, Salesforce has the metadata API to move changes from one place to the other, and it also has the Force.com migration tool (basically a way to use ant with the metadata API). These tools work for what they do, but are limited, as the API doesn't support all the metadata needed for complete automated deployments, and some of the areas it supports are messy, buggy or both (profiles anyone?).
Salesforce then came up with the Tooling API, faster and for different things than the metadata API, but it allowed people to build custom development tools. This API added to the ecosystem, but it was still lacking in completeness.
As an initiative to improve the developer experience and give more flexibility and freedom to move into source driven development (instead of "just winging it" as I feel it is otherwise), Salesforce came up with a CLI and Salesforce DX. They're still in early stages and are limited in some areas, but I'm not going to get into a lot of detail in this post about this, as I'll write a full post on DX in this series. I point this out because it affects the way you use some of the tools below.
This is a contentious topic, as everyone has a different view and preferred choices, but I promise I won't get into arguments or choose favourites (as much as I can).
For some context, Salesforce has supported a version of the Force.com IDE on eclipse for years, and love it or hate it, there was a need for more options, as it definitely has had some problems over the years. So MavensMate got popular, which continues to be widely used to this day, but it's now officially unsupported, meaning it won't get updates anymore. This is a big problem, given that Salesforce updates itself every 4 months or so.
This brings me to the list of some of the most popular IDEs that are out there:
In my opinion, if you're able to use only DX (lucky you!), I'd go with VS Code with Salesforce extensions. It's free, lightweight, integrated with CLI and Git and it's officially supported by Salesforce.
If you're not going with DX (or even if you are, as it's supported) and have the money, I'd go with Illuminated Cloud. I haven't decided on top of which editor, but I'll update this when I dig in a little more on that.
The most important part of the whole DevOps "thing", if it's not in source control it doesn't exist!
Even though there are many different systems for source control, I'm going to be only talking about Git, which is probably the de facto standard for source control. As it's distributed, it makes it great for collaboration and coordination. Check out the wikipedia page here for more info.
For git, you'll need clients and a server, below the list of the ones I've been in touch with:
All in all, it's a personal choice, the options are out there.
Again, there are many, but I'll name the most popular ones, at least in my opinion. Also, they're the ones I've worked with, so are the ones I know.
On clients, it's a dev's choice. I'd just say that in each team, most people should use the same tool, or at least be very careful on how the configuration of things like line breaks and empty spaces are the same, as you could get into a mess of seeing changes that aren't changes and other super fun situations.
On servers, they're all pretty good, to be honest, and it will be a choice of how your full DevOps stack works together. For example, if you're full into the Atlassian suite, then use Bitbucket, as it will integrate nicely with everything else. If not, probably check Github out. The most important part of this is that the server supports Pull or Merge requests and the ability to collaborate on them (this will be heavily used on the next post about processes).
So, choose accordingly, but definitely don't forget to use it.
Artifact repository management
In order to better tag and manage releases, you should probably think of creating artifacts that are inmutable and versioned (I'll explain a bit more on the processes post). I haven't used many repository managers, but I'll name a few here:
I can't really say too much about the others, but if you're using Bamboo, think of using your artifacts and releases with deployment projects, as they call it.
Continuous integration / delivery (CI/CD)
This is another area where there are many options and can be contentious, so I'll do my best to stay neutral and just provide the info on the ones I've worked with / played around.
It's one of those tough ones, but same as source control, the choice is probably up to how they fit in your full stack (think of the Atlassian suite decision above). Now, these can get pretty expensive, depending on the size of your team.
If you want to run it for free I'd say take a look at CircleCI first (Bitbucket Pipelines if you're using Bitbucket) and check if they fit for your use case. Then, as your budget needs to grow, move to Jenkins (it can be free, but you have to host it, which costs some - or a lot of - money, depending how you do it), CloudBees, Bamboo and so on.
Also, take a look Copado, Gearset, AutoRabit and the like, for less flexible and robust, but more inclusive experiences. Again, this is my opinion, on the day I'm writing this post.
Code quality review
There are a few of these out there, although not a lot, as Salesforce is a bit of a silo with this topic and the historical lack of tech support I mentioned in my previous post. I've used the following ones for Apex:
I'll give a shout out to Lorenzo's Clayton on this one, check it out and hopefully it fits in your flow as it does on mine. Check it out here.
This is a tricky subject, as automated testing is not that popular on the Salesforce platform. The problem, I think, has been that, as Salesforce gets updated every few months, some names could change, some conventions got messed up and then all scripts would fail.
This has made it too time consuming and not worth it in some cases. Also, there's a lack of technical support for test automation (surprise!). Salesforce devs don't necessarily know how to write test scripts and it turns into a vicious circle. I'm not going into the commercials, but think of hiring a dev just to write these scripts on top of the considerations I mentioned in my views, and you'll see how it's harder to sell automated testing in the Salesforce world.
However, you should definitely automate testing, of course! Plan your budget accordingly and keep all considerations in mind. I'll get a bit more detailed on where to use automated tests when I write my post about the processes.
The usual suspects come to mind for tests automation:
Salesforce is inherently a web site, so you can use any of that, if you can and know how to code it and maintain it.
For running tests in the cloud (you'll need this, as you'll need to simulate environments, connect to your CI tools and so on), there's SauceLabs(I'm sure there are others, but I'm not familiar with them), which I find really cool and integrates very well with DevOps flows.
There's also Provar, which is a Salesforce specific tool, which helps bypass most of Salesforce's peculiarities, so check it out here.
Automate your tests! Sell that and please let me know how you got along with it.
Ok, time for a break now. This post will be continued in part 2b, with the Ops side of the tools.
Ivan, Head of Architecture
If you would like to know more about what we do, we’re happy to answer any questions you may have for us.
Share this article: