Salesforce DevOps is a topic gaining steam recently as organizations look to reduce cycle times and introduce features more frequently to keep up with a rapidly changing business landscape.
It is no surprise that Salesforce teams want to adopt DevOps into their workstreams. These teams have watched traditional development teams reap the benefits of DevOps for the past decade.
I have been on this journey recently. I thought the timing perfect for attending this inaugural community conference centered around DevOps.
Given the sponsorship by Gearset, it made perfect sense to participate since I am implementing their product. Follow along with our journey here.
Format and Venue
DevOps Dreamin’ was scheduled as a 1.5-day conference from March 31, 2022, to April 1, 2022; rest assured, this conference was not an April Fools joke!
The organizers were able to book the Mid-America Club on the 80th floor of the Aon building in Chicago, Illinois. While there were only two conference rooms in use for the conference, I never felt like we were cramped or could not find a little bit of space to myself.
The layout of round banquet tables in one room and classroom-style tables in another allowed attendees to casually meet other attendees if they wanted and respected those who did not want to network at times.
Unlike some conferences, I never had to wait to enter a room or stress if I missed a session.
We have become second to none at deploying Salesforce metadata
Matt Dickens, Chief Product Officer and Co-Founder gave a session on the future of Gearset.
The company is a fan of dogfooding, with over 530 releases in 2021. The session was centered around Gearset’s values.
This year we will see the rollout of more enterprise-centric features, including SSO and potentially SCIM, an audit API, RBAC features, and CLI tooling.
There is also a focus on using Gearset for end-to-end development, allowing the ability to configure environments as part of the workflow.
This ability to automate environments is a significant focus of this conference.
It is good to know that there is the ability to buy and build.
Over 1.5 days, there were 31 sessions to choose from; since there were only two sessions at a time, it never felt like you were “missing out” on a session.
As the conference was sponsored by Gearset, a good portion was Gearset related. Still, the balance was struck between product demos and platform-agnostic content.
The sessions never felt like a sales pitch but were tailored more towards general CI/CD pipeline concepts. I have attended too many sessions at conferences with great titles. Still, you don’t learn anything other than what product is being hocked.
Overall, the content catered to individuals new to DevOps, with most introductory content. There wouldn’t be much-advanced content if you were familiar with DevOps or leveraging pipelines in an Org-based or Source Controlled environment. We barely scratched the surface related to low-code testing, automated test suites, or other advanced techniques.
However, I am confident that if the event is renewed next year or following, the content will expand as more organizations adopt a DevOps mindset.
It’s no surprise to see many sessions geared towards DevOps awareness and how to adopt it within your organization.
Gearset was here to highlight their platform, but they did provide overviews and general thought leadership towards why CI/CD for Salesforce is essential.
We learned about where we all are on the DevOps maturity curve, how Salesforce CI/CD differs from traditional software engineering DevOps, and how Salesforce is beginning to promote local development.
Although Salesforce is known to acquire platforms to advance its efforts, it will be interesting to watch the DevOps space to see if the trend continues. Salesforce is leaning into DevOps, releasing their own DevOps Center as a pilot this May and GA this fall.
I will be interested to see how the advent of their own DevOps platform will compete with Gearset, Flosum, and Copado.
From the Salesforce hosted sessions, it sounds like Salesforce will be adopting techniques for the pro-code ecosystem to the low-code/no-code side. We know metadata deployments and no-code (Flow) solutions need testing suites. We all have had defects introduced because we cannot test these solutions, especially between environments. Salesforce has admitted that they are working (Safe Harbor) on solutions to address this.
One piece was missing from this session, though. I heard that you should learn DevOps or put someone with DevOps experience on your team several times.
Not once did I hear about leveraging your existing DevOps team, if you have one. Your SRE or Reliability teams already know Git actions, Jenkins, or Maven and can be valuable allies.
Why silo Salesforce teams when the wheel doesn’t need to be reinvented?
Five pillars of DevOps: Version Control, Automation, Testing, Backup, Strategy
As an engineer, there are three tools I live in Git, Terminal, and IDE (VS Code being my current favorite). Two of these tools were in the spotlight. It is great to see both Git and the Terminal receiving more attention in the Salesforce ecosystem, especially amongst Admins.
For those who are unfamiliar:
Typically you’ll see Git in reference to its productized versions: GitHub, BitBucket, Gitlab, etc.
The typical Salesforce Admin has probably heard of Git but hasn’t interacted with it due to being in the declarative world and using changesets.
However, Git is an all-important tool within the DevOps world. Git allows for version control and prevents breaking changes from being merged into production. Git is why multiple team members can work together and not step on each others’ toes.
We saw several sessions introducing how to interact with Git, mainly focused on GitHub – probably one of the most well recognized VCS – and Gearset interacting with GitHub.
While none of the sessions dove into rebasing, how heads work, and the structure of a repo, they did touch on why a VCS is important and how work is introduced into a pipeline.
Once again, I think this is the familiarity stage for DevOps with Salesforce. There still remains a critical mass to ensure we start leveraging tools that others throughout the industry are using. Especially as we look at Internal Controls and SOX regulations.
It also bears repeating that we didn’t discuss pairing with an engineer in your organization (if you have one) to learn how Git is used. We should start partnering more outside of our silos.
CLI (Command Line Interface aka Terminal)
CLI for Admins was on my list for future posts, and I was ecstatic to see multiple sessions catered toward Admins.
You can’t shout out the benefits of Git from the rooftop without having some learning on CLI.
Why? CI/CD leans on Git, and Git was born out of command instructions. While not as crucial for declarative users, pro-code engineers love the CLI.
We saw sessions on how to get comfortable with the CLI and ones tailored towards SFDX and directly interact with our orgs. CLI also popped up its head as we talked about getting information to bake into our pipelines.
I believe that getting comfortable with CLI speeds up a lot of Admin actions, even just logging into an org. Pushing what is needed at just the right time. Hopefully, we are approaching a day when Admins use scratch orgs just as developers.
It was apparent from the questions in the audience that Salesforce is still early on in its DevOps journey. The declarative and business users are still grappling with the tools of the trade, and that’s okay. The good news is that we are talking about it and providing safe places for folks to get comfortable.
We have resources such as Gearset’s DevOps Launchpad, Vernon Keenan’s Salesforce DevOps, and even Salesforce’s DevOps Center. The more we start talking about it and pairing with our partners utilizing DevOps in other parts of the business, the more we mature in practice.
I am excited to see what discussions this conference will spurn. It’s an exciting time to be on the platform, and I think we’ll start to see how we configure Salesforce change.