Close

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

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

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

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

Время

30 минут

Аудитория

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

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

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

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

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

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

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

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

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

В этом примере мы расширим простое приложение node.js, созданное по инструкциям из статьи <ссылка на статью 2>, добавив конвейер непрерывного развертывания. Непрерывное развертывание здорово помогает командам ускорить разработку. Такой подход устраняет препятствия, связанные с процессом одобрения релизов, и позволяет разработчикам получать обратную связь от клиентов сразу, как только они завершают выполнение задачи. У команды нет конкретного времени релиза, поэтому участникам становится проще выявлять и устранять проблемы. Кроме того, им реже приходится переключать контекст.

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

Шаг 1. Создайте новое приложение Heroku

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

heroku create --remote production2
git push production2 main

Теперь выходные данные команды git remote -vv выглядят примерно так, как показано ниже. Для оставшейся части этого урока используйте ветки staging и production2.

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/fierce-basin-45507.git (fetch)
production https://git.heroku.com/fierce-basin-45507.git (push)
production2 https://git.heroku.com/limitless-headland-92324.git (fetch)
production2 https://git.heroku.com/limitless-headland-92324.git (push)
staging https://git.heroku.com/thawing-river-12585.git (fetch)
staging https://git.heroku.com/thawing-river-12585.git (push)

Шаг 2. Настройте конвейер

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

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

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

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

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

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

Отправка конфигурации в Bitbucket Pipelines

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

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

Снимок экрана: приложение «Hello World», развернутое в промежуточной среде

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

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

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

mkdir acceptance-test
touch acceptance-test/test.js

Затем отредактируйте файл acceptance-test/test.js и добавьте следующий фрагмент кода.

var request = require('supertest');

// Running a test on our staging environment
describe('GET /', function() {
  it('displays "Hello World!" on staging', function(done) {
    var staging_url = 'https://' + process.env.HEROKU_STAGING + '.herokuapp.com'
    // The line below is the core test of our app.
    request(staging_url).get("/").expect("Hello World!", done);
  });
});

Обновите файл package.json, добавив в него строку «--timeout 10000».

{
  "name": "cdtutorial",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "mocha --exit --timeout 10000"
  },
  "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"
  }
}

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

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
            - HEROKU_STAGING=thawing-river-12585 npm test acceptance-test

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

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

Успешный запуск конвейера в Bitbucket

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

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

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
            - HEROKU_STAGING=thawing-river-12585 npm test acceptance-test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/limitless-headland-92324.git main

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

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

Обновленное сообщение «Hello World! Straight to production!» (Привет, мир! Прямо в рабочей среде!) на главной странице, подтверждающее, что приложение развернуто в рабочей среде

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

Готовый конвейер непрерывного развертывания в Bitbucket

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

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

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

Sten Pittet
Sten Pittet

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


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

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

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

Рисунок: DevOps

Сообщество DevOps

Рисунок: DevOps

Семинар по моделированию

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

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

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

Thank you for signing up