Налаштування 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