CI/CD setup for websites via Bitbucket Pipelines

CI/CD setup for websites via Bitbucket Pipelines

We often encounter projects where deployments are done manually via FTP — leading to errors and lost time. In one Symfony project, manual deployment took 40 minutes and every fifth release had to be rolled back due to a forgotten migration. After implementing Bitbucket Pipelines, the process was reduced to 8 minutes, and failures dropped to zero. Moreover, the team stopped spending time coordinating releases — the pipeline performs all checks automatically.

We configure CI/CD in Bitbucket Pipelines so that each build runs static analysis, unit tests, and integration checks, then autonomously deploys to the server. This not only speeds up releases but also eliminates human error: forgotten migrations, incorrect configs, missing dependencies.

Problems we solve

• Different environments: staging and production often have different configs. Pipelines allows setting distinct variables for each deployment environment.
• Long manual deployments: one click and the build with tests starts automatically. No waiting for a developer.
• Configuration errors: frequently mixed up SSH keys or forgotten dependencies. We define everything in the YAML, and the after-script notifies about issues.
• Lack of tests: many projects lack automated checks. We integrate static analysis, unit tests, and linters directly into the pipeline. For example, for a React 18 TypeScript frontend project we added ESLint, Jest, and Playwright — the pipeline immediately catches regressions.

How CI/CD works in Bitbucket Pipelines

Bitbucket Pipelines is built into the repository — no separate CI server needed. You describe steps in a bitbucket-pipelines.yml file, and Bitbucket runs them inside a Docker container. Compared to GitLab CI, setup takes roughly half the time: no need to manage runners. You get 50 free build minutes per month; paid plans remove limits (starting at $10/month).

Setup process

1. Repository audit: determine the tech stack, tests, and environments.
2. Create bitbucket-pipelines.yml: write steps for build, test, and deploy.
3. Configure variables: set secrets (SSH keys, tokens) in Repository Settings.
4. Configure environments: create staging and production with manual approval.
5. Testing: run the pipeline on a test branch.
6. Documentation: describe the launch and rollback process.

Example: basic configuration for Node.js and deploy via rsync

image: node:20-alpine pipelines: branches: main: - step: name: Test caches: - node script: - npm ci - npm test - step: name: Build caches: - node script: - npm ci - npm run build artifacts: - dist/** - step: name: Deploy deployment: production script: - apt-get update && apt-get install -y openssh-client rsync - mkdir -p ~/.ssh - echo "$SSH_PRIVATE_KEY" | base64 -d > ~/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts - rsync -avz --delete dist/ deploy@$DEPLOY_HOST:/var/www/mysite/ pull-requests: '**': - step: name: Test PR script: - npm ci - npm test - npm run lint 

Advanced features

Environment variables and artifacts

Variables are stored in Repository Settings → Repository variables. The secured flag hides the value from logs. Artifacts pass files between steps, e.g., dist/ and .env.production. They are retained for 14 days, enough for debugging. Comparison of settings for environments:

Parallel steps and manual trigger

Parallel steps speed up the pipeline — tests, linter, and E2E run simultaneously. For production, we use trigger: manual so deployment only happens after approval.

Custom pipeline for rollback

pipelines: custom: rollback: - variables: - name: RELEASE_TAG default: 'v1.0.0' - step: name: Rollback to tag script: - git fetch --tags - git checkout $RELEASE_TAG - npm ci && npm run build - ./deploy.sh production 

# Docker build image: atlassian/default-image:4 pipelines: branches: main: - step: services: - docker script: - docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD - docker build -t myrepo/mysite:$BITBUCKET_COMMIT . - docker push myrepo/mysite:$BITBUCKET_COMMIT - docker tag ... && docker push ... # PHP (Laravel/Symfony) image: php:8.3-cli definitions: caches: composer: vendor pipelines: branches: main: - step: caches: - composer script: - apt-get update && apt-get install -y unzip libpq-dev - docker-php-ext-install pdo_pgsql - curl -sS https://getcomposer.org/installer | php - php composer.phar install --no-dev --optimize-autoloader - php artisan config:cache - php artisan migrate --force 

- step: script: - npm run build after-script: - | if [ $BITBUCKET_EXIT_CODE -ne 0 ]; then curl -s -X POST $SLACK_WEBHOOK \ -H 'Content-type: application/json' \ -d '{"text":"Build failed: '"'$BITBUCKET_REPO_FULL_NAME'"'"}' fi