3 Things I Learned About Salesforce DevOps at DevOps Dreamin’ 2022
We launched OrgFlow to the general public at the end of 2021. We’ve been working on the product since 2019, using it internally since 2020, and were running private/closed betas for a few months too.
Before launch, we were tracking the Salesforce DevOps landscape as ‘outsiders’; keeping our hands close to our chest. We knew we had some fresh and original ideas, but we couldn’t tell anybody about them just yet.
That’s why it was so good to finally be able to attend a conference in person, be able to speak about our product and ideas in an open forum, and hear from a wide range of people at varying stages in their Salesforce DevOps processes.
So without further ado, here’s my top three takeaways from DevOps Dreamin’ 2022:
1. DevOps seems to be accepted by a wide range of people and companies
The first thing that stood out to me after speaking to a few people was the variety of companies and roles that these people were in.
There were admins, architects, developers, managers, business analysts and everything in-between. They were also employed in a variety of different industries and a variety of different company sizes — from single person consultancy firms all the way up to multi-national household names.
But they all had one thing in common — a strong understanding of what Salesforce DevOps entails, and a strong desire to get their company to that point.
2. Salesforce DevOps still has a long way to go
I personally come from a more traditional software development background. I had been doing that for almost ten years before I dived into the Salesforce world, and the thing that stood out to me at the time was that Salesforce DevOps was pretty much non existent.
Traditional software development DevOps was lightyears ahead of anything that you could do with Salesforce, thanks in part to popular tools such as Team Foundation Server, Jenkins and TeamCity.
Salesforce DevOps has of course come on a long way since then, but so too have traditional DevOps platforms (including a whole host of new DevOps tools and platforms such as Azure DevOps and GitHub Actions).
I am of the opinion that Salesforce DevOps tools such as Gearset, Copado, Flosum, and even Salesforce’s very own DevOps Center will fail to be able to reach feature parity with these well established traditional DevOps platforms.
3. People want to make changes in production
A recurring claim that I heard from a number of speakers was along the lines of:
You shouldn’t make any changes in production, all changes in production are bad
I don’t agree. And a lot of attendees that I spoke to don’t agree either. We all have business cases where it just makes more sense to make small changes in production.
Now, I’m not saying that all changes can be made in production, but I am saying that as a company, you should be able to decide what you allow to be changed in production, and what you don’t allow to be changed in production.
To get to the point where you can allow changes to be made to production, I think you need three things in place:
- A well defined policy that sets out when it is acceptable to make a change in production, and what metadata types it is acceptable to change in production. (If you can enforce this with profiles and permissions then even better.)
- The ability to frequently test your production org. Depending on the size of your org you might need a series of automated tests that can run on a schedule or trigger (but you’d have this already as part of your DevOps workflow, right?).
- The ability to commit these changes to your Git repository and merge them with any other changes that might have been made elsewhere.
Bonus thing that I learned: Chicago is a great city!
Seriously, if you ever get the chance to go, you should take it. We were there for a full week and there was so much to see and do that we weren’t able to fit it all in in the time that we had.
Where does OrgFlow fit in with all of this?
As I said earlier: Salesforce DevOps has a long way to go compared to traditional DevOps. That’s why OrgFlow acts as the glue between your Salesforce org and traditional DevOps platforms such as GitHub Actions, Azure DevOps, TeamCity, and more. This bridges the feature gap and allows you to take advantage of well accepted, well tested, and well documented platforms in order to run your Salesforce DevOps process.
We support (and even encourage) making changes in production, and our smart merging algorithm is able to merge these changes back into your Git repository and sandboxes.
You can try OrgFlow for free by getting a trial license. We also have a Slack workspace where we encourage any questions that you might have. If you’re interested in using GitHub Actions for your Salesforce DevOps, then be sure to check out our template repository that can get you up and running in as little ad 5 minutes.
