The process of data migration in Salesforce pertains to the movement of data from one Salesforce instance to another. This may be required when a business upgrades from an older version of Salesforce to a more recent one, or when consolidating several Salesforce instances into a single one. To ensure successful testing and deployment, developers typically use various tools and techniques, such as automated testing, continuous integration, and version control. These processes help identify and fix any issues before releasing the application to end-users. Additionally, developers must follow best practices and adhere to Salesforce's security and compliance guidelines to ensure data privacy and protection.
The Salesforce platform is extremely adaptable and inclusive, allowing businesses to personalize it to suit their individual needs with ease. It offers a diverse range of resources, tools, and an extensive third-party integration ecosystem through the AppExchange marketplace, all of which can be utilized to customize the platform. However, given the complexity of the system, conflicts may occur. When upgrading Salesforce to a newer version, it can conflict with the existing customizations New external systems, APIs, and integrations may clash with already installed integrations New data validation rules can be too strict or inconsistent with existing data, causing issues with data entry and updates Heavy data processing can impact performance Customizations that modify user access controls can lead to security issues By conducting comprehensive testing, the QA team can identify and resolve areas of conflict in a timely manner prior to release, thereby minimizing the adverse effects of bugs on the company's profits. Along with examining customizations, Salesforce testing offers the same advantages as performing typical software testing. Ensure system reliability and stability Minimize risk of system failures, data loss, or performance issues Maintain data integrity in the system Improve user experience by identifying and eliminating friction Ensure compliance and security
Getting the Fundamentals right Before we dive in to the setup and configurations of the DevOps process, we should have a clear understanding of what Continuos Integration (CI) is and what Continuous Delivery (CD) Is. Continuous Integration (CI) is not a tool. It is a practice. It is a practice for integrating the work of all developers into a common codebase. It involves running tests automatically when code is changed. It also involves detecting broken build & tests in few seconds to keep process flowing. Continuous Delivery (CD) is not a tool. It is a practice. It also involves propagating changes from PROD to DEV to keep orgs in sync. Understanding the current Development Model As of today, Salesforce recommends two development models. Package Development Model Org Development Model We need to set the deployment strategy in alignment with the development models. In Package Development Model, Every artefact is bundled into a package and deployed separately Package should be self-sufficient & isolated Requires the organization to have adherence to architectural principles, existence of frameworks, horizontal & vertically sliced concerns addressed Even though Package Development Model appears close to what we want to have, do not force yourself into package development if your organizational practices are not package based. Package Development Model would vision to release features as a package which is vertically and horizontally sliced. Any impacts that occur would only happen in that package/app and it would not affect the other packages/apps. Getting to the package development model maturity itself is a huge effort on its own. In Org Development Model, Artefacts are bundled as functionalities/features for deployment (like a changeset bundle) Deployments are org based and not package based Org Development Model is a common development model that most organizations follow. Every feature developed would be bundled into a changeset and be deployed to an org. Post deployment, QA would do a smoke testing and a regression testing just to ensure nothing in the org is impacted. Now, let’s define the problem statement. ABC Company uses Salesforce CRM for their business. They have a development team that develops functionalities as per business request in a Developer Sandbox. The team lead/team manager/deployment manager collects the list of items developed for each functionality from the developer, prepares changeset and deploys to QA Sandbox when it is ready for QA testing. After QA testing is pass, those functionalities are queued for PROD deployment which happens once every 2 weeks. The team lead/team manager/deployment manager again creates the changeset for PROD deployment and executes them every 2 weeks and initimates the organization stakeholders. For your information, they use Azure repositories for code management for their website development team. Key items to consider for deployment strategy It is clear that ABC company uses Org Development Model. So, we need to understand that anything related to package development model (even though it is fancy and attractive) should not be forced. They already use Azure repositories for version control needs. So, it is worth using Azure repo for SF code management. Azure has out of the box features for Devops which is called Azure DevOps services. This can be used as a tool for CI/CD. Things that we need before we start the DevOps configurations Salesforce Developer Org [if you don’t have one, signup and get a free personal dev org] Developer Azure account [just go to dev.azure.com and register with your microsoft personal email address] Salesforce CLI installed locally Visual Studio Code installed locally with “Salesforce Extension Pack” installed. Git (either via npm or as installer)
In this step, we will pull the codebase from salesforce and organize it in the way we want to version
control it. Then, we will commit this code to the Azure Git repo we created in Step 3.
Create a folder named “Projects” in your local machine
Open the terminal/command prompt from this “Projects” folder.
Execute the following command for creating an empty SFDX project locally
sfdx force:project:create --projectname MyPersonalDevOrg
cd into the newly created project folder
cd MyPersonalDevOrg
Create a folder named “manifest”
mkdir manifest
Type the following command to open the project in VS Code.
code .
Create a file named “package.xml” inside the manifest folder.
Open the “package.xml” file and paste the following contents. Essentially, we are saying that we are
interested in Apex Classes, Apex Triggers, Visualforce Pages and Custom Objects only. You can add more
metadata to “package,xml” file as per your needs.
In this step, we will create the azure pipeline which will build, test and deploy the committed codebase from azure git repo to Salesforce Cloud. Here, we will use the latest SFDX CLI techniques to deploy instead of the old school ANT migration scripts. In the Azure Project page open in the browser, navigate to “Pipelines” tab. Click on “Create Pipeline” Choose “Azure Repos Git” for “Where is your code?” Choose “SF DevOps” project for “Select your repository” Choose “Starter Pipeline” for “Configure your pipeline” Overwrite the code shown in “Review your pipeline YAML” and paste the following code. (Note: a usual mistake that people do is to copy-paste the pipeline code and mess up the indentation of the yml code. If indentation is not right, you will have a tough time running the pipeline.) # Starter pipeline # Start with a minimal pipeline that you can customize to build and deploy your code. # Add steps that build, run tests, deploy, and more: # https://aka.ms/yaml trigger: batch: "true" branches: include: - master paths: exclude: - README.md - azure-pipelines.yml pr: autoCancel: "true" branches: include: - master paths: exclude: - README.md jobs: - job: Deploy condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master')) steps: - task: UseNode@1 - bash: npm install sfdx-cli --global displayName: Install Salesforce CLI - bash: sfdx force:auth:jwt:grant --clientid $(salesforceDevOrgClientId) --jwtkeyfile ./buildfiles/server.key --username $(salesforceDevOrgUserName) --instanceurl $(salesforceDevOrgInstanceURL) -a devOrg displayName: Authorize salesforce org - bash: sfdx force:source:convert -r ./force-app -d ./toDeploy displayName: Convert to deploy source - bash: sfdx force:mdapi:deploy -l RunLocalTests -c -d ./toDeploy -u devOrg -w 10 displayName: Run validation on source code - bash: sfdx force:mdapi:deploy -l RunLocalTests -d ./toDeploy -u devOrg -w 10 displayName: Deploy source code to Dev Org
We define 1 job called “Deploy” with a set of steps/tasks. Install SF CLI on the azure vm so that we can execute SFDX commands. Authorize the Dev Org and ensure that we can login using clientId, server.key and username Convert the SFDX code in “force-app” directory to metadata format for deployment Run a Validation using the converted code in metadata format using SFDX Deploy the converted code in metadata format using SFDX Click on the “Variables” button and create the following variables salesforceDevOrgClientId = paste the client id from the connected app we created in Step 2 salesforceDevOrgInstanceURL = https://login.salesforce.com salesforceDevOrgUserName = type the username of your developer org Click on “Save & Run”. You will see the pipeline starting to run. You can click the build instance and see what the azure pipeline is doing while it is executing the commands. After the pipeline is executed, you can open the Salesforce Org in browser and navigate to Setup -> Environments -> Deploy -> Deployment Status. Here, you will see a recent Deployment Validation Success & a Deployment Success. Run the following command in terminal/command prompt to pull the pipeline yml file to vscode locally. git pull origin master This completes the setup of Azure DevOps pipeline for automating Salesforce deployments. **From now on, you just need to ** open the project code in VS Code add/modify the code run the following commands to commit your code changes to azure git repo git add . git commit -m "commit message" git push origin master the azure pipeline will automatically detect that a commit was made and it will automatically run the azure pipeline to deploy the code. even if the pipeline succeeds or fails, you will get an email notification regarding the latest build status