Salesforce DevOps is a buzzword in 2022 as vendors in the space continue to receive investment. And rightfully so, 3 years into the pandemic, companies want to release features faster and in a controlled manner.
For years Salesforce has worked on tooling to allow developers to push code quicker, first the Force.com CLI, then SFDX, and layering in Dev Hubs and Scratch Orgs.
While the developer community has been happy using familiar tools to engineers across languages – git, terminal, CLI, IDE – we’ve noticed that administrators continue to languish with changesets.
Companies have burst onto the market. Some are built into the Salesforce UI, some recreated GitHub, while others play in the middle.
Regardless of design, they are all about reducing friction through deployment and minimizing changesets within the flow.
This is the first part of a series covering our Salesforce CI/CD journey.
A tale of maturity
I came into an organization where almost all work was built directly into Production – sometimes without specs – and sandboxes were 9 months out of date.
Because Salesforce is tightly coupled to our custom app, some fields need to maintain parity. With 30+ Admin profiles assigned, we had no idea if a change would cause additional debugging or who did it.
We monitored changelogs piped into a Salesforce channel to ensure breaking changes were not introduced into Production.
Our team being in engineering, I knew we needed better tooling to release quality features.
Our team knew that we would need a product that both Salesforce Administrators and Developers could use effectively. Additionally, we knew that our third-party consultants would need to use the platform to promote changes if this were to work.
Due to the nature of our business, we already had a Github Enterprise account. We were comfortable navigating git from a command line. We wanted the ability to leverage GitHub for source control and visibility.
Since Admins needed to be comfortable with the platform, we knew we needed an intuitive interface.
We don’t use Jira at our organization and instead use Shortcut – this would be nice, but I knew it would be a tall order.
This was a project we approached differently. We had loose requirements as a North Star but did not favor using a regimented scorecard.
We knew this project would blend budget and instinct of whether we liked the platform.
We were well aware that these platforms varied in features and price, but we knew we wanted to see them. Simply put, we knew we needed a solution but didn’t know what was out there.
I won’t dive into each product’s pros and cons in this article, but we had some exciting demos. Some seemed ill-prepared and weren’t used to speaking with non-enterprise customers.
Other products seemed to have everything we wanted, but additional layers of complexity were on top. We knew that while we needed maturity, we also knew where our appropriate comfort level was in the form of adoption.
One thing that stood out, we noticed that the vendors that chose to build their solution in Salesforce basically rebuilt GitHub. We asked about the ability to connect to GitHub. They could indeed, but were attempting to sell us that their version was better.
I would agree that a rebuilt Salesforce native repo may work for Salesforce-only teams. But, we get so much more out of GitHub, including automation.
In the end, we selected Gearset. Their platform operates as the wrapper, running validations and providing the ability to selectively choose metadata to deploy. Their interface was streamlined, there was no massive level of complexity, and we liked that it was GitHub (or Bitbucket or Gitlab) focused.
Buckle up because you will be along for the journey.
- Will we succeed in convincing Administrators to abandon changesets or stop work in Production?
- How will our pipeline look? Plus, how difficult will it be to set up?
- Will we see a reduction in incidents now that there is a process?
- What are the lessons learned?
I look forward to sharing our journey with you and any insights you have as we travel on this new CI/CD pipeline.