Continuous Integration for Salesforce

CI/CD for Salesforce is one of those things that sounds straightforward until you actually try it.

The core problem: Salesforce development isn't file-based in the traditional sense. Your "code" lives as metadata in an org, not as files in a Git repo. Apex classes, triggers, page layouts, validation rules, workflow rules, custom objects — they all live server-side. Getting them into version control requires pulling metadata through the Salesforce CLI or Metadata API, and the results aren't always deterministic.

Then there's the deployment model. You can't just push code to a branch and deploy. Salesforce deployments are essentially metadata diffs between orgs, and they depend on org state. A deployment that works in your sandbox might fail in staging because someone manually changed a field type through the UI. This happens more often than anyone admits.

We set up a Jenkins pipeline that pulled metadata from a developer sandbox, ran Apex tests, and promoted to a staging org. It worked, but maintaining it was a constant fight against Salesforce's deployment quirks. Still worth it. Without CI, the alternative was developers deploying change sets manually and hoping nothing broke.