Узнайте, как реализовать непрерывную поставку с помощью Bitbucket Pipelines

В этом руководстве мы увидим, как можно внедрить рабочий процесс непрерывной поставки с помощью Bitbucket Pipelines. Читайте дальше! 

Sten Pittet Sten Pittet

Требования

Время:

30 минут

Аудитория:

Если вы только начинаете работу с непрерывной поставкой и/или Bitbucket Pipelines

Обязательное условие:

Попробовать бесплатно

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

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

Такую автоматизацию развертывания сегодня можно легко осуществить с помощью Bitbucket Cloud. Для каждого из ваших репозиториев можно настроить конвейер, который будет автоматически выполнять сборку, проводить тесты и развертывать код в ваших средах после каждой команды push. В этом руководстве будет показано, как внедрить процесс непрерывной поставки с помощью Bitbucket Pipelines.

Непрерывная поставка или непрерывное развертывание?

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

При непрерывном развертывании новые изменения, отправляемые в репозиторий, автоматически развертываются в рабочую среду, если успешно проходят тесты. При этом создается большой упор (читай: давление) на культуру тестирования, однако это отличный способ ускорить цикл обратной связи с клиентами.

Схема, показывающая разницу между непрерывной поставкой и непрерывной интеграцией (CI и CD) | Atlassian CI/CD

Внедрение конвейера непрерывной поставки

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

В обоих примерах мы будет использовать простое приложение Node.js, отображающее в браузере сообщение «Hello World». Вы можете клонировать код приложения «Hello World!» по ссылке ниже и использовать его для работы с этим руководством.

Мы будем развертывать это приложение в промежуточной и рабочей средах, размещенных на Heroku, используя оба способа.

Просто приложение Hello World | Atlassian CI/CD

Очень простое приложение Hello World

Подготовка к развертыванию в Heroku

Для начала нам будет нужно добавить несколько переменных среды в Bitbucket Pipelines, чтобы мы могли осуществлять развертывание в Heroku.

  • HEROKU_API_KEY: ключ API вы можете найти в своем аккаунте Heroku
  • HEROKU_STAGING: имя промежуточной среды
  • HEROKU_PROD: имя рабочей среды

Чтобы добавить все эти переменные, перейдите в настройки репозитория и откройте раздел Pipelines > Environment variables (Конвейеры > Переменные среды).

Снимок экрана: настройка Heroku в Bitbucket | Atlassian CI/CD

Настройка переменных среды для развертывания в Heroku

В этом руководстве мы используем Heroku, но, разумеется, этот пример можно адаптировать к другим сервисам хостинга. Другие руководства по развертыванию можно найти в документации.

Непрерывная поставка с использованием веток, играющих роль шлюза перед рабочей средой

Эта конфигурация подходит для команд, имеющих специальные ветки релиза, которые можно сопоставить с конкретными развертываниями. Она также позволяет проверять изменения в запросе pull перед их развертыванием в рабочей среде.

В этой конфигурации мы будем использовать две разные ветки для запуска развертываний:

  • main: любая отправка в главную ветку приведет к развертыванию кода в промежуточной среде после выполнения тестов.
  • production: после слияния с веткой production код будет автоматически выпускаться в рабочую среду.

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

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main

Итак, мы создали конвейер, который после сборки и тестирования приложения будет развертывать на Heroku каждое изменение кода в главной ветке. Раздел clone в начале конфигурации обеспечивает выполнение полного клонирования (иначе Heroku может отклонить команду git push). Просто отправьте эту конфигурацию в Bitbucket, и вы увидите, как впервые выполнится автоматическое развертывание в промежуточную среду.

Снимок экрана: успешное развертывание конвейера | Atlassian CI/CD

Успешный конвейер, который развертывает наше приложение в промежуточной среде

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

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main     # When code is pushed to the main branch it is deployed automatically to the production environment.     production:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:main  

Мы снова запускаем тесты в ветке production, чтобы убедиться, что перед выпуском релиза приложения ничего не затронуло соответствующую сборку.

Теперь конвейеры настроены, и мы можем ограничить ветку рабочей среды таким образом, чтобы в нее принимались слияния только посредством запросов pull. Чтобы ограничить ветку рабочей среды, просто перейдите в раздел Workflow > Branch permissions (Процесс > Права доступа к веткам) в настройках репозитория. Это важный шаг, так как мы хотим предотвратить отправку кода с локальных компьютеров прямо в рабочую среду.

Настройка разрешений для ветки рабочей среды | Atlassian CI/CD

Настройка разрешений для ветки рабочей среды

На вышеприведенном снимке экрана можно заметить права:

  • Никто не имеет доступа с правом записи
  • Только один разработчик может осуществлять слияние с веткой.

Мы также добавили проверку слияния, чтобы перед слиянием кода убедиться, что в исходной ветке есть хотя бы одна «зеленая» сборка. Это позволит нам сэкономить время сборки и запретить разработчикам делать слияние плохого кода с веткой рабочей среды.

Когда это будет сделано, можно создать запрос pull для слияния кода из главной ветки в ветку рабочей среды, а затем выпустить новые изменения в рабочую среду.

Снимок экрана: создание запроса pull в Bitbucket | Atlassian CI/CD

Создайте запрос pull для слияния изменений в рабочей среде

Как только вы выполните слияние запроса pull, то увидите, как запустится новый конвейер для ветки рабочей среды.

Конвейер был успешно запущен по запросу pull | Atlassian CI/CD

По завершении его работы новые изменения будут успешно развернуты в рабочей среде.

Рабочая среда обновлена!

Теперь вы настроили процесс непрерывной поставки с помощью Bitbucket Pipelines и можете безопасно использовать запросы pull для выпуска кода вашим клиентам.

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

Непрерывная поставка с управляемым вручную триггером релиза

Такая конфигурация идеально подходит для команд, практикующих разработку с магистральной веткой.

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

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

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main  

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

Наше первое автоматическое развертывание в промежуточной среде

Теперь, когда у нас настроено промежуточное развертывание, мы можем просто добавить пользовательский конвейер в нашу конфигурацию bitbucket-pipelines.yml, которую мы будем использовать для инициирования выпуска в рабочую среду вручную.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main   custom:     prod-deployment:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

После отправки новой конфигурации в репозиторий Bitbucket можно перейти к коммиту и щелкнуть ссылку Run pipeline (Запустить конвейер) под информацией о коммите, чтобы запустить развертывание в рабочей среде.

При вызове действия запуска конвейера будет показан список доступных пользовательских конвейеров

Просто нажмите кнопку Run (Выполнить). Вы будете перенаправлены к конвейеру развертывания в рабочей среде, где сможете следить за журналами.

В разделе конвейера, содержащем информацию о коммите, можно увидеть имя пользовательского конвейера, который был использован. Теперь вы готовы использовать свою новую конфигурацию Bitbucket Pipelines для непрерывной поставки и можете проверить свое приложение Hello World в рабочей среде, чтобы убедиться, что все прошло хорошо.

Наше приложение «Hello World» было развернуто в рабочей среде с помощью ручного триггера

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