Настройка CI/CD пайплайна в Bamboo с Atlassian стеком

Почему ручная сборка ломает релизы: когда нужна настройка Bamboo

Ручная сборка релизов держится на памяти и договорённостях. Пока выпуск один в две недели, инженер собирает ветку, прогоняет тесты локально и копирует артефакт на стенд. Как только релизов становится больше или в команду приходит второй разработчик, шаг «собрать как в прошлый раз» превращается в лотерею: у каждого своя версия зависимостей, свои переменные и свой порядок команд.

Невоспроизводимая сборка — главный источник тихих дефектов. Артефакт с машины разработчика и артефакт из промышленного контура отличаются составом зависимостей и параметрами сборки, поэтому баг «воспроизводится только на проде» — не мистика, а следствие разных входных условий. Рассинхрон окружений добавляет вторую половину: конфигурации тестового и боевого контуров правятся руками и расходятся за считанные недели.

Отдельный риск — релизы, которые держатся на одном человеке. Доступы, скрипты развёртывания и порядок отката живут в его голове и локальной папке, а не в репозитории. Отпуск или переход на другой проект останавливает выпуск, а окно отката при неудачной выкладке растёт с минут до часов.

Автоматизация развёртывания становится обязательной, когда релизы идут чаще раза в неделю, окружений больше двух или аудит требует подтверждённого авторства каждого изменения. Тогда и нужна настройка Bamboo в связке с остальной экосистемой Atlassian: сборка, проверки и выкладка описываются декларативно и выполняются одинаково на любом стенде. Разбираем, как это закрывается.

Что даёт конвейер сборки: воспроизводимость, скорость, меньше сбоев

Единый конвейер сборки убирает главную причину расхождений — разные окружения у разработчика, на сборочном агенте и на сервере. Зависимости фиксируются файлом-манифестом, шаги описаны кодом, агенты поднимаются в изолированном окружении и после прогона уничтожаются. Один и тот же коммит даёт один и тот же артефакт независимо от того, кто и когда запустил сборку — «у меня локально работает» перестаёт быть аргументом.

Время сборки и релиза сокращается не оптимизацией ради оптимизации, а структурой: кэш зависимостей между запусками, параллельные стадии тестов, разделение быстрых проверок и долгих регрессионных прогонов по расписанию. Артефакт собирается один раз и продвигается по средам без пересборки, поэтому путь от коммита до готового релиза измеряется десятками минут вместо часов. Узкое место при этом видно на временной шкале стадий, а не выясняется на созвоне постфактум.

Доля откатов релиза падает за счёт того, что уходит целый класс ошибок — забытые миграции, расхождения конфигураций, шаги, которые делались руками и «обычно работали». Простой из-за сбоя сборки перестаёт быть сюрпризом: конвейер падает на коммите с понятной причиной, а не в рабочем контуре ночью, и откат на предыдущий артефакт остаётся доступным в один шаг.

Bamboo в связке с трекером задач и репозиторием даёт это без разрозненных самодельных скриптов: правила сборки, права и история запусков живут в одном месте. Дальше разбираем, как переносится текущий процесс сборки и что остаётся от накопленных скриптовых обвязок.

Варианты запуска сборок: выделенные агенты, облако, контейнеры

Режим работы агентов задаёт, где выполняется сборка и насколько воспроизводим результат. В Bamboo это описывается требованиями задачи и возможностями узла: планировщик отдаёт сборку только тому агенту, чей набор совпадает. Отсюда четыре схемы, между которыми реально выбирают.

На практике схемы смешивают: сборка идёт в изолированном окружении, тесты распараллеливаются на агентах по требованию, а выпуск выполняет выделенный узел. Так закрываются сразу и пики нагрузки, и требования к контролю доступа.

Этапы настройки Bamboo: от аудита репозиториев до передачи

Порядок работ в Bamboo одинаков для любого репозитория — меняется объём, а не последовательность. Начинаем с аудита: без него автоматизация просто переносит внутрь конвейера те же скрытые допущения, что живут в ручных сборках на машинах разработчиков.

1. Аудит репозиториев и текущих сборочных сценариев. Смотрим, что собирается вручную и почему, где лежат зависимости и секреты, какие ветки действительно живые, сколько времени занимает сборка сейчас.
2. Проектирование схемы конвейера сборки. Разбиваем процесс на шаги: компиляция, тесты, статический анализ, публикация артефакта, выкладка на окружения. Фиксируем, что запускается на каждый коммит, а что только по тегу версии.
3. Настройка агентов и планов сборки. Разворачиваем агенты под нужные платформы и ограничиваем параллелизм, чтобы тяжёлая сборка не вытесняла остальные задачи. Общие шаги выносим в шаблоны — новый сервис подключается правкой переменных, а не копированием скриптов.
4. Проверка на пилотной ветке релиза. Прогоняем весь конвейер на одном сервисе: замеряем время сборки, долю успешных запусков, поведение при падении тестов. Отдельно проверяем откат на предыдущий артефакт.
5. Обучение команды. Показываем разработчикам, где смотреть логи, как добавить шаг в план и как перезапустить только упавшую часть вместо всей сборки.
6. Передача документации. Схема конвейера, описание переменных и доступов, инструкция по правке планов, порядок действий при сбое сборки.

Пакет передачи: конфигурации планов, схемы окружений, регламенты

После настройки Bamboo у команды остаётся не набор настроек в переписке и не один инженер, который «знает, где нажать», а версионируемый комплект артефактов. Конфигурация планов хранится рядом с кодом, поэтому изменение проходит проверку как обычный коммит, а окружение воспроизводится из описания, а не собирается руками заново.

• Конфигурация планов сборки — описание планов и связей между ними в файлах репозитория: шаги, условия запуска, зависимости. Значения, различающиеся между средами, вынесены в переменные, секреты — во внешнее хранилище, а не в текст конфигурации.
• Матрица агентов и их мощностей — какой класс задач идёт на общих исполнителях, какой на выделенных, как расставлены метки. Это снимает конкуренцию между сборкой и выкладкой: релиз не ждёт, пока освободится агент под тяжёлые тесты.
• Схема окружений и потоков релиза — цепочка от среды разработки до продуктивной, триггеры перехода и ручные точки подтверждения. Собранный артефакт продвигается между средами без пересборки, поэтому в продуктив уходит ровно то, что прошло проверки.
• Правила разграничения доступов — роли: кому доступен запуск, кому правка конфигурации плана, кто подтверждает выкладку в продуктив. Согласуются с правами в репозиториях и системе задач, чтобы не осталось обходного пути в обход процесса.
• Регламент отката релиза — какой артефакт берётся для возврата, кто принимает решение, за сколько минут среда возвращается в рабочее состояние. Откат изменений схемы данных расписан отдельным сценарием, потому что он не сводится к возврату предыдущей сборки.
• Инструкции для дежурного инженера — типовые сбои: недоступен агент, упали проверки, выкладка зависла в ожидании. На каждый — порядок действий, способ диагностики и точка эскалации.
• Регламент сопровождения — срок жизни артефактов и истории сборок, периодическое обновление базовых окружений агентов и пересмотр планов при смене состава сервисов.

Кейс: переход с ручных релизов на конвейер — метрики до и после

Как было до

До проекта релиз собирался руками: инженер поднимал окружение, прогонял сборку локально, копировал артефакты на стенд и запускал миграции отдельной командой. Порядок шагов жил в голове одного человека — при отпуске релиз просто не выходил. На выпуск уходило 3–4 часа в ночном окне, а причина сбоя выяснялась уже после того, как ошибку увидели пользователи.

Что изменили и что получили

Собрали конвейер в Atlassian Bamboo: сборка, тесты, публикация артефактов версионированным номером, развёртывание по окружениям — одной последовательностью связанных задач. Ветка разработки проверяется на каждом изменении, а в прод идёт только сборка, прошедшая проверки целиком.

Откат сделали таким же шагом конвейера: возврат на предыдущий артефакт и откат схемы базы одной командой, без ручных правок на серверах. Если проверки после развёртывания не проходят, конвейер останавливает выпуск сам и возвращает предыдущее состояние.

Время сборки релизной версии сократилось с 3–4 часов до 20–25 минут. Количество откатов упало с четырёх на десять выпусков до единицы на двадцать — большинство дефектов ловится на проверках, до попадания на прод. Время восстановления после сбоя снизилось с двух-трёх часов до 10–15 минут: откат перестал быть аварийной операцией под давлением.

Отдельный эффект — предсказуемость: релиз больше не зависит от одного человека и от ночного окна, а журнал сборки хранит, кто и что поменял. Новые шаги — проверки безопасности, уведомления — добавляли без переписывания процесса.

Что делать, если часть сборок уже настроена в другом инструменте?

Часть проектов уже собирается в другом инструменте — это рабочая ситуация, а не проблема. Переписывать всё сразу рискованно: релизы идут своим чередом, и остановка сборочной линии сразу бьёт по срокам. Поэтому мы не переносим всё разом, а сначала выстраиваем сосуществование двух контуров.

Начинаем с инвентаризации: какие задачи и триггеры есть у каждого проекта, откуда берутся артефакты, кто и как получает уведомления о сборке. По этой картине видно, какие сценарии переносятся один в один, а какие требуют переработки — чаще всего расхождения в переменных окружения и шагах публикации артефактов.

Пока один проект живёт в старом инструменте, второй уже собирается в Bamboo: оба пишут артефакты в один реестр и запускаются по событиям в системе контроля версий. Работающее не ломаем — прежний сценарий остаётся, новый ставится рядом и обкатывается на тех же ветках и тех же тестовых наборах.

Единая точка выпуска собирается постепенно: версии, журналы сборок, права и оповещения смотрим в одном месте, даже если исполнение идёт в двух системах. Заказчик видит один список выпусков и один статус по каждому сервису вместо двух несогласованных картин. Это же снимает вопрос, кто и когда вносил правку в сборочный сценарий.

Поэтапная миграция конвейера идёт по риску: сначала некритичные сервисы и ночные сборки, затем релизные ветки, в конце — то, что связано с боевым контуром. Каждый шаг обратим: прежний сценарий остаётся рабочим, пока новый не отработает несколько релизов подряд. Настройка Bamboo в таком режиме не требует остановки текущих релизов.

Частые технические вопросы: агенты, доступы, миграция сборок

Изоляция сборок начинается с агентов: у каждого пула свой набор возможностей — установленные инструменты, доступ к внутренним реестрам, переменные окружения. План привязывается к нужному пулу через требования, поэтому чужая сборка не займёт освободившийся агент и не увидит переменные соседней команды.

Секреты живут отдельно от плана — в общих учётных данных проекта, параметрах окружений развёртывания и внешнем хранилище. Значения подставляются в момент запуска и маскируются в логах, а доступ к ним выдаётся по ролям.

Как выдаются доступы к окружениям?

Права на развёртывание привязаны к окружению и роли: разработчик собирает артефакт, но выкладку в продуктив выполняет согласованный круг. Ротация учётных данных не требует правки планов — меняется значение в хранилище.

Что делать с существующими планами сборки?

Переносим двумя путями: экспорт-импорт конфигурации для точечного переезда или описание плана как кода — тогда настройки лежат в репозитории, проходят ревью и воспроизводятся на новом контуре. Перед переносом сверяем связи с репозиториями, триггеры и переменные.

Кто сопровождает конвейер после передачи?

Остаёмся на сопровождении: обновляем агентов и дополнения, следим за очередью заданий и временем сборки, разбираем падения. Метрики — длительность сборки, доля успешных запусков, время до восстановления после сбоя.

Обсудим задачу: посмотрим ваши сборки и вернёмся с планом

Чтобы оценка опиралась на факты, а не на предположения, начинаем с разбора текущего процесса. Смотрим, как устроены планы сборки в Bamboo, сколько агентов задействовано, как репозитории связаны с трекером задач и в какой момент код попадает в целевое окружение. Отдельно фиксируем узкие места: где сборка идёт дольше, чем могла бы, какие шаги выполняются руками и какие релизы зависят от конкретного инженера.

На разборе уточняем то, что невозможно увидеть из конфигураций:

• какие ветки и как попадают в сборку, где сейчас рвётся конвейер и почему;
• сколько шагов автоматизации не хватает — от проверок до выкладки;
• какие окружения есть и чем отличаются, где нужны ручные подтверждения;
• как устроены доступы, роли и хранение секретов, кто и что может менять;
• как формируются артефакты, нумеруются версии и выполняется откат;
• какие ограничения задаёт инфраструктура — сеть, агенты, лимиты внешних систем;
• что уже настроено и переиспользуется, а что придётся строить с нуля.

По итогам разбора возвращаемся с планом внедрения конвейера: этапы, порядок работ, зоны ответственности и оценка трудозатрат по автоматизации. План согласуем до старта — вы заранее видите, что изменится на каждом этапе и как это отразится на текущих релизах. Опишите задачу и пришлите доступы к конфигурациям — вернёмся с оценкой и схемой работ.