💡 To use Gearset Pipelines you will need an Automation licence.
What is the advantage of using an automated Gearset Pipeline?
Gearset Pipelines form part of the end to end DevOps lifecycle, introducing automation to your deployment landscape and allowing a team to fully leverage the advantages of version control and automated deployments.
Many teams struggle to manage their Revenue Cloud implementations as they scale not because of the complexity of the configuration (although this is also a consideration) but because of the classic challenges that confront all Salesforce teams -
overwritten changes
unclear change management processes
increasing overhead from a ballooning list of manual steps
These are problems that DevOps solves, not just through the application of a version control and automated deployments but through an understanding of those as part of the wider DevOps lifecycle.
💡 Security, testing, collaboration and automation are all critical DevOps practices and should be applied throughout the lifecycle — not just at one stage. That’s why these four things are featured in the “halo” around Gearset’s DevOps lifecycle diagram.
How can I start using Gearset Pipelines for my Revenue Cloud configuration?
We recommend the following steps are completed before setting up your pipeline to automatically deploy Revenue Cloud (Salesforce CPQ or Agentforce Revenue Management/Revenue Cloud Advanced) configuration.
Before you start
We recommend familiarising yourself and your team with the process of comparing and deploying your Revenue Cloud (Salesforce CPQ or Agentforce Revenue Management/Revenue Cloud Advanced) configuration data from org to org before introducing it to your Pipeline. This will allow you and your team to become familiar with the way the dependency analysis and deployment sequencing works before those processes are automated as part of the pipeline.
Make sure you have completed the External ID setup process using the Gearset External ID setup wizard. This introduces a unique External ID to all of your Revenue Cloud records, allowing Gearset to track them as they move between environments and treat them in the same way as metadata. You will need to run the wizard on all of the orgs you intend to use as part of your pipeline, as Gearset will not deploy the configuration data if either the source or target do not have a Gearset External ID field, to prevent duplicates being created.
Assess whether you need to align the IDs between your orgs. Gearset derives the Gearset External ID from the Salesforce Record ID, the same record created in two different orgs (by hand or by a non-Gearset deployment) will have a different Salesforce Record ID, and therefore different Gearset IDs. You can use Gearset to align your IDs, or use the sandbox refresh approach to make sure that you are starting from a place of alignment.
Setting up a pipeline for Revenue Cloud deployments
Before you begin, if you would like to become more familiar with Gearset Pipelines as a concept and how you can leverage them please get in touch over the in app chat to arrange a demo.
Populate the Revenue Cloud metadata and configuration data into the master branch of your repository. Revenue Cloud configuration data you intend to be configurable through your Pipelines process should be included here. To learn more, use this guide: Comparing and deploying Revenue Cloud configuration with source control
Note: To ensure good performance from your repo, we recommend that the size of Revenue Cloud configuration data in your repository should not exceed 1GB. Typically, this would correspond to an upper limit of approx. 1 million pricebook entries, or around 20,000-30,000 products.
Ensure that this Revenue Cloud configuration data is aligned across all branches which underpin orgs in which Revenue Cloud is actively used.
If using a new repo with a new pipeline, push Revenue Cloud config data to the master branch alongside metadata, then create your other Pipelines branches from this to ensure alignment.
If you have an existing repo, create pull requests to push the Revenue Cloud config data from the master branch to the other branches in use - as the External IDs are already aligned (if they are not please see the previous section), this should simply ensure that the config data in the branch matches that already in the orgs.
Create new CI jobs for each environment in which Revenue Cloud is actively used alongside core metadata, including Revenue Cloud metadata types required, alongside with the configuration data objects.
Note 1: For Salesforce CPQ, ensure you also have the SBQQ CPQ managed package selected in the right hand side of your metadata filter.
Note 2: If you wish to use existing CI jobs, the first run for the job after adding Revenue Cloud components to the metadata filter will attempt to deploy all Revenue Cloud items in the repo to the target which is why we recommend new CI jobs.
Add these new CI jobs into your pipeline, replacing the static environments. Any PRs open against the branches here will be preserved. If setting up your pipeline for the first time, see the following document and incorporate Revenue Cloud into your CI jobs here when setting them up: Setting up your first Gearset pipeline.
Start using Revenue Cloud in Pipelines! You can create PRs with Revenue Cloud configuration data and Salesforce metadata - on merging to the first branch and deploying to the org, the PR is raised against the next Pipeline environment in the same way as with any other PR.
We recommend that teams use Delta CI with Pipelines for Revenue Cloud in the same way as is recommended for metadata-only jobs. This way, only the new changes will be deployed when you push changes.
Considerations for the deployment of configuration data
Although Gearset will for the most part treat configuration data in the same way as metadata, allowing it to be source controlled and subject to dependency analysis, there are some key differences in the way it is treated in Pipelines to account for the fundamental differences between the configuration data and actual metadata.
Pull request Validations
Validations will be run on metadata in a pull request (PR), but not on the Revenue Cloud configuration data, as the metadata API cannot be used to validate data deployments. If the metadata passes validation, the PR can be merged and deployment started, but if there are issues with the Revenue Cloud deployment, this may cause the deployment to be only partially successful.
Partially successful deployment due to Revenue Cloud deployment failure
If a Revenue Cloud deployment fails to deploy some configuration data, this status is shown in the Pipelines UI for the deployment. Any errors here can then be found and remedied as needed.
If a deployment has only partially succeeded Gearset will display an error message next to the records that have failed to deploy, along with an annotation to help the user understand the error and resolve it.
Adding new fields to Revenue Cloud records
When you update the metadata of your Revenue Cloud objects (for example, adding a new field to the Product2 object) this will also update all of the records stored on that object, as they now have a new field.
If you add a new field to a single Revenue Cloud record (for example a Product) then Gearset will add this new field to all of your Revenue Cloud Products in order to keep them in sync. This may show in the CI Job History as a deployment of many more Revenue Cloud components than is expected, but this is a required step by Gearset to keep your environments and orgs up to date.
Gearset will add this new field as empty so that it doesn't affect the org and these additions will not show in the git commit history of the PR.
Call for feedback
We're always eager to hear user feedback, and to understand how we can best support your team. Please get in touch over the in-app chat if you have any questions or feedback for us!