Статьи
Обучающие материалы
Интерактивные руководства
Узнайте, как реализовать непрерывное развертывание с помощью Bitbucket Pipelines
Стен Питтет
Приглашенный автор
Из этого руководства вы узнаете, как внедрить конвейер непрерывного развертывания с помощью Bitbucket Pipelines
Время
30 минут
Аудитория
Если вы только начинаете работу с непрерывным развертыванием и/или Bitbucket Pipelines
При разработке приложений часто приходится идти на сложные компромиссы. Большинство специалистов считает, что для ускорения разработки нужно пожертвовать качеством релизов. Однако существует подход к разработке, с которым можно экономить время и при этом выпускать релизы быстрее. Его называют «непрерывным развертыванием».
При непрерывном развертывании вы избавляетесь от стресса, связанного с развертыванием ПО, превращая эту задачу в автоматизированный процесс. Вашей команде разработчиков больше не нужно останавливаться и вникать в новый контекст на время релиза: код поставляется клиентам, как только разработчик завершает выполнение задачи.
В этом руководстве будет показано, как реализовать конвейер непрерывного развертывания с помощью Bitbucket Pipelines.
Непрерывная поставка или непрерывное развертывание?
Непрерывная поставка — это методика, при использовании которой гарантируется, что код всегда готов к релизу, даже если вы не развертываете каждое изменение в рабочей среде. Рекомендуется обновлять рабочую среду как можно чаще, чтобы объем изменений всегда оставался небольшим, однако в конечном итоге частоту своих релизов контролируете вы.
При непрерывном развертывании новые изменения, отправляемые в репозиторий, автоматически развертываются в рабочую среду, если успешно проходят тесты. При этом создается большой упор (читай: давление) на культуру тестирования, однако это отличный способ ускорить цикл обратной связи с клиентами.
Настройка конвейера непрерывной поставки
В этом примере мы расширим простое приложение 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.
Автоматическое развертывание в промежуточной среде завершено
На этом этапе наше приложение 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 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 наши изменения кода будут пропущены через весь конвейер (при этом будут выполняться сборка и тестирование кода), а затем, после успешной проверки того, работает ли промежуточная среда, развертывание кода будет выполнено в рабочей среде. В этом случае сообщение на главной странице было изменено, подтверждая, что приложение будет успешно развертываться во всех средах, вплоть до рабочей.
Наше новое сообщение отправилось в рабочую среду, как и ожидалось!
Проверка, прошел ли код через конвейер
Прежде чем приступать к внедрению непрерывного развертывания в своих репозиториях, обеспечьте наличие эффективного комплекта тестов, а также отлаженного мониторинга в режиме реального времени. Отныне изменения будут поступать непосредственно в рабочую среду сразу после отправки кода в ветку main, поэтому очень важно убедиться, что ключевые части приложения проверяются автоматическими тестами. Кроме того, вам потребуются инструменты мониторинга для обнаружения изменений, которые отрицательно сказываются на функциональности экземпляров рабочей среды, вызывая полный отказ или снижая качество обслуживания.
Окончательную версию исходного кода можно найти в репозитории Bitbucket Cloud, ссылка на который приведена ниже.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Сообщество DevOps
Образовательные программы DevOps
