Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Отделите сборку от публикации
Команда собирает приложение отдельно для staging и production. Между сборками меняются зависимости, поэтому протестированный код не всегда совпадает с опубликованным. Предлагаемый рабочий процесс создаёт один неизменяемый артефакт и передаёт его через среды. Сначала определите формат, идентификатор версии и место хранения. Для контейнера удобно фиксировать точный digest, для архива — контрольную сумму и commit. Это архитектурная рекомендация команды; Bitbucket предоставляет средства организации конвейера и deployment-окружений, но не делает любой пользовательский скрипт воспроизводимым автоматически. Проверьте, что конфигурация среды не зашивается в артефакт вместе с секретами.
Опишите окружения и переменные
В настройках репозитория заведите используемые deployment-окружения согласно доступному интерфейсу и свяжите шаги pipeline с нужной средой. Названия должны однозначно отличать тестовый и производственный контур. Для каждого окружения определите адрес сервиса, идентичность развёртывания и владельца. Чувствительные значения храните в предназначенных для этого переменных с минимальной областью действия. Одинаковое имя переменной может иметь разные значения по средам, поэтому документируйте правило выбора. Перед первым запуском скрипт должен проверить наличие обязательных параметров и прекратить работу при неоднозначной конфигурации. Недопустимо молча использовать production как значение по умолчанию.
Ограничьте право производственного выпуска
Bitbucket Cloud предлагает настройки разрешений deployment-окружений; используйте доступные вашему репозиторию механизмы для согласованной группы выпуска. Отдельно ограничьте, кто может менять pipeline и скрипт развёртывания: иначе разрешение на выполнение обходится изменением кода. Проверьте ветки, из которых допускается публикация, и защиту основной истории. Для ручного подтверждения определите конкретную роль и проверяемые условия: успешный staging, известный артефакт и готовый откат. Не считайте наличие ручной кнопки достаточным контролем. Пользователь, нажимающий её, должен понимать, какую версию и в какую среду он выпускает.
Проверьте параллельные изменения
Два одновременных развёртывания способны перезаписать конфигурацию или сделать результат непредсказуемым. Изучите применяемое Bitbucket управление конкурентными deployment-процессами и дополнительно проверьте поведение вашего внешнего инструмента. Если pipeline запускает отдельную систему, её очередь может продолжить работу независимо. На тестовой среде запустите два выпуска и убедитесь, что последовательность соответствует ожиданиям. Запишите, какая версия фактически установлена после завершения. В журнале приложения полезно иметь идентификатор артефакта. Успешный статус шага недостаточен, если целевой сервис продолжает отдавать предыдущую версию или часть узлов не обновилась.
Сделайте откат отдельной проверяемой операцией
До production сохраните предыдущий артефакт и подтвердите совместимость его запуска с текущими данными. Для изменений схемы базы данных нужен отдельный план: возврат бинарного файла не обязательно отменяет миграцию. В процедуре отката укажите триггер, ответственного и критерий восстановления. Проверьте сценарий на staging с теми же классами изменений. Не собирайте старый commit заново в момент аварии, если можно использовать ранее проверенный неизменяемый артефакт. После отката проверьте пользовательскую операцию и метрики, а не только завершение команды. Запишите итоговую фактическую версию сервиса и состояние временных обходов.
Проведите первый выпуск как упражнение
Выберите небольшой релиз и пройдите весь маршрут: сборка, тесты, staging, подтверждение, production и контроль. Затем выполните заранее согласованный тестовый откат в безопасной среде. Проверьте отрицательные случаи: отсутствие переменной, неподходящую роль и попытку выпуска неизвестного артефакта. При сбое настроек верните сохранённую конфигурацию pipeline, сохранив историю проблемы. После упражнения упростите шаги, которые требуют ручного копирования идентификаторов. Хороший результат — возможность однозначно ответить, какой код работает в каждой среде, кто разрешил выпуск и как быстро вернуть известное рабочее состояние без догадок и повторной сборки.
Паспорт конкретного выпуска
Для первого производственного релиза подготовьте компактный паспорт: commit, идентификатор артефакта, результаты staging, подтверждающий участник и предыдущая рабочая версия. Укажите отдельно изменение данных и необходимость миграции. Во время выпуска сравните фактическую версию сервиса с паспортом, а не полагайтесь только на зелёный статус pipeline. Если приложение многокомпонентное, перечислите совместимые версии связанных сервисов. Попросите дежурного по документу определить, что именно он вернёт при откате. Неоднозначный ответ означает, что процедура ещё не готова. После успешного релиза сохраните наблюдаемые показатели и время проверки. При следующем выпуске используйте ту же структуру, обновляя конкретные значения. Такой паспорт помогает быстро связать изменение поведения с установленным кодом, особенно когда несколько команд выпускаются одновременно и общий журнал содержит много близких по времени событий.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу