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.
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
- Force.com migration tool (ANT)
- Salesforce DevOps Center
- CI/CD Pipeline
- 3rd Party tool.
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.
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.
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.