Настройка CI/CD для сайта через Bitbucket Pipelines

Настройка CI/CD для сайта через Bitbucket Pipelines

Мы часто встречаем проекты, где деплой делается вручную через FTP — это приводит к ошибкам и потерям. В одном проекте с Symfony-сайтом ручной деплой занимал 40 минут, и каждый пятый выкат приходилось откатывать из-за забытой миграции. После внедрения Bitbucket Pipelines процесс сократился до 8 минут, а количество сбоев упало до нуля. Более того, команда перестала тратить время на согласование выкатов — pipeline выполняет все проверки автоматически.

Настраиваем CI/CD в Bitbucket Pipelines так, чтобы каждая сборка проходила статический анализ, модульные тесты и интеграционные проверки, а затем автономно уезжала на сервер. Это не только ускоряет релизы, но и исключает человеческий фактор: забытые миграции, неверные конфиги, пропущенные зависимости.

Проблемы, которые решаем

• Разные окружения: staging и production часто отличаются конфигами. Pipelines позволяет задать свои переменные для каждого деплой-окружения.
• Долгие ручные деплои: один клик — и сборка с тестами запускается автоматически. Не нужно ждать разработчика.
• Ошибки в конфигурации: часто путают SSH-ключи или забывают установить зависимости. Мы прописываем все в yml, а after-script оповестит о проблеме.
• Отсутствие тестов: многие проекты не имеют автоматических проверок. Мы встраиваем статический анализ, модульные тесты и линтер прямо в пайплайн. Например, для фронтенд-проекта на React 18 с TypeScript добавили ESLint, Jest и Playwright — пайплайн сразу выявляет regression.

Как работает CI/CD в Bitbucket Pipelines?

Bitbucket Pipelines встроен в репозиторий — не нужен отдельный CI-сервер. Вы описываете шаги в файле bitbucket-pipelines.yml, и Bitbucket выполняет их в Docker-контейнере. В отличие от GitLab CI, настройка занимает в 2 раза меньше времени: не нужно управлять раннерами. Бесплатно даётся 50 минут сборки в месяц, платные планы снимают ограничения (от $10/мес).

Процесс настройки

1. Аудит репозитория: определяем стек, тесты, окружения.
2. Создание bitbucket-pipelines.yml: пишем шаги сборки, тестов, деплоя.
3. Настройка переменных: задаём секреты (SSH-ключи, токены) в Repository Settings.
4. Конфигурация окружений: создаём staging и production с ручным одобрением.
5. Тестирование: прогоняем pipeline на тестовой ветке.
6. Документация: описываем процесс запуска и отката.

Пример: базовая конфигурация для Node.js и деплой через 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 

Продвинутые возможности

Переменные окружения и артефакты

Переменные хранятся в Repository Settings → Repository variables. Флаг secured скрывает значение в логах. Артефакты передают файлы между шагами — например, dist/ и .env.production. Хранятся 14 дней, достаточно для отладки. Сравним настройки для окружений:

Параллельные шаги и ручной триггер

Параллельные шаги ускоряют pipeline — тесты, линтер и E2E запускаются одновременно. Для продакшена используем trigger: manual, чтобы деплой делался только после одобрения.

Кастомный pipeline для отката

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-сборка 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