Post

Part 1: Implementing CI/CD in Salesforce with the Org Development Model

Using the Org Development Model is my go-to strategy for managing Salesforce deployments. It’s straightforward and effective, particularly for setups requiring distinct development environments.

Environment Setup

Desktop View Three-org model used in this tutorial

I’ve configured three Salesforce Developer Edition orgs to mimic typical environments in a CI/CD pipeline:

  1. LucidSF_Prod: Simulates the Production environment, housing stable, verified code.
  2. LucidSF_Integration: Acts as the Integration environment for merging and testing code.
  3. LucidSF_Develop: The Development environment where new features and fixes are built and tested.

You can create several Developer edition orgs to follow along by signing up for an org here: Developer Edition Signup

These orgs help ensure a smooth workflow from development to production.

Version Control with GitHub

The project is managed through a GitHub repo, initialized from a clean org. Key components tracked include:

  • Apex Classes: Server-side business logic.
  • Flows: Declarative automations.
  • Flexipages: Custom page layouts.
  • Objects: Custom object schemas.
  • LWC Components: Lightning Web Components for a better UI.

Version control in GitHub keeps our codebase organized and auditable.

CI/CD Workflow

  1. Develop in LucidSF_Develop: Changes are built and committed to GitHub.
  2. Test in LucidSF_Integration: Merged code is tested to catch conflicts.
  3. Deploy to LucidSF_Prod: Stable code is pushed to production.

Desktop View From development to deployment workflow

Collaborative Development Workflow

In the image I’ve shown, you can see a representation of how multiple developers (example, 3 developers) would collaborate within our CI/CD pipeline. Here’s a breakdown of the process:

  1. Individual Development: Each developer works on their own feature or bug fix. When ready, they create a pull request (PR) to share their changes with the team.
  2. Code Review: The pull requests are reviewed by a tech lead or senior developer. This review process ensures code quality and adherence to best practices. Feedback is provided, and once the changes are approved, they are merged into the main branch.
  3. Integration Testing: The merged code is then deployed to the LucidSF_Integration org. Here, thorough testing takes place to verify that new features integrate seamlessly with existing functionality.
  4. Deployment to Production: If the code passes all integration tests, it is deemed stable and is pushed to the LucidSF_Prod org. This way, only thoroughly tested code reaches the production environment, ensuring reliability for end users.

Check out Part 2 of my blog where we set up CI/CD pipelines for the LucidSF_Integration and LucidSF_Prod orgs

This post is licensed under CC BY 4.0 by the author.