Using Deployment Variables Based on Tenant Selection in a Bitbucket Custom Pipeline

[Dattatray Sable]

I have a Bitbucket custom pipeline that consists of multiple steps. The deployment steps and pipeline logic are the same for multiple test tenants; only the tenant-specific configuration differs.

My requirement is to configure two deployment environments, for example:

• tenant1
• tenant2

I want to store tenant-specific values such as Azure client ID, client secret, tenant ID, subscription ID, etc. as Deployment Variables for each environment.

At the same time, I have some common/shared values that should remain as Repository Variables.

The desired flow is:

1. A developer or QA runs the Test custom pipeline.
2. They select which tenant they want to deploy to (tenant1 or tenant2).
3. The pipeline should automatically resolve:
   • Tenant-specific values from the selected Deployment Variables
   • Common values from Repository Variables
4. All pipeline steps should remain the same; I don't want to duplicate the pipeline or deployment logic for each tenant.

For example:

Custom Test Pipeline
        |
        |-- Select Tenant
        |      |
        |      +-- tenant1
        |      |      └── Tenant 1 Deployment Variables
        |      |
        |      +-- tenant2
        |             └── Tenant 2 Deployment Variables
        |
        +-- Same pipeline steps
               |
               +-- Shared values → Repository Variables
               +-- Tenant values → Deployment Variables

Is there a supported way in Bitbucket Pipelines to dynamically select a Deployment environment based on a custom pipeline variable, so that the selected environment's Deployment Variables are automatically made available to all steps?

For example, something conceptually like:

pipelines:
  custom:
    deploy-test:
      - variables:
          - name: TENANT
            allowed-values:
              - tenant1
              - tenant2

      - step:
          deployment: $TENANT
          script:
            - ./deploy.sh

I understand that deployment: may need to be statically defined in the YAML. If dynamic selection is not supported, what would be the recommended Bitbucket approach for this use case while avoiding duplication of the actual deployment steps?

I would particularly like to keep the secrets in Deployment Variables rather than Repository Variables, since they are tenant-specific.

[Mark C · Accepted solution]

Hi @Dattatray Sable

Welcome to the community.

The short answer is no, the deployment keyword in Bitbucket Pipelines must be a static string. You cannot use a variable like $TENANT there because Bitbucket needs to resolve the environment (and its associated permissions and secrets) before the step starts execution.

To keep your configuration DRY (Don't Repeat Yourself) while still using Deployment Variables and the Deployment Dashboard, the standard workaround is to use YAML Anchors and Aliases.

This allows you to define your deployment logic once in a template and then "call" it for each specific environment. Here is how you can structure your bitbucket-pipelines.yml:

definitions:
  steps:
    - step: &deploy-logic
        name: Deploying to Tenant
        script:
          - echo "Deploying to $BITBUCKET_DEPLOYMENT_ENVIRONMENT"
          - ./deploy.sh --client-id=$AZURE_CLIENT_ID # This pulls from the specific environment
        # ... add the rest of your shared logic here

pipelines:
  custom:
    deploy-tenants:
      # You still need to define a step for each environment to 
      # map the Deployment Variables correctly.
      - step:
          <<: *deploy-logic
          deployment: tenant1
      - step:
          <<: *deploy-logic
          deployment: tenant2

Why this is the recommended approach:

• Security: It correctly maps to your Deployment Variables, ensuring secrets like Azure Client IDs stay masked and environment-specific.

• Tracking: Each tenant gets its own entry and history on the Deployment Dashboard.

• Maintenance: You only have to update your deployment script in one place (the anchor definition).

One thing to keep in mind:
If you eventually have a massive number of tenants (e.g., 50+), this YAML file will become quite long since you still need one step entry per environment. If you reach that scale, you might want to look into OpenID Connect (OIDC) to fetch credentials dynamically from Azure based on a script variable, though you would lose the individual tracking on the Bitbucket dashboard for each tenant.

Hope this helps.

Regards,
Mark C

[Aron Gombas _Midori_]

I don't think that you have the required flexibility with the built-in feature, but the Pipeline Forms app could be a great match to your use case.