Salesforce and DevOps Part 1 - Ivan's views

Date published • 31st July 2018

Let's start with a couple of conversation topics (bear with me if you know them already, comment if you don't agree, feel free!):

  • What is DevOps: you can find good definitions for DevOps all over the place (this one, for example), so I'm not adding anything new here. The important part for me is that people know that it is a culture shift, it's a way of working, and it's not just the tech and tools involved!
  • Who uses DevOps: well, everyone in a technology company should! It includes (as the word implies) Dev and Operations, but it's a bit broader than that, as it also includes testing, collaboration, monitoring, and so on. There is DevOps for everyone!
  • Why use DevOps: the benefits are many!
    • Faster time to market new features through automation
    • Higher quality of deployments, as less defects move all the way to production, they're caught really early on
    • Subjectively, in my experience, teams collaborate a lot better and feel more confident as things progress in a      DevOps culture
    • Everything can be tracked, all bottlenecks can be found and dealt with
    • Both delivery people and operations are happier, or at least have a better insight of what's going on at all times and can collaborate better. Happier employees mean better employees, usually
    • Reducing human errors make results more dependable
    • All of the above results in gaining trust! not easy to gain, but really easy to lose
    • Money savings!!! less hassle, less overhead, more efficiency, faster times to market translates in less cost and more revenue for your products

Now, in the Salesforce world, there's a big lack of motivation embracing the DevOps culture, and I'll use this post to reason out why I think this happens. Please add to the comments and I'll keep updating.

For me, the major reason is that the culture is not there yet. As I mentioned earlier in the post, DevOps is mostly culture and ways of working, and for Salesforce, unfortunately, things are not there yet, and it's hard to implement the culture as a whole.


In my opinion, some causes for this lack of DevOps culture are the following:

  • Salesforce being so "easy" to configure and customise with clicks and not code make people think that there's no need for what they see as convoluted processes. Have you encountered the question: Why should I do that when I can just do it straight there? Why do I need to pay for all that?
  • Thinking it's OK to just go and change things in production directly, because you can, without traceability
  • Historical lack of technical support and tools by Salesforce themselves. Things seem to be changing with SFDX, but it's still in the early stages
  • Salesforce, being multi-tenanted and proprietary technology, has to create their own ways for customising the client orgs, for which they started the metadata API long ago. I don't know for sure how many years they've been working on that, but it's interesting that there are still so many things that are not supported by it, making it complicated to automate all kinds of development at all times. They seem to be working on that as well, we'll see how fast and reliable that is. I'm optimistic, though, don't get me wrong
  • People working hands-on with Salesforce technologies, in my experience, have been divided into 3 groups: functional (BAs, configurators, admins, consultants and so on), technical (developers, architects and such) and testers (QA, functional testing, automated testing experts, for example). For the most part, DevOps has been driven by the technical group so far, and highly seen as obscure technical stuff and "coding" by others. This is mainly due to lack of knowledge, and technical people not being the best at sharing it and making it clear for everyone (I've been known to be guilty of that, sorry to say, but I'm working on it!)
  • For the reasons above, and others I'm not getting into, it's been historically hard to sell the implementation of DevOps. As it's not widely adopted, it's seen as expense that is not worth the trouble
  • Salesforce implementations don't always have the people it takes to lead a project with a DevOps culture, and these people are highly in demand, and are super expensive as well, which also makes it a hard sell sometimes

After writing that list, things seem to be very bleak, but that's really not the case, as most of those are changing!


Below is a list of things everyone should do, in order to make it happen (I know I try to do this):

  • Try your best to empower your delivery teams, using a common set of tools and processes reduces the "gap" between the groups I mentioned above. For this, they need support to begin with, but they get used to it as they see the benefits and embrace it really fast, I've seen it every single time
  • Most people working with Salesforce work in technology companies, embracing the future sometimes is scary, but it's the future. In fact, DevOps is the present, and we in the Salesforce community are a bit behind
  • Salesforce are definitely trying to improve their technology toolset with DX and the lightning platform and other initiatives, so use them, collaborate, give feedback and push for innovation
  • Don't know about you, but I think having DevOps in your CV is hot right now, so why not? This applies to all groups: functional, technical and testing! I'm a firm believer in that everyone in a technology company should know and embrace DevOps, no exceptions
  • Avoid changes and releases that are not tracked and controlled, they'll be forgotten. Please take my word for it, in the future you'll want to know what you did, and no one will remember, therefore no one will know what went wrong, what is wrong now and how to improve it and that grows and grows... So, track your source, put a process in place, monitor your ops, document and report on your progress, use the tools if you have them, in short, embrace the culture!
  • For me, being a mostly technical person it's been hard to explain the value of DevOps, I like to think I'm getting better at that, but I ask for help, and I try to collaborate. The point is, ask for help, always, in any area, collaboration is key
  • We need to educate clients, and for that we need to be very clear on the value of DevOps, we need more of that if we want the culture to shift. For this, we need to bring everyone together, the benefits are big and the profit to be made is huge!

In the next parts of this series, I'll go deeper in the tools (part 2) and processes (part 3). Later on, I'll talk in more detail about DX and overall limitations, to finish up with my personal wish list and how I see the future, let's see how it goes, hope it's interesting for everyone.


Words by:

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:

View more from the blog and events