Как улучшить процесс сборки и развертывания?
Наш процесс сборки / развертывания очень утомителен, достаточно ручен и подвержен ошибкам. Не могли бы вы дать предложения по улучшению?
Итак, позвольте мне описать нашу стратегию развертывания и процесс сборки. Мы разрабатываем систему под названием Сервер приложений (для краткости AS). По сути, это веб-приложение на основе сервлетов, размещенное на веб-сервере JBoss. AS может быть установлен в двух "средах". Каждая среда представляет собой каталог с кодом веб-приложения. Этот каталог размещен в сетевом хранилище. Хранилище смонтировано на нескольких производственных серверах, на которых установлены экземпляры JBoss. Каталог связан с JBoss' webapps каталог. Таким образом, все экземпляры JBoss используют один и тот же код для среды. Конфигурация JBoss отделена от среды и обновляется отдельно для каждого экземпляра.
Таким образом, у нас есть два типа исправлений: исправления веб-приложения (для разных сред) и исправления конфигурации (для конфигурации каждого экземпляра)
Патч - это исполняемый файл. Фактически это bash-скрипт со встроенным двоичным rpm-пакетом. Установка довольно проста: вы просто запускаете файл и при необходимости отвечаете на некоторые вопросы. Важным моментом является то, что исправление не является системой в целом - оно содержит только некоторые классы с исправлениями и / или сценариями, которые изменяют файлы конфигурации. Классы копируются в WEB-INF/classes (AS развертывается как развернутый каталог).
То, как мы строим эти пути:
- Мы берем некоторые предыдущие файлы патчей и копируем их.
- Мы модифицируем содержимое патча. Самая важная часть этого - спецификация RPM. Там мы меняем имя патча, меняем его обязательные rpm-пакеты и записываем фактические команды bash для резервного копирования, копирования и изменения файлов. Это одна из самых раздражающих частей, потому что мы не всегда можем получить реальный набор изменений. Это особенно верно для новых сложных функций, которые охватывают несколько запросов на изменение и фиксацию. Кроме того, написание этих команд для набора изменений утомительно и подвержено ошибкам.
- Для патчей веб-приложений мы также изменяем спецификации для других сред. Обычно они идентичны, за исключением имени пакета rpm.
- Мы помещаем все связанные с RPM файлы в VCS
- Мы модифицируем build.xml, добавив несколько целей для создания нового патча. Модификация осуществляется путем копирования и редактирования.
- Мы изменяем конфигурацию CruiseControl, копируя проект и изменяя в нем цели муравья
- Наконец, мы строим систему
Кроме того, меня интересуют любые рекомендации по подготовке и развертыванию исправлений, предпочтительно для приложений Java. Я не смог найти это в Google.
2 ответа
В месте, где я работаю, были похожие проблемы, но, возможно, не такие сложные.
Мы ответили, полностью исключив концепцию патча. Мы перестали вносить исправления и начали просто устанавливать все приложение (даже если мы сделаем небольшое изменение).
Теперь у нас есть готовые установочные комплекты Cruise Control, которые содержат временную метку сборки в имени установочного комплекта. Это артефакт сборки круиз-контроля.
Cruise Control автоматически устанавливает их на тестовом сервере и запускает некоторые автоматические дымовые тесты. Затем мы запускаем ручные тесты на тестовом сервере. Затем мы устанавливаем артефакт на промежуточный, а затем на производственный сервер.
Избавление от исправлений привело к тому, что некоторые люди засыпали: "Разве это не расточительно, если вы просто меняете пару вещей?" и "почему вы перезаписываете все программное обеспечение, чтобы просто что-то исправить?"
Но правда в том, что хороший контроль исходного кода, автоматическая сборка установочного комплекта и одностадийная установка сэкономили нам массу времени. Установка занимает несколько секунд, но мы можем сделать это гораздо чаще и с меньшими затратами труда на разработку.
Мы также пытаемся перейти к выпускам исправлений / исправлений, а также к выпуску полных установочных пакетов на основе RPM.
Должен сказать, что я также согласен с тем, что в большинстве случаев это бесполезная трата, и я бы также хотел выпустить полный установочный пакет, предполагая, что у вас уже есть установленный конвейер сборки.
В нашем случае у нас есть многомодульная доставка, каждая из которых упакована в RPM и завернута в ISO для доставки. Мы стремимся сохранить наш сборочный конвейер в основном неизменным для выпуска исправлений. Поэтому вместо этого мы сосредоточены на том, чтобы сделать наши RPM более детализированными (меньшими - более целевые RPM), чтобы мы могли выпускать только те RPM, которые содержат измененные артефакты, для определенного исправления / исправления.
Таким образом, RPM с полной версией и RPM с исправлениями одинаковы, единственное различие заключается в количестве RPM, которые вы упаковываете в ISO доставки.
У меня есть еще один вопрос, касающийся этой проблемы, вы можете посмотреть там: