This article was written by Nicolas Vuillamy, one of our Cloudity’s CTO, and published initally on salesforcedevops.net.
If you’re like me, you’ve been frustrated dealing with the Salesforce release management experience. It’s like we Salesforce users couldn’t use all that good DevOps stuff happening in Java, Python, JavaScript and other, more popular versioning experiences.
As we looked at that landscape, my team and I at Cloudity became so frustrated about how awkward it was to do Salesforce release management. That is when we decided to do something about it.
When confronted with how complex it was to use Salesforce tooling, we created a custom layer called sfdx-hardis for an advanced, manageable CI/CD. In this article I tell the story of how we decided to build sfdx-hardis and I’ll also help you see if it’s a good system for you to explore.
- 1 : The SFDX-HARDIS story
- 2 : How We Decided
- 3 : SFDX-HARDIS Application Scenarios
- 4 : How Does It Work ?
- 5 : Conclusion
The sfdx-hardis Story
I started working on Salesforce in 2017. We were 10 colleagues working in the same org, and despite our desperate attempts at synchronization, it was kind of a nightmare to control who does what, where, and why, and don’t even get me started on performance!
Some things we did were awkward, to say the least. We used Ant deployments scripts with command lines copy-pasted from a Word file, and manually written package.xml.
When Salesforce DX was released, it was like a light appeared at the end of the tunnel. We would finally be able to work with CI/CD with Git and Pipelines, as it has been the standard for the past 10 years with any other technology!
The joy wouldn’t last, however. SFDX is a nice tool, but except for “hello world” cases, the calls to SFDX commands must be dynamic, and thus, scripted. We encountered these problems:
- Manual updates of metadata XML files to avoid deployment errors
- Problems with overwriting metadata that has been manually updated in production
- Adoption issues with non technical users
This meant we had to script, script, and script over again (in Bash, Groovy or JavaScript, depending on the weather and mood), until efficiently reducing the essential manual operations, and reaching an acceptable state for the CI/CD Pipeline. The pipeline with its custom scripts had to be directly maintained in the project repository, which was efficient but time consuming.
How We Decided
When I started at Hardis Group’s Salesforce Practice (now Cloudity) as a new CTO, some of our customers had already been moving into CI/CD as a Salesforce best practice. So, some CI/CD projects were already set, with home-made pipelines and scripts directly maintained in the project repositories.
We had to choose amongst the available options in the ecosystem:
- Purchase licenses of a DevOps market tool like Copado, Gearset, Flosum, Autorabit, Blue Canvas, Prodly, or Opsera.
- Or, continue to use home-made CI/CD pipelines (and maintain them on each project)
We came up with this decision matrix to help us choose!
Summary of our analysis at the time
We weren’t thrilled about the commercial options because our clients don’t all have the budget. So most wouldn’t have agreed to purchasing expensive additional licenses on something they didn’t fully comprehend.
As we had internal knowledge regarding home-made CI/CD pipelines, we decided to go ahead and commence the project!
But as we did not want to have to maintain scripts on each client repository. That inspired the idea to package an open-source engine that would be used everywhere, and repositories would only contain the configuration applied by the engine.
That is how the Salesforce DX plugin sfdx-hardis was born!
Salesforce DX plugins are usually used via the command line, and some of our Business Consultant colleagues were not happy. That was because they were not used to command lines. So we decided to create an UI to work with clicks, not command lines. That is how we got started with the Visual Studio Code Extension for sfdx-hardis.
Do you need sfdx-hardis?
Are you tired of change sets, maintaining your pipeline scripts, or don’t want to or can’t pay for third party DevOps products? Then maybe it is time to switch from manual org-based deployments to automated source-based deployments!
After crossing the bridge to source-based deployments, you will benefit long before you deploy to production with these important developer patterns:
- Versioning: Trace who did what, when, where and why
- Deployment checks, including Apex tests code coverage
- Code quality checks: Reduce the number of bugs in production
- Conflict management: avoid overwriting your colleagues’ work
- Automated deployments: let the CI servers deploy them for you, with minimal manual actions
In this diagram, I am giving you a before and after look at how introducing a devops pipeline changes Salesforce release management. In our case, we introduce a set of activities which make up the continuous integration and continuous deployment (CI/CD) process. These activities are run on a scripted command server that orchestrates the entire process.
The CI/CD process gives us important capabilities, including:
- Thanks to the automated checks, anything that succeeded to reach the Integration (Integ) org will then be deployed seamlessly to UAT, then to Production org
- What you test on UAT will coincide with what will be deployed in Production
sfdx-hardis Application Scenarios
Here are some of the common patterns found in using sfdx-hardis. But before getting started you need a few prerequisites:
- Access to a GIT & CI/CD server. This is the server that runs scripts to manage the CI/CD process. sfdx-hardis has built-in integrations with Gitlab CI and Azure Pipelines. You can also adapt it to Github Actions, Bitbucket Pipelines and Jenkins.
- A designated release manager who can run Git and Salesforce DX.
- The will to evolve: Your teams must be mature enough to accept to be trained to use versioning and forget about using change sets, for the project’s greater good!
Now, let’s go and see how sfdx-hardis works depending on your role in a Salesforce application development team.
- Setup Manager Role
- Release Manager Role (can also be the setup manager)
- User Roles (Business consultants, developers)
Setup Manager Role
The setup manager will initialize the technical elements of the Salesforce CI/CD project (Git repository, Branch strategy, CI/CD pipeline, Authentication between CI server & Salesforce orgs…).
Here is an example of advanced branch strategy, with parallel management of BUILD and RUN for a project, but depending on the project’s complexity, it is also possible to define a much simpler branch strategy with a pre-production (branch & org) and a production (branch & org).
All the steps for setup are detailed in sfdx-hardis Setup Guide.
As a release manager
The release manager’s part will be to assist other users, validate merge requests and proceed to deployments between major branches (ex: UAT to production)
All Release Manager operations are detailed in sfdx-hardis Release Manager Guide, with tutorials and videos.
As a user
The user’s role is to provide new features and fixes!
They will work in source-tracked sandboxes (or scratch orgs), and use VsCode SFDX Hardis visual menu to:
- Initialize a new git branch
- Connect to a Salesforce org
- Pull updates from org
- Prepare their merge requests
Developers will obviously have access to many more operations! All user operations are detailed in sfdx-hardis User Guide, with tutorials and videos.
How does it work?
No, it’s not magic! Here is a quick tour of how sfdx-hardis works!
Salesforce DX plugin: sfdx-hardis
sfdx-hardis is just an orchestrator of native SFDX commands, git commands and other SFDX plugins commands.
It has been made to assist users by prompting inputs and questions when necessary, and displays in logs every background command so techies can see what is run behind the scenes in live.
It automates operations and updates XML when necessary, for example:
- Automatically generate package.xml and destructiveChanges.xml before committing (thanks to sfdx-git-delta !)
- Automatically install managed packages during deployments
- Automatically import data during deployments (thanks to sfdmu !)
- Remove permissions on profiles, to avoid issues in 2026 with their deprecation
- Auto-fix XML sources so they can be deployed
- Avoid overwriting elements in deployment target orgs when they are directly maintained in production
- Initialize sandboxes and scratch orgs with assignments, sample data…
- Force pull updates that are not detected by SFDX tracking
- Generate certificates, deploy a connected app and provide config variables to create a secure connection between CI server and orgs
- Provide human readable instructions to solve deployment errors
- And many more!
Most of the configuration is in a single YAML file in your repository, with enhanced documentation and auto-completion while editing, and its content is usually directly updated by sfdx-hardis configuration commands.
When you use the create sfdx-hardis project command, it adds ready to use pipelines:
It is also shipped with a command that creates an additional monitoring repository, that will create a backup of all org metadata every night, so you can:
- Track manual updates by admin users in production
- Anticipate issues related to Critical Updates, like legacy API versions deprecation
Visual Studio Code Extension: VsCode SFDX Hardis
VsCode SFDX Hardis is mainly a menu launching command lines, but not only:
- Integration between sfdx-hardis CLI prompts and VsCode prompt UIs, for a better user experience
- Check presence and compliance of dependencies (Node.js, sfdx-cli, SFDX plugins…) and assist users when they must be installed or upgraded
All VsCode SFDX Hardis code is open-source and available on its public repository.
Conclusion
As we successfully use it on many of our large client projects, we consider our CI/CD product to be mature enough to be officially shared with the trailblazer community!
This is Cloudity’s humble gift to the Salesforce Ohana: all we ask for in return is feedback, and perhaps some Github Stars 🙂
Pull requests are of course very welcome for anyone willing to contribute, even if you are a competitor, that’s how open-source community works: we all work together towards the greater good and all benefit from it 🙂
Special thanks to:
- Julie Camdessus & Alexiane Debaenst for correcting my clumsy english 🙂
- Vernon for giving me the opportunity to post on salesforcedevops.net
- Maxime Guenego, Clément Fernandez, Remy Vultaggio Focher & Fabien Taillon for proofreading.
Nicolas Vuillamy was invited by Vernon Keenan for making an interview about our SFDX-HARDIS.
You can hear the podcast here 👉
If you want to read the original article, click here.
