Streamlining Salesforce Development With Continuous Integration

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.

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.

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:

1. The developer creates a feature branch and a scratch org to work in an isolated environment.
2. Once development is complete, they create a pull request for peer review and merge it into the master branch.
3. Jenkins automatically detects the changes and deploys them to a shared dev org for team testing and review.
4. 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:

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

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.

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.