Development and Deployment Process

In this post we will cover Development/deployment guide for Salesforce related Projects. We will cover standard project development lifecycle, environments management and the criteria that is to be met before moving to a higher/production environment including Salesforce Branching Strategy. We should ensure that all development, testing, remediation, and propagation of code fall in line with the deployment process and ensure a stable development life cycle.

The process outlined will serve as a standard for changes made in any of the current Salesforce instances, Sales Cloud, Service Cloud, and Community Cloud. Let see different option for Salesforce Deployment.

Development process

Let’s start with the deployment process. Developing applications on the Salesforce platform is fast and easy. It is recommended that if possible the whole release management process is completely automatic and this document outlines the process to deliver this. The below image describes the process of project management which include how we can manage the environment management, Agile methodology, and release management.

Development Process flow in Salesforce
  • Backlog : This is the gathering of ideas, requirement and prioritization of requirement.
  • Development Process : This is the process of implementing the defined requirement as defined within the backlog.
  • Release Management : This is the process of managing the completed application/enhancement into production.

Salesforce Deployment Methods

Release management provides a framework to control when and where changes are promoted from one Salesforce organization to another. You can set up the CI/CD process to move a change from one organization to another. Whether from a developer sandbox to integration testing or from user acceptance testing (UAT) to production, release management is the framework to enable effective organizational control, and should be implemented alongside your deployment management process.

There are a number of tools currently used to manage the Salesforce deployment of these applications, including change sets and the migration tool.

  1. Change Set
  2. Workbench
  3. migration tool (ANT)
  4. Salesforce DevOps Center
  5. SalesforceDX
  6. CI/CD Pipeline
  7. 3rd Party tool.
    • Copado
    • Flosum
    • AutoRabit
    • Gearset

There are many more option are available in market for Salesforce deployment. You can select which tool you like base on your client requirement and budget.

Salesforce DevOps Tools

There are different DevOps Tools are available. Which can be divided into the below category. Learn more about Salesforce DevOps Tool in our Salesforce DevOps Post.

Salesforce DevOps Tools
Salesforce DevOps Tools

Development Process Flow in Details

One of the most important parts of the software development lifecycle is the testing of the migration of the code and configuration from sandbox to sandbox and to production after UAT. Below document show how we can follow the end to end development process during plan, code, build, test and release process.

Development Process Flow in Details.


Salesforce DX is a set of tools and features that improve the efficiency of development during the application lifecycle. It addresses common challenges faced by developers, allowing them to manage the source of truth and lifecycle for the org. With its accessible and useful tools, development teams can easily work with command line interfaces (CLIs) or integrated development environments (IDEs). Below are the core features.

  1. Source Driven Development
  2. Salesforce CLI
  3. Modular Metadata and code

The included tools for Salesforce DX are designed to improve the Application Lifecycle Management (ALM) process at every stage.

Branching Strategy in Salesforce

A branching strategy is a set of rules, that describes when branches are created, naming guidelines for branches, what use branches should have, and so on. This is a the toughest part for any DevOps implementation. We would like to light a few advantages of a good branching strategy. Below is the branching Strategy for Salesforce Development we can follow.

branching Strategy for Salesforce Development

A Feature-based branching strategy we can have following branches:

  1. Master – Production Branch
  2. Hotfix – Branch to handle production issues that needs immediate attention
  3. Release – Represents the candidate for production (Branch of UAT)
  4. Develop – Integration Branch where multiple projects merge
  5. Feature – Project features (Branch for each project.)

Branch Naming Convention

All branches should have a clearly defined names with release number. This naming conventions should follow the company standard. For Examples

  • <Org_Name>.Release.<versionNumber> for release.
  • <Org_Name>.Integration.<VersionNumber> branch for testing and UAT.
  • <Org_Name>.Team.<VersionNumber> for team base branch
  • <Org_Name>.BreakFix.<Version Number> branch for the scrum team working on break-Fix release.

Developer Workflow – One Time Setup

  1. INTEGRATED DEVELOPMENT ENVIRONMENT (IDE) : As recommended by Salesforce Visual Studio Code is the IDE for all Salesforce Development activities.
  2. SETUP VISUAL STUDIO CODE : Download the latest version of Visual Studio Code from and install it.
  3. SETUP SALESFORCE DX CLI : Go to:- to install Salesforce DX CLI.
  4. INSTALL SALESFORCE EXTENSION PACK : Install the Salesforce Extensions Pack: this extension can be downloaded in VSC by going to the extension icon on the left side. Search for the Salesforce Extension Pack and click on the first result.
  5. INSTALL GIT : download the latest version of Git from
  6. CLONE REPOSITORY FROM VCS : Click on Clone button to get the code local.

Developer Workflow


Now, as you’ve installed Salesforce DX CLI, VS Code and all the required extensions, have the local git code Repo you’re good to connect your IDE with your Salesforce Org. To do so, use command:- Ctrl + Shift + P and type Authorize an Org. Here, we’re going to connect with our dev org or a sandbox. You’ll see the first option as:- Authorize an Org and press enter.


Want to learn about how to setup vs code with Salesforce check this post.


Based on the user story assigned to you identify the components and create/modify the components in the Salesforce environment ( Or by Vs Code). Specify the metadata component details in the package.xml file under manifest folder. Once the development and unit testing is completed commit the code into your project branch.


The next step is to get all your classes, triggers and other required files in our IDE. To do so, open package.xml from the manifest subfolder present in the left pane. Right click anywhere in package.xml and click the option:- SFDX: Retrieve Source in Manifest from Org . Make sure you are connected to the correct branch in your VSCode. Stage and Commit your changes fro VsCode. Learn about GIT Command here.

Release Strategy Best Practices

We should follow the below key release management best practices.

  1. No changes are made into production directly.
  2. Sandboxes are all refreshed as soon as possible after a release has been pushed to production.
  3. No use of CHANGE SET.
  4. All migration are automated.
  5. All migration scripts are tested.
  6. Complete regression test is carried out before code is pushed to production.
  7. Developers need to create a unit test for all code and configuration they develop.
  8. Try to target the 95% code coverage for Apex Code.
  9. Have a well-documented release roadmap. A comprehensive communication plan is place for release.
  10. The release process is managed by a Release Manager who is independent of any scrum team.

Salesforce deployment best practices

Here are some Salesforce deployment best practices.

  1. Develop Environment Strategy: Design Sandbox Strategies for your deployment. Learn more about Sandbox Design Strategies for Enterprise Implementations.
  2. Define your Software Development Lifecycle (SDLC).
  3. Create Release release management Strategy and deployment calendar.


How do we deploy in Salesforce?

There are different way to deploy component in Salesforce, We can use 1) Change set, 2) Metadata API 3) SalesforceDX or 4) Salesforce DevOps tools.

What is Environment Strategy in Salesforce?

Environment Strategy is the planning and practice of allocating and maintaining an Salesforce environments.

Further learning

  1. Salesforce Org Strategy
  2. Governance model required in SF projects

Check out the our YouTube, and don’t forget to subscribe to our channel, so that you’re notified right away when a new video is available

Amit Chaudhary
Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates.

He is a active blogger and founder of Apex Hours.

Articles: 465


  1. Hi Amit— thanks alot for the devops post. Any thoughts on parallel projects development in salesforce.

    • Glad you like this post. I hope this helped your understand the different deployment method in salesforce

  2. Hi Amit,
    3. No use of CHANGE SET.
    So, with the above line, you are not recommending to deploy in production with Change Set. Rather, you are recommending to use CI/CD. Is my understanding correct?

  3. Good post although testing needs to shift left and there seems to be no mention of design approvals/design review before going straight into development. I would want to focus more on quality.

    • Yes I did not included that point in this post. But included Governance model required in Salesforce projects for further learning. For that Architect and Tech Lead come into picture. Salesforce Architect design the solution and present to design Authority and got approval Then Technical lead need to put tech spec on Jira ticket. Same ticket developer will take for development.

  4. Hi Amit,

    This is great – a few questions/thoughts:

    1. After features are merged into their respective branches, is the entire branch deployed to the target org, or only the updates for the features that have been merged into the branch? If deploying feature updates only, how is this being accomplished within the process? I know that you can use commercial tools to achieve delta deployments/ only deploy the changes that have been committed to a feature branch – wondering how this can be accomplished with SFDX, ANT (+ other open source tools).

    2. What happens if you merge the features into their respective branches, and then the deployment fails – are you surgically updating/removing metadata or code that is causing the failures in the branch itself? On top of that, are you sending the feature back to Dev to fix the issues that caused the deployment to fail?

    3. Where is the feature branch being created from in this process, master/main?

    4. I would think we would want to automate the creation of feature branches, retrieval of the metadata from the source org, the commit of the metadata into the feature branch, running static code analysis, as well as the unit testing. On top of that, I would suggest automating the pull request, so it automatically performs a validation against the target org environment, and automate regression/functional/integration testing, and finally automate the merging of feature branches into target branches if testing is successful.


    • Here is my thought
      1- It depend on your pipeline. I recommend delta deployment.
      2- We should always have build check before merging the branch. To confirm make sure deployment dont failed.
      3- Master
      4- Yes we can do that.

Leave a Reply

Your email address will not be published. Required fields are marked *