by  Oleksandr Vashchenko

Salesforce Continuous Integration

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

By integrating regularly, teams can detect errors quickly, and locate them more easily.

A standard Salesforce metadata-driven development looks like this:

salesforce-ci

This process is based on deploy using change sets and it defines org as source of true with the following disadvantages to consider:

  1. Code might be changed and overridden
    1. All changes that were made during development should be tracked and manually included into change set
  2. No history tracking
  3. Late issue detecting
  4. No code review process
  5. Work with source control systems is not obvious. Code can be changed and released without SCS.

In 2017, Salesforce DX was released, providing a new model: source-driven development. Everything is driven from source code, environments are easily created and disposable, and development is organized around team collaboration.

This new model is better aligned with agile development and international standards (ex. ISO 13485)

Based on Salesforce DX, Jenkins, and PMD, SoftServe built a re-usable CI solution. Now the workflow looks like this:

salesforce-ci-1

The developer creates “feature branch”, creates “Scratch org” and pushes code to it. Now there is an isolated environment to accomplish what is needed. When the work is done, the developer creates a “Pull Request” where code is reviewed and merged to the master branch.

After changes are transferred to master, Jenkins detects it and deploys to org (sandbox) that we call “dev org” to be reviewed and tested by other developers.

To push the latest changes to QA org, the team only needs to make a rebase (or cherry pick) and Jenkins will deploy it.

Benefits:

  • Feature branch workflow
  • Distributed development
  • Pull requests (Code review)
  • Code control
  • Possibility to rollback
  • Fast issue detecting
  • No more overwritten code

Code Analysis

As an additional enhancement to the build process, SoftServe included a static code analyzer called “PMD” in tandem with “Warning next generation” Jenkins plugin. As a result, each commit is analyzed and provides analytics about code quality:

salesforce-ci-2

Examples of rules that PMD checks:

  • Avoid SOQL queries inside loops
  • Avoid DML Statements inside loops
  • Avoid logic in triggers
  • Avoid hardcoding ID’s
  • Code style conventions
  • Apex unit test classes should have at least one System.assert() or assertEquals() or AssertNotEquals() call

Limitations:

Even good SFDX has limitations and disadvantages. Some are listed in official Salesforce documentation, but some are hidden. These include:

  • Dev Hub can be enabled only on orgs without registered namespace
  • Permission sets should be preferred. Salesforce DX + Profiles might become a nightmare. Scratch orgs often add configuration for fields that don’t exist in your org and when you pull sources it will change FLS configuration for profiles. You won’t be able to detect this issue until deployment to some org and the build will fail with an error such as: In field: field - no CustomField named Case.IsStopped found
    ERROR running force:source:deploy: Deploy failed.
  • The query for export can return a maximum of 2000 records. The files for import can have a maximum of 200 records.
  • In the process builder, Queue ID is hardcoded in metadata under the hood. As a result, such code can’t be built and deployed. As a workaround we used Process Builder + Flow builder.
  • Not all types of metadata are supported: Unsupported Metadata Types.
  • Not all metadata that is not supported is listed in documentation.
    We encountered additional issues with Communities default navigation. As a solution we added an additional manual step for post release actions and included .forceignore in the file.
  • Some files removed from repository won’t be automatically deleted during deployment from sandboxes. This should be done manually.

Conclusion

While not perfect, our Salesforce CI has strong advantages over a classic “Change set” deployment procedure but each Salesforce project must take small steps into source-driven development and CI/CD solution. Contact SoftServe today to learn more about our Salesforce CI solutions.