Close

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

Фотография Стена Питтета
Стен Питтет

Приглашенный автор

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

Время

30 минут

Аудитория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для начала зарегистрируйтесь в Heroku.

Затем установите интерфейс командной строки Heroku.

Обновите файл package.json, чтобы он выглядел примерно следующим образом:

{
  "name": "cdtutorial",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "mocha --exit"
  },
  "repository": {
    "type": "git",
    "url": "git+ssh://git@bitbucket.org/pmmquickstartguides01/cdtutorial.git"
  },
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://bitbucket.org/pmmquickstartguides01/cdtutorial/issues"
  },
  "homepage": "https://bitbucket.org/pmmquickstartguides01/cdtutorial#readme",
  "dependencies": {
    "express": "^4.17.3"
  },
  "devDependencies": {
    "mocha": "^9.2.2",
    "supertest": "^6.2.2"
  }
}

Обновите файл server.js, чтобы он выглядел примерно следующим образом:

var express = require("express");
var app = express();

app.get("/", function (req, res) {
  res.send("Hello World!");
});

app.listen(process.env.PORT || 3000, function () {
  console.log("Example app listening on port 3000!");
});

module.exports = app;

Обратите внимание на изменение в функции app.listen(). Теперь она включает порт process.env.port, который задан со стороны Heroku.

Добавьте Procfile в корневой каталог тестового репозитория, выполнив следующую команду:

touch Procfile

Затем добавьте следующий текст в Procfile:

web: npm start

Войдите в Heroku, нажмите значок пользователя в правом верхнем углу, выберите Account Setting (Настройка аккаунта) и прокрутите страницу вниз, чтобы найти раздел API key (Ключ API).

Расположение раздела API Key (Ключ API) в настройках аккаунта Heroku

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

  • HEROKU_API_KEY: ключ API вы можете найти в своем аккаунте Heroku

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

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

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

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

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

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

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

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

Создайте в Bitbucket Cloud ветку production, нажав пункт Branches (Ветки).

Ветка production в Bitbucket Cloud

Затем нажмите кнопку Create branch (Создать ветку).

Выбор кнопки Create Branch (Создать ветку) во всплывающем окне в Bitbucket Cloud

Введите название «production» и нажмите кнопку Create (Создать).

Из корневого каталога тестового репозитория выполните следующие команды:

heroku create --remote staging
git push staging main
heroku create --remote production
git push production main

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

Список приложений Heroku в браузере

Кроме того, выполните следующую команду:

git remote -vv

Нам нужно, чтобы среди выходных данных отобразилось три удаленных репозитория: один для Bitbucket и два — для Heroku (где первый будет удаленной промежуточной средой, а второй — удаленной рабочей средой).

wmarusiak@C02F207NML7L cdTutorial % git remote -vv
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (fetch)
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (push)
production https://git.heroku.com/young-harbor-11356.git (fetch)
production https://git.heroku.com/young-harbor-11356.git (push)
staging https://git.heroku.com/boiling-refuge-14681.git (fetch)
staging https://git.heroku.com/boiling-refuge-14681.git (push)

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

bitbucket-pipelines.yml

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/boiling-refuge-1468.git main

Обязательно замените в команде git push URL-адрес для ветки main на URL-адрес репозитория staging из git remote -vv.

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

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

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

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

bitbucket-pipelines.yml

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
    production:
      - step:
          name: deploy_to_production
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production:main

Обязательно замените в командах git push URL-адрес для ветки main на URL-адрес для staging из git remote -vv, а URL-адрес для production — на URL-адрес для production из git remote -vv.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение «Hello World!» (Привет, мир!), подтверждающее, что рабочая среда обновлена

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

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

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

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

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

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

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

bitbucket-pipelines.yml

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
  custom:
    prod-deployment:
      - step:
          name: deploy_to_production
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production:main

Обязательно замените в командах git push URL-адрес для ветки main на URL-адрес для staging из git remote -vv, а URL-адрес для production — на URL-адрес для production из git remote -vv.

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

Выбор и запуск конвейера из Bitbucket

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

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

Конвейер развертывания в рабочую среду в Bitbucket

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

Тестовое сообщение «Hello World!» (Привет, мир!) в рабочей среде

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

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

Sten Pittet
Sten Pittet

Я уже 10 лет работаю в сфере ПО, занимал различные должности: от разработчика до менеджера продукта. Проработав 5 лет в Atlassian, где я участвовал в создании инструментов разработки, теперь я пишу статьи о разработке ПО. За пределами офиса я работаю над тем, чтобы стать хорошим отцом для своего потрясающего малыша.


Поделитесь этой статьей
Следующая тема

Рекомендуемые статьи

Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.

Рисунок: DevOps

Сообщество DevOps

Рисунок: DevOps

Образовательные программы DevOps

Рисунок схемы

Начните работу бесплатно

Подпишитесь на информационную рассылку по DevOps

Thank you for signing up