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.
- 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 Force.com migration tool.
- Change Set
- Workbench
- Force.com migration tool (ANT)
- Salesforce DevOps Center
- SalesforceDX
- CI/CD Pipeline
- Jenkines: Setup CI/CD pipeline using Jenkins.
- CumulusCI: Automate the App Lifecycle with CumulusCI.
- Azure DevOps: Check Azure DevOps with Salesforce.
- Gitlab pipelines: Build CI/CD pipeline using Gitlab for Salesforce.
- GitHub Actions: Salesforce DevOps Using GitHub Actions.
- 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.
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.
SALESFORCE DX IN PRACTICE
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.
- Source Driven Development
- Salesforce CLI
- 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.
A Feature-based branching strategy we can have following branches:
- Master – Production Branch
- Hotfix – Branch to handle production issues that needs immediate attention
- Release – Represents the candidate for production (Branch of UAT)
- Develop – Integration Branch where multiple projects merge
- 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
- INTEGRATED DEVELOPMENT ENVIRONMENT (IDE) : As recommended by Salesforce Visual Studio Code is the IDE for all Salesforce Development activities.
- SETUP VISUAL STUDIO CODE : Download the latest version of Visual Studio Code from https://code.visualstudio.com/ and install it.
- SETUP SALESFORCE DX CLI : Go to:- https://developer.salesforce.com/tools/sfdxcli to install Salesforce DX CLI.
- 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.
- INSTALL GIT : download the latest version of Git from https://git-scm.com/download
- CLONE REPOSITORY FROM VCS : Click on Clone button to get the code local.
Developer Workflow
1) CONNECTING WITH YOUR SALESFORCE ORG
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.
2) DEVELOPMENT – SALESFORCE METADATA MODIFICATION
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.
3) COMMIT CODE TO REPOSITORY
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.
- No changes are made into production directly.
- Sandboxes are all refreshed as soon as possible after a release has been pushed to production.
- No use of CHANGE SET.
- All migration are automated.
- All migration scripts are tested.
- Complete regression test is carried out before code is pushed to production.
- Developers need to create a unit test for all code and configuration they develop.
- Try to target the 95% code coverage for Apex Code.
- Have a well-documented release roadmap. A comprehensive communication plan is place for release.
- 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.
- Develop Environment Strategy: Design Sandbox Strategies for your deployment. Learn more about Sandbox Design Strategies for Enterprise Implementations.
- Define your Software Development Lifecycle (SDLC).
- Create Release release management Strategy and deployment calendar.
FAQ’s
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.
Environment Strategy is the planning and practice of allocating and maintaining an Salesforce environments.
Further learning
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
What’s your experience with tools used for DevOps arena for Salesforce. Say for example, Copado?
All tool have there advantage and dis-advantage. I used both AutoRabit and Copado.
Hi Amit— thanks alot for the devops post. Any thoughts on parallel projects development in salesforce.
Great post!
Glad you like this post. I hope this helped your understand the different deployment method in salesforce
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?
Use ANT or DX with CI/CD
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.
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.
Thanks!
-Dustin
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.