Bitbucket Deployment Pipelines

Deployment environments, manual triggers, and promotion

Language / Topic

Bitbucket Pipelines

Rules

Bitbucket Deployment Pipelines · balanced balanced

- Use deployment: <environment> on steps to track deployments in the Bitbucket Deployments dashboard and scope deployment variables

- Configure manual triggers with trigger: manual on deployment steps to require explicit human approval before production deploys

- Use custom pipelines for on-demand operations (database migrations, rollbacks) triggered manually with custom variable inputs

- Build artifacts once in CI steps and pass them via artifacts: to deployment steps — never rebuild code during deployment

- Use size: 2x on resource-intensive build/deploy steps; keep lightweight lint and test steps on the default 1x to conserve build minutes

- deployment: <environment> links a step to a Bitbucket deployment environment (test, staging, production) — enables tracking and scoped variables

- The Deployments dashboard shows deployment history per environment: commit, branch, status, timestamp for full audit trail

- trigger: manual on steps requires a user to click "Run" in the Bitbucket UI — essential for production deployment gates

- The first step in a pipeline cannot be manual; place an automated build/test step before the manual deployment step

- custom: pipelines are triggered manually from the Bitbucket UI or API with optional variables: input fields for runtime configuration

- Custom pipeline variables: users provide values at trigger time (environment, version, dry-run flag) — useful for parameterized deploys

- Artifacts: define artifacts: paths: ['dist/**', 'build/**'] on build steps; subsequent steps automatically receive artifacts from prior steps

- Artifacts vs caches: artifacts pass build output within a single pipeline run; caches persist dependencies across multiple pipeline runs

- size: 2x (4 CPU, 8GB RAM) for builds and Docker operations; size: 4x or 8x for memory-intensive integration tests or large monorepo builds

- Use the Docker service (services: [docker]) for steps that need to build or push container images; allocate memory: 2048 for large images

- Parallel steps for multi-environment deploys: parallel deploy to dev and staging simultaneously, then gate production behind trigger: manual

- Use tags: pipelines to trigger release builds on Git tag push — tags: 'v*' matches semantic version tags for automated release workflows