In today’s fast-paced development environment, agility and quality are key. Continuous Integration (CI) helps teams achieve both by automating the process of integrating and testing code changes. Instead of waiting until the end of a sprint or project, developers integrate their code into a shared repository several times a day. Each update triggers an automated build that detects problems early, long before they reach production.

For Salesforce development, this approach offers a significant improvement over the traditional, manual deployment model. Let’s explore how Salesforce development has evolved and how SoftServe built a reusable CI solution to make it faster, safer, and more collaborative.

FROM CHANGE SETS TO SOURCE-DRIVEN DEVELOPMENT

Traditionally, Salesforce teams relied on change sets to move updates between environments. This metadata-driven approach treated the org itself as the source of truth. However, it came with several challenges:

Code could be changed or overwritten without notice
Developers had to manually track and add every change to a change set
There was no version history or code review process
Issues were often discovered late in the release cycle
Integration with source control systems was inconsistent or absent

In short, the process was manual, error-prone, and difficult to scale across teams. And it looked like this:

SALESFORCE DX: A NEW DEVELOPMENT MODEL

In 2017, Salesforce introduced Salesforce DX, marking a major shift to source-driven development. With this model, the source code, not the org, is the single source of truth. Development becomes modular, environments are easily created and disposed of, and collaboration happens through modern DevOps tools.

This approach fits seamlessly with agile development and international quality standards, such as ISO 13485, providing a structured, reliable way to build and release Salesforce applications.

SOFTSERVE’S CI SOLUTION FOR SALESFORCE

Building on Salesforce DX, SoftServe developed a reusable CI solution that combines the power of Salesforce DX, Jenkins, and PMD. This setup streamlines the entire development lifecycle, from coding and testing to deployment and review.

Here’s how the workflow looks:

The developer creates a feature branch and a scratch org to work in an isolated environment.
Once development is complete, they create a pull request for peer review and merge it into the master branch.
Jenkins automatically detects the changes and deploys them to a shared dev org for team testing and review.
To move changes to the QA org, the team simply rebases or cherry-picks the latest updates, and Jenkins handles the deployment automatically.

KEY BENEFITS

This CI solution introduces a structured, automated process that enhances both quality and collaboration:

Feature branch workflow for parallel development
Code reviews through pull requests
Clear code version control and rollback options
Faster issue detection
Prevention of overwritten code
Built-in code analysis and quality reporting

CODE ANALYSIS AND QUALITY CONTROL

To strengthen code quality, SoftServe integrated PMD, a static code analysis tool, with the “Warnings Next Generation” Jenkins plugin. Every commit is automatically analyzed for potential issues and code style violations.

PMD checks include, for example:

Avoiding SOQL or DML statements inside loops
Preventing business logic in triggers
Avoiding hardcoded IDs
Ensuring Apex test classes use assertions
Maintaining consistent code style conventions

This ensures that every build maintains high standards of performance, maintainability, and readability.

KNOWN LIMITATIONS

While Salesforce DX and CI bring clear benefits, there are still limitations to be aware of:

Dev Hub can only be enabled on orgs without a registered namespace.
Permission Sets are recommended. Using Salesforce DX with Profiles can be problematic. Scratch orgs may add configurations for fields that don’t exist in your main org. When you pull these sources, the field-level security (FLS) for Profiles may change. You won’t notice this issue until deployment, which can result in errors like: In field: field – no CustomField named Case.IsStopped found; ERROR running force:source:deploy: Deploy failed.
The data export query can return a maximum of 2,000 records, and import files can include up to 200 records.
In Process Builder, the Queue ID is hardcoded in metadata. Because of this, such components can’t be built and deployed directly. As a workaround, we use a combination of Process Builder and Flow Builder.
Not all metadata types are supported in Salesforce DX, and the list of unsupported types is not fully documented. Here is the list — Unsupported Metadata Types.
We also encountered issues with Communities default navigation. To address this, we added a manual post-release step and updated the .forceignore file accordingly.
Some files removed from the repository are not automatically deleted during sandbox deployments. These need to be removed manually.

Despite these constraints, the advantages of CI far outweigh the drawbacks.

CONCLUSION

SoftServe’s Salesforce CI solution offers a modern, automated alternative to the traditional change-set-based deployment. It promotes collaboration, accelerates releases, and improves overall code quality, helping teams transition toward a more agile, source-driven development model.

Ready to modernize your Salesforce development process? Contact SoftServe to learn how we can streamline your delivery pipeline and development efficiency.

Start a conversation with us

Streamlining Salesforce Development With Continuous Integration