Skip to content

How to wire a repository into CI

Take a repository that already contains the toolchain and make its pipeline run on Bitbucket. For the branch/environment reasoning behind these steps, see the branch, environment and org model.

Enable Pipelines

In Repository settings → Pipelines → Settings, enable Pipelines for the repository. Bitbucket admin privileges are required for this and the steps below.

Create the deployment environments

The pipeline deploys through named Bitbucket deployment environments, referenced by deployment: in bitbucket-pipelines.yml. In Repository settings → Deployments, create:

  • sit
  • uat
  • production

Names must match bitbucket-pipelines.yml exactly. See the pipeline reference for which step deploys to which environment.

Set the auth URLs

Each stage org and the DevHub authenticate from an SFDX auth URL stored as a repository variable. Follow how to authenticate CI to an org to obtain and store:

  • DEVHUB_AUTH_URL
  • SIT_AUTH_URL, UAT_AUTH_URL, PRODUCTION_AUTH_URL — repository variables; the deployment environments (sit, uat, production) need no variable copies of their own

Enable deployments

Add the repository variable:

SF_DEPLOY_ENABLED = 1

Without it, deploy steps run as a dry run — see the environment variable reference for the exact behavior. Scope the variable to individual deployment environments instead of the whole repository if you want to turn deployment on for some stages before others.

Set the optional opt-ins

None of the following are required for a first run:

  • Delta deployments per stage — how to enable delta deployments for a stage
  • Pooled scratch-org validation on pull requests — how to validate a PR against a scratch org
  • Quick-deploy build statuses — BITBUCKET_ACCESS_TOKEN, covered in how to authenticate CI to an org
  • Git-bot content sync pipelines (Sync Content, Sync Email Templates) — add BASE64_BOT_PRIVATE_KEY as a repository variable (the base64-encoded SSH key for the bot account)
  • Daily dependency audit — schedule the custom pipeline Audit Node Dependencies daily on the default branch (Repository settings → Pipelines → Schedules); it catches advisories published after a lockfile merged

The full variable set is in the environment variable reference.

Push and watch the first run

Push to the branch you want to exercise — see the pipeline reference for exactly which steps that triggers. Open Pipelines on the repository to watch the run and confirm the expected steps triggered.

Confirm before merging pull requests

Open a pull request against develop before relying on the pipeline for real work. It runs Validate against Org unconditionally, confirming the auth URL and deployment environment for that stage resolve correctly, even with no opt-ins set.