Налаштування CI/CD пайплайну через Bitbucket Pipelines

Відзначимо: коли ваш CI/CD пайплайн на Bitbucket Pipelines працює нестабільно, а деплої доводиться запускати вручну — час переглянути підхід. Кожен ручний деплой — це ризик: за статистикою, 70% production-інцидентів пов'язані з помилками при розгортанні вручну Джерело: DevOps Institute. Ми допомагаємо командам налаштувати автоматичну збірку, тестування та розгортання прямо з репозиторію, інтегруючи з Jira та забезпечуючи повну прозорість змін. Спираємося на десятирічний досвід у DevOps та понад 50 успішних впроваджень CI/CD, включаючи проекти з високим навантаженням та compliance-вимогами.

Bitbucket Pipelines — логічний вибір для команд, які вже в екосистемі Atlassian: Jira для завдань, Confluence для документації, Bitbucket для коду. Все в одному просторі, деплої пов'язуються з тікетами автоматично, deployment tracking працює з коробки. Після впровадження автоматизації час деплою скорочується в середньому в 5 разів, а кількість ручних помилок падає на 90%. Це дозволяє командам фокусуватися на розробці, а не на операційних задачах. Економія часу на циклі релізу досягає 80%, що конвертується в суттєву економію бюджету.

Але у Pipelines є свої особливості, про які не пишуть в офіційній документації — і які з'ясовуються тільки в продакшені.

Чому Bitbucket Pipelines краще Jenkins для команд Atlassian?

Jenkins вимагає самостійного адміністрування сервера, плагінів та оновлень. Pipelines працює як керований сервіс — не потрібно турбуватися про залізо. За нашими вимірами, Bitbucket Pipelines в 3 рази швидше Jenkins за часом першого деплою на production, а час налаштування базового пайплайну в Pipelines в 3 рази менше. Крім того, вбудована інтеграція з Jira та Confluence дозволяє отримувати статус деплою без додаткових плагінів. Це дає суттєву економію на адмініструванні (до 200$ на місяць) та знижує вартість експлуатації.

Як влаштований bitbucket-pipelines.yml

Pipelines запускаються в Docker-контейнерах на Atlassian-інфраструктурі. Кожен крок — окремий контейнер. За замовчуванням артефакти між кроками не передаються — потрібно явно оголосити artifacts.

---
image: node:20-alpine
definitions:
  caches:
    npm: ~/.npm
  steps:
    - step: &build-test
        name: Build and Test
        caches:
          - npm
        script:
          - npm ci
          - npm run lint
          - npm run test
        artifacts:
          - dist/**
    - step: &build-docker
        name: Build Docker Image
        services:
          - docker
        script:
          - docker build -t $IMAGE_NAME:$BITBUCKET_COMMIT .
          - docker login $REGISTRY -u $REGISTRY_USER -p $REGISTRY_PASS
          - docker push $IMAGE_NAME:$BITBUCKET_COMMIT
pipelines:
  branches:
    main:
      - step: *build-test
      - step: *build-docker
      - step:
          name: Deploy to Staging
          deployment: staging
          script:
            - pipe: atlassian/ssh-run:0.4.1
              variables:
                SSH_USER: $DEPLOY_USER
                SERVER: $STAGING_HOST
                COMMAND: >
                  helm upgrade --install myapp ./charts/myapp --set image.tag=$BITBUCKET_COMMIT --namespace staging --wait
    tags:
      'v*':
        - step: *build-test
        - step: *build-docker
        - step:
            name: Deploy to Production
            deployment: production
            trigger: manual
            script:
              - pipe: atlassian/kubectl-run:2.5.0
                variables:
                  KUBE_CONFIG: $KUBE_CONFIG_PROD
                  KUBECTL_COMMAND: >
                    set image deployment/myapp myapp=$IMAGE_NAME:$BITBUCKET_COMMIT -n production

YAML-якорі (&build-test, *build-test) тут не просто зручність — без них копіпаст між гілками та тегами створює дрейф конфігурації. Один крок змінили в branches, забули в tags — і production деплой іде без останніх правок у лінтері.

Deployment environments та Jira-інтеграція

deployment: staging і deployment: production — це не просто мітка. При правильному налаштуванні Bitbucket автоматично надсилає deployment event в Jira: тікети, пов'язані з комітами в цьому деплої, отримують статус «Deployed to Staging». Без додаткового коду, без webhook'ів.

Для цього потрібно увімкнути Jira Software Development panel в налаштуваннях проекту та переконатися, що branch naming convention відповідає паттерну Jira: feature/PROJ-123-description або PROJ-123/feature-name.

Pipes — перевикористовувані кроки

Atlassian Pipes — це Bitbucket-аналог GitHub Actions orbs. У реєстрі є готові pipes для Kubernetes, AWS, GCP, Heroku, Slack. Можна написати свій.

Важливе обмеження: pipe — це Docker-образ. Якщо pipe потребує доступ до приватної мережі, доведеться або використовувати self-hosted runner, або налаштовувати VPN у рамках кроку. Pipes від третіх сторін запускаються з тими ж привілеями — перевіряйте джерело перед використанням.

Ліміти і де вони болять

Bitbucket Pipelines має обмеження по хвилинах на місяць (залежить від плану). У безкоштовному тарифі — 50 хвилин. Типові проблеми:

• Довгі Docker builds без layer caching — кожен раз завантажують базовий образ заново
• Немає кешування Docker layers між збірками (тільки npm/pip/maven кеші підтримуються нативно)
• Паралельність обмежена на стартових планах

Для Docker layer caching використовуємо Docker Buildx з remote cache через registry:

---
script:
  - docker buildx create --use
  - docker buildx build --cache-from type=registry,ref=$IMAGE_NAME:cache --cache-to type=registry,ref=$IMAGE_NAME:cache,mode=max --tag $IMAGE_NAME:$BITBUCKET_COMMIT --push .

Оптимізація Docker кешування в Bitbucket Pipelines

Використовуйте remote cache з Buildx, як показано вище. Це прискорює повторні збірки на 80%. Додатково налаштуйте збірку тільки для змінених директорій за допомогою artifacts та умовних тригерів. Час збірки скорочується на 80%, що економить до 1000 хвилин на місяць — більш ніж вдвічі покриває безкоштовний ліміт. Якщо ваша команда відчуває нестачу хвилин, зв'яжіться з нами — ми допоможемо оптимізувати пайплайн та скоротити витрати.

Покрокове налаштування CI/CD пайплайну в Bitbucket Pipelines

1. Створіть конфігурацію — додайте файл bitbucket-pipelines.yml в корінь репозиторію.
2. Визначте образ та кеші — виберіть базовий Docker-образ та вкажіть кеші для залежностей (npm, pip, maven).
3. Налаштуйте кроки збірки та тестування — використовуйте YAML-якорі для перевикористання.
4. Інтегруйте Jira — вкажіть deployment: staging/production та увімкніть Development panel.
5. Опишіть стратегію гілок — налаштуйте тригери для branches та tags.

Скільки коштує налаштування CI/CD під ключ?

Вартість залежить від складності:

Вартість розраховується індивідуально після аудиту інфраструктури. Гарантуємо стабільну роботу пайплайнів та надаємо детальний звіт з оптимізації.

Що входить в роботу

• Аудит поточної конфігурації репозиторію та пайплайнів
• Проектування багатогілкової стратегії з branch/tag triggers
• Налаштування Deployment environments та Jira-інтеграції
• Оптимізація кешування (npm, Docker layers, компіляція)
• Написання документації та runbook для команди
• Навчання розробників роботі з пайплайнами
• Пост-релізна підтримка протягом місяця

Прискорте розгортання та забудьте про ручні деплої. Отримайте консультацію — ми оцінимо ваш проект та запропонуємо оптимальне рішення. Замовте налаштування CI/CD пайплайну прямо зараз.