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

В этом руководстве будет показано, как реализовать конвейер непрерывного развертывания с помощью Bitbucket Pipelines.

Sten Pittet Sten Pittet

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

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

В этом руководстве будет показано, как реализовать конвейер непрерывного развертывания с помощью Bitbucket Pipelines.

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

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

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

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

Требования

Время:

30 минут

Аудитория:

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

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

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

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

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

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

Исходный код приложения Hello World можно найти в репозитории, ссылка на который приведена ниже.

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

Прежде чем приступить к работе, необходимо добавить несколько переменных среды, чтобы обеспечить возможность развертывания нашего приложения в Heroku:

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

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

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

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

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

Настройка конвейера

Этот процесс простой и понятный.

  • Сборка приложения.
  • Выполнение тестов на сборке.
  • Развертывание в промежуточной среде.
  • Выполнение нескольких приемочных тестов в промежуточной среде.
  • Развертывание в рабочую среду.

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

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 

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

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


На этом этапе наше приложение Hello World развернуто в промежуточной среде.

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

Если вы посмотрите на код приложения, то увидите, что наш тест выполняет предельно простое действие: он всего лишь ищет наличие строки «Hello World» на странице. Для реальных приложений мы рекомендуем разрабатывать приемочные тесты, идущие намного дальше: они должны проверять правильность работы всех базовых сервисов, используемых приложением (база данных, кэш, сторонние сервисы и т. д.).

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

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             - HEROKU_STAGING=$HEROKU_STAGING npm test acceptance-test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main             - npm test acceptance-test  

После отправки этой новой конфигурации в Bitbucket мы увидим, как наш конвейер успешно завершает работу.

После развертывания в промежуточной среде Bitbucket Pipelines выполняет приемочные тесты

Чтобы завершить создание конвейера непрерывного развертывания, осталось только добавить в его конец развертывание в рабочей среде.

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             - HEROKU_STAGING=$HEROKU_STAGING npm test acceptance-test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

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

Наше новое сообщение отправилось в рабочую среду, как и ожидалось!

Можно проверить конвейер и убедиться, что он корректно прошел все этапы.

Проверка, прошел ли код через конвейер

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

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