You promote work items through a pipeline, which defines the sequence of stages that work items progress as they go through the release lifecycle from development to production (or some other final stage). You can have any number of pipeline stages. Your team manager built the pipeline when configuring DevOps Center.
Each pipeline stage corresponds to an environment (currently a Salesforce org), and a branch in the source control repository. Depending on how your pipeline is configured, changes move through the pipeline when individual work items or a grouped set of work items (work item bundle) is promoted. Upon promotion, changes are merged from the current stage branch to the next stage branch, and then are deployed to the next stage org.
At a minimum, we recommend that your pipeline has one test stage and a production stage. However, it’s common to have two to three test stages, often called something like integration, UAT (user acceptance testing), and staging.
Your team manager can configure your pipeline in one of two ways:
- Allow you to move work items individually through the entire pipeline.
- Allow you to move work items individually in early stages of the pipeline, and as a work item bundle in later stages. The point in the pipeline when you transition from the more flexible individually selectable work item promotion to the more predictable versioned promotion is referred to as the bundling stage. When changes are promoted from the bundling stage to the next stage, all work items that haven’t yet been promoted are included in the versioned work item bundle and promoted as a unit. This versioned work item bundle continues to be promoted as a consistent unit through subsequent stages when you perform a promotion.
Your pipeline configuration determines how many stages allow you to promote individual work items.
- Stages that allow you to promote individual work items have the Promote Selected button at the top.
- Stages that allow you to promote a versioned work item bundle have the Promote Work Item Bundle or Promote Work Item Bundles button at the top.
- The bundling stage, where the versioned bundle is created, has the Promote as Work Item Bundle button at the top.
Special Characters in Metadata Component Names
When naming metadata components, DevOps Center and its underlying technologies support a subset of special characters. To avoid issues when deploying or promoting metadata to a pipeline stage, we strongly suggest using only supported special characters in your component names. See Supported Special Characters in Metadata Component Names for details.
Components in Managed Packages
Due to packaging manageability rules, you can’t promote or modify most components that are installed in a managed package.
Best Practices for Non-Bundled Pipeline Stages
Ideally, it’s best to keep work items moving through your pipeline so they don’t stack up. If your team practices result in numerous work items in a stage, consider adding a bundling stage. To ensure that DevOps Center can efficiently process all the selected changes, follow these guidelines to avoid promotion errors.
- When promoting work items from the Approved Work Items list to the first pipeline stage, select up to approximately 20 work items at a time.
- When promoting work items from a non-bundled pipeline stage to the next pipeline stage, select up to approximately 30 work items at a time.
- Limit the total number of work items to approximately 50 or fewer for each non-bundled pipeline stage.
For work items in the Approved Work Items list, you have options to reduce the number of work items in your list. See Work Item Management for details.
Limit for Bundling Pipeline Stage
Limit the total number of work items to approximately 50 or fewer for the bundling pipeline stage.
- Promotion Options
The available promotion options depend on if you’re promoting individual work items, work item bundles, or performing a validate-only deployment. - Promote Individual Work Items
After a work item is considered “ready to promote,” it’s added to the Approved Work Items list. You can then promote individual work items to the first pipeline stage. - Promote Individual Work Items as a Work Item Bundle
During pipeline configuration, your project manager can define a stage as the bundling stage. Instead of selecting individual work items to promote, you promote work items in this stage as a work item bundle. All unpromoted work items in this stage become part of the bundle. - Promote All Work Item Bundles
When you promote work item bundles, all unpromoted versioned bundles are promoted together to the next stage. The unpromoted work item bundles and corresponding work items are listed in this stage. - Run a Validate-Only Deployment
To ensure a successful deployment ahead of time, create a validate-only deployment. You can create a validation for only the bundling stage and versioned stages. You can run a validate-only deployment within DevOps Center or using Salesforce CLI. - Promote Changes Merged Outside of DevOps Center
If you merge the change request in the source control system, the changes are in a partially promoted state because they’ve been merged but not yet deployed to the associated pipeline environment. You can complete the promotion in DevOps Center or use Salesforce CLI. - Deploy Changes Using Salesforce CLI (Beta)
Use Salesforce CLI to deploy changes to a pipeline stage’s environment or to perform a validate-only deployment. You must externally merge any changes in the source control repository before you can perform the deployment using the CLI. While the CLI command runs, you can see the progress of the promotion reflected in the DevOps Center Pipeline Stages tab. - View Promotion Status
When promotion completes, you see a success banner or a failure banner where you can see details of the error. You have several options to validate the promotion or dig into errors. - View Deployment Status to Dig Deeper
If the deployment error doesn’t provide sufficient information, you can see more details in the Deployment Status in the org. - Fix a Stalled Promotion When the Promotion Succeeded
If DevOps Center deployed the changes to the target environment and merged them into the target stage branch, but the promotion doesn’t appear as completed in DevOps Center, update the associated records to reflect the successful result. - Fix a Stalled Promotion When Deployment Succeeds But the Branch Merge Fails
If DevOps Center deployed the changes to the target environment but didn’t merge them into the target stage branch, set the associated async request record status to Error. Then refresh the pipeline and try the promotion again. - Fix a Stalled Promotion When the Promotion Failed
If a promotion failed before DevOps Center deployed the changes to the target environment or merged them into the target stage branch, set the associated async request record status to Error. Then refresh the pipeline and try the promotion again.