Почему мы должны разделять сборку и выпуск на разные конвейеры?
Благодаря современным инструментам DevOps у нас есть возможность разбить непрерывную интеграцию (CI) и непрерывное развертывание (CD) на несколько этапов.
И мы обычно разделяем конвейер, учитывая различные факторы, такие как:
- Производительность — сокращение времени выполнения, например максимальное использование ресурсов за счет параллелизма.
- Повторное использование. Повторно используйте определенные шаги в сложном конвейере, например, создание внешнего интерфейса для разных языков, где большую часть сборки можно использовать повторно.
- Повторяемость. При необходимости повторите определенные шаги, например, выпуск одной и той же сборки для другой среды.
- Отказоустойчивость: повторите попытку при частичных сбоях в конвейере.
- Снижение затрат — снижение общих затрат на выполнение.
Более того, некоторые из этих факторов повлияли на то, как мы настраиваем конвейеры CI/CD.
Одним из таких шаблонов является разделение сборки и выпуска на отдельные конвейеры.
Итак, в этой статье давайте рассмотрим причины такого разделения и преимущества, которые вы получите, сделав это на практике. Давайте начнем.
Зачем отдельные конвейеры?
Технически мы можем определить сборку и выпуск в одном конвейере. Однако это создает несколько проблем, влияющих на эффективность конвейера.
Основная причина заключается в том, что сборка и выпуск решают две разные задачи.
Некоторые из вас могут задаться вопросом: разве сборка не является предшествующим этапом перед выпуском?
Несмотря на то, что это предшествующий этап, обычно у нас есть несколько этапов сборки перед выпуском. Один — при создании запросов на включение (или запросов на слияние), а другой — после слияния ветки.
Первый в основном сосредоточен на том, чтобы как можно скорее предоставить разработчику обратную связь;
- Качество кода.
- Модульные тесты.
- Тестовое покрытие.
- Оценки уязвимости.
Это помогает обнаруживать и исправлять любые ошибки, не обнаруженные в среде разработки, перед объединением кода в общую ветку.
Последний этап связан с релизом.
Тем не менее, разделение сборки и выпуска ветки имеет смысл, если мы планируем сохранить стадию сборки для создания артефактов, которые можно развернуть в нескольких средах.
Что входит в стадию сборки?
Этап сборки состоит из всех тестов, которые мы запускаем поверх кодовой базы, и сценариев для компиляции, транспиляции или минимизации кода в развертываемый артефакт.
В некоторых случаях у нас могут быть параметризованные сборки, ориентированные на разные локали. Хорошим примером может служить создание приложений Angular, где мы создаем интерфейсные артефакты для каждой локали.
И шаги довольно просты.
Сборка запроса на слияние
- Получите код PR агенту сборки.
- Скомпилируйте, транспилируйте или минимизируйте код.
- Запускайте проверки кода, которые не отнимают много времени. (например, модульные тесты, качество кода и т. д.)
- Обновите результаты (до самого пиара и инструментов освещения).
Сборка ветки
- Получить код из ветки в агент сборки.
- Скомпилируйте, транспилируйте или минимизируйте код.
- Запускайте проверки кода (быстрые проверки + комплексные тесты, такие как интеграционные тесты, e2e-тесты).
- Загрузите артефакты на стадию выпуска.
Стадия развертывания отличается
Как следует из названия, на этом этапе мы выполняем развертывание приложения в указанной среде. Он также поддерживает выбор сред, таких как Dev, QA, Stage, Production и откаты, в качестве мер безопасности.
На этом этапе вы можете включить шаги для внедрения переменных среды.
Кроме того, в зависимости от вашей стратегии развертывания может быть создано новое окружение (например, сине-зеленая разработка). Таким образом, цель этого этапа может быть более сложной, чем просто выпуск продукта.
Что, если это всего лишь один конвейер?
Да, мы можем использовать один конвейер как для сборки, так и для выпуска, как я упоминал выше. Но дело в том, что он имеет несколько ограничений.
Изучив, что они из себя представляют, вы, вероятно, поймете, почему отдельные конвейеры — лучшее решение, как и я.
1. Приходится создавать все с нуля для каждой среды
Предположим, мы однажды запустили конвейер сборки и на этот раз хотим выпустить его в другую среду.
Нет другого выбора, кроме как перезапустить весь конвейер, включая процесс сборки. Но, к сожалению, это неэффективно и является пустой тратой ресурсов.
2. Артефакты могут меняться с обновлениями
Рассмотрим ситуацию, когда вы запускаете один конвейер для одной среды и повторно запускаете ту же сборку (тот же код) через некоторое время для другой среды.
Сборка, скорее всего, устанавливает зависимости, такие как NPM, а иногда обновляются младшие версии или версии исправлений. Из-за этого существует вероятность того, что окончательные артефакты для одной среды будут отличаться от других.
Совет: Создавайте с независимыми компонентами для скорости и масштаба.
Вместо создания монолитных приложений сначала создайте независимые компоненты и объедините их в функции и приложения. Это ускоряет разработку и помогает командам создавать более согласованные и масштабируемые приложения.
Бит предлагает отличный опыт разработчика для создания независимых компонентов и создания приложений. Многие команды начинают с создания своих дизайн-систем или микроинтерфейсов с помощью независимых компонентов.
Попробуйте →
Создание отдельных конвейеров сборки и выпуска с помощью Azure DevOps
Когда мы рассматриваем популярные инструменты DevOps, такие как Azure DevOps, они предлагают конвейер для сборки и отдельный тип конвейера, называемый выпуском.
Он придерживается философии разделения конвейеров сборки и выпуска и облегчает их выпуск в нескольких средах. Но в некоторых инструментах процесс разбивается на этапы, последним из которых является этап развертывания.
Давайте рассмотрим, как мы можем шаг за шагом настроить Azure DevOps, чтобы получить более полное представление.
Предпосылки:
- Организация Azure DevOps.
- Учетная запись GitHub (вы также можете использовать Azure DevOps для репозитория кода).
- Приложение React.
Вы можете создать бесплатную организацию Azure DevOps, чтобы попробовать это. Кроме того, вы также можете использовать действия GitHub. Но сегодня мы собираемся реализовать это с помощью Azure DevOps. Итак, давайте все автоматизировать.
Построить конвейер
1. Новый проект
Сначала давайте создадим новый проект в вашей учетной записи Azure DevOps.
2. Код регистрации
Теперь добавьте свой локальный проект React в репозиторий Git. Вы можете использовать;
git initgit add .git commit -m “message”
Чтобы создать репозиторий из кода Visual Studio. Затем вы можете использовать приведенную ниже команду с вашими учетными данными, чтобы отправить приложение с локального компьютера в ваш проект Azure.
git remote add origin https://[email protected]/organization/projectname/_git/build-release git push -u origin --all
И теперь, если вы обновите страницу Azure DevOps, код приложения React должен появиться в разделе файлов.
3. Измените конфигурацию конвейера YML
Давайте создадим конвейер сборки. Но сначала давайте откроем конфигурацию конвейера, хранящуюся в файле azure-pipeline.yml.
Конвейеры (Панель навигации) -> Конвейеры -> Создать конвейер -> Выберите Azure Repos Git -> Выберите только что добавленный репозиторий -> Выберите Node.js с React, если ваш проект является приложением React -> файл azure-pipeline.yml
Вы можете изменить файл, включив в него переменные, определенные следующим образом.
И после этого вы можете изменить раздел скрипта, чтобы использовать эти переменные.
Теперь нажмите, показать помощник (в правом верхнем углу) -> Архивировать файлы.
После изменения имени корневой папки нажмите кнопку «Добавить», чтобы продолжить.
4. Публикация артефактов
Теперь давайте посмотрим, как опубликовать этот артефакт. На той же вкладке Show Assistant выберите Publish Build Artifacts. Всегда не забывайте помещать курсор в конец файла. Вот где добавляется дополнительный код.
Нажмите «Добавить», и мы готовы к запуску. Итак, нажмите «Сохранить и запустить».
Вы увидите, что работа выполняется. А если вы получите ошибку о том, что у вас нет бесплатного гранта на параллелизм, вы можете запросить его здесь.
Теперь вы можете найти артефакты в папке Drop задания. Он содержит содержимое папки сборки.
Конвейер выпуска
1. Выбор шаблона
Создайте новый конвейер в разделе «Релизы» на вкладке «Конвейеры». Выберите там Развертывание службы приложений Azure.
2. Выбор артефактов
Нажмите «Добавить артефакт» и выберите артефакт из нашего предыдущего задания.
Давайте включим триггер непрерывного развертывания, щелкнув значок молнии над добавленным нами артефактом.
3. Выбор среды развертывания
После этого мы можем настроить сведения о службе приложений Azure, щелкнув задание 1, ссылку задачи на созданном нами этапе.
Заполните поля и сохраните. Теперь вы можете вернуться и создать «новый выпуск» для развертывания приложения.
Окончательно
Я надеюсь, что после прочтения статьи вы полностью осознали ценность разделения конвейеров сборки и выпуска в DevOps.
Кроме того, многие инструменты, такие как Azure DevOps, поощряют это, поскольку это общеизвестная передовая практика. И, надеюсь, вы будете использовать это разделение в своем следующем проекте.
Если у вас есть какие-либо вопросы, дайте мне знать в комментариях ниже. Спасибо за прочтение !!
Создавайте компонуемые веб-приложения
Не создавайте веб-монолиты. Используйте Bit для создания и компоновки несвязанных программных компонентов — в ваших любимых фреймворках, таких как React или Node. Создавайте масштабируемые интерфейсы и серверные части с мощным и приятным опытом разработки.
Перенесите свою команду в Bit Cloud, чтобы совместно размещать и совместно работать над компонентами, а также значительно ускорить, масштабировать и стандартизировать разработку в команде. Начните с компонуемых интерфейсов, таких как Design System или Micro Frontends, или исследуйте компонуемый сервер. Попробуйте →
