Статьи
Обучающие материалы
Интерактивные руководства
Узнайте, как реализовать непрерывную поставку с помощью Bitbucket Pipelines
Стен Питтет
Приглашенный автор
В этом руководстве мы увидим, как можно внедрить рабочий процесс непрерывной поставки с помощью Bitbucket Pipelines. Читайте дальше!
Время
30 минут
Аудитория
Если вы только начинаете работу с непрерывным развертыванием и/или Bitbucket Pipelines
Выпуск новой возможности — это всегда приятный момент, поскольку вы собираетесь предоставить новый функционал своим клиентам. Но также это может быть рискованным делом, требующим серьезной подготовки, из-за чего ваша команда будет опасаться делать это часто. И чем дольше вы ждете, тем труднее становится развертывание в рабочей среде. Изменения накапливаются, становится трудно анализировать масштаб изменений и выявлять основные причины проблем при их возникновении в рабочей среде.
Простой способ избавиться от опасений и расходов, связанных с развертыванием ПО, заключается в автоматизации процесса развертывания и релизе изменений небольшими порциями, но чаще. Прежде всего это экономит бесчисленные часы, которые обычно тратятся на подготовку релиза. Кроме того, это сокращает риски при развертывании ПО, поскольку объем работ по каждому релизу становится меньше, мониторинг сред — проще, и устранить проблемы не составляет труда.
Такую автоматизацию развертывания сегодня можно легко осуществить с помощью Bitbucket Cloud. Для каждого из ваших репозиториев можно настроить конвейер, который будет автоматически выполнять сборку, проводить тесты и развертывать код в средах после каждого выполнения команды push. В этом руководстве будет показано, как внедрить рабочий процесс непрерывной поставки с помощью Bitbucket Pipelines.
Непрерывная поставка или непрерывное развертывание?
Непрерывная поставка — это методика, при использовании которой гарантируется, что код всегда готов к релизу, даже если вы не развертываете каждое изменение в рабочей среде. Рекомендуется обновлять рабочую среду как можно чаще, чтобы объем изменений всегда оставался небольшим, однако в конечном итоге частоту своих релизов контролируете вы.
При непрерывном развертывании новые изменения, отправляемые в репозиторий, автоматически развертываются в рабочую среду, если успешно проходят тесты. При этом создается большой упор (читай: давление) на культуру тестирования, однако это отличный способ ускорить цикл обратной связи с клиентами.
Внедрение конвейера непрерывной поставки
В этом примере мы расширим простое приложение node.js, созданное по инструкциям из руководства по непрерывной интеграции, добавив конвейер непрерывной поставки, который автоматически развертывает сборку в промежуточной среде после тестирования. Мы увидим две разные стратегии для развертывания в рабочей среде: в одной используются ветки и запросы pull, а в другой — специальные конвейеры и ручные триггеры.
В обоих примерах мы будет использовать простое приложение Node.js, отображающее в браузере сообщение «Hello World». Мы будем развертывать это приложение в промежуточной и рабочей средах, размещенных на Heroku, используя оба способа.
Очень простое приложение 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).
Далее добавьте в Bitbucket Pipelines переменную среды, чтобы мы могли осуществлять развертывание в Heroku:
- HEROKU_API_KEY: ключ API вы можете найти в своем аккаунте Heroku
Чтобы добавить эту переменную, перейдите к настройкам репозитория и откройте раздел Pipelines > Environment variables (Конвейеры > Переменные среды).
Настройка переменных среды для развертывания в Heroku
В этом руководстве мы используем Heroku, но, разумеется, этот пример можно адаптировать к другим сервисам хостинга. Используйте это руководство в качестве справочника по Heroku.
Непрерывная поставка с использованием веток, играющих роль шлюза перед рабочей средой
Эта конфигурация подходит для команд, имеющих специальные ветки релиза, которые можно сопоставить с конкретными развертываниями. Она также позволяет проверять изменения в запросе pull перед их развертыванием в рабочей среде.
В этой конфигурации мы будем использовать две разные ветки для запуска развертываний:
- main: любая отправка в главную ветку приведет к развертыванию кода в промежуточной среде после выполнения тестов.
- production: после слияния с веткой production код будет автоматически выпущен в рабочую среду.
Создайте в Bitbucket Cloud ветку production, нажав пункт Branches (Ветки).
Затем нажмите кнопку Create branch (Создать ветку).
Введите название «production» и нажмите кнопку Create (Создать).
Из корневого каталога тестового репозитория выполните следующие команды:
heroku create --remote staging
git push staging main
heroku create --remote production
git push production mainЧтобы убедиться в том, что команды выполнены корректно, перейдите в браузере к 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, и вы увидите, как впервые выполнится автоматическое развертывание в промежуточную среду.
Успешный конвейер, который развертывает наше приложение в промежуточной среде
Как вы могли догадаться, нам просто нужно добавить еще один конвейер для ветки 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 (Процесс > Права доступа к веткам) в настройках репозитория. Это важный шаг, так как мы хотим предотвратить отправку кода с локальных компьютеров прямо в рабочую среду.
Настройка разрешений для ветки рабочей среды
На вышеприведенном снимке экрана можно заметить права:
- Никто не имеет доступа с правом записи
- Только один разработчик может осуществлять слияние с веткой.
Мы также добавили проверку слияния, чтобы перед слиянием кода убедиться, что в исходной ветке есть хотя бы одна «зеленая» сборка. Это позволит нам сэкономить время сборки и запретить разработчикам делать слияние плохого кода с веткой рабочей среды.
Когда это будет сделано, можно создать запрос pull для слияния кода из главной ветки в ветку рабочей среды, а затем выпустить новые изменения в рабочую среду.
Создайте запрос pull для слияния изменений в рабочей среде
Как только вы выполните слияние запроса pull, то увидите, как запустится новый конвейер для ветки рабочей среды.
По завершении его работы новые изменения будут успешно развернуты в рабочей среде.
Рабочая среда обновлена!
Теперь вы настроили процесс непрерывной поставки с помощью 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 (Запустить конвейер) под информацией о коммите, чтобы запустить развертывание в рабочей среде.
При вызове действия запуска конвейера будет показан список доступных пользовательских конвейеров
Просто нажмите кнопку Run (Выполнить). Вы будете перенаправлены к конвейеру развертывания в рабочей среде, где сможете следить за журналами.
В разделе конвейера, содержащем информацию о коммите, можно увидеть имя пользовательского конвейера, который был использован. Теперь вы готовы использовать свою новую конфигурацию Bitbucket Pipelines для непрерывной поставки и можете проверить свое приложение Hello World в рабочей среде, чтобы убедиться, что все прошло хорошо.
Наше приложение «Hello World» было развернуто в рабочей среде с помощью ручного триггера
Окончательный исходный код этого примера можно найти в репозитории, ссылка на который приведена ниже.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Сообщество DevOps
Образовательные программы DevOps
