Узнайте, как реализовать непрерывную поставку с помощью 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: any push to main will deploy the code to a staging environment after running the tests.
  • production: после слияния с веткой production код будет автоматически выпускаться в рабочую среду.

First, we'll configure the deployment to staging. To do that, we use the branch-specific pipelines and create a pipeline that gets executed for every push on the main branch.

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

We have now created a pipeline that will deploy every push to main to Heroku after building and testing our application. The clone section at the beginning of the configuration ensures we do a full clone (otherwise Heroku might reject the git push). Just push this configuration to Bitbucket to see your first automated deployment to staging happening.

Снимок экрана: успешное развертывание конвейера | 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

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

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

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

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

When that's done, you can create a pull request to merge the code from main to production and subsequently release the new changes to your production environment.

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

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

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

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

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

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

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

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

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

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

With Bitbucket Pipelines it is possible to configure custom pipelines that can be triggered manually. They can be used for various purposes: long-running tests that you do not want to run on every push, or specific actions that you want to control yourself. We will use a custom pipeline to set up a continuous delivery workflow where pushes to the main branch get automatically deployed to a staging environment, and commits can be manually deployed to production.

First, we need to configure the automatic deployment to staging. You simply need to add a branch-specific pipeline for main that will deploy the staging environment.

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» было развернуто в рабочей среде с помощью ручного триггера

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