Как улучшить процесс сборки и развертывания?

Question

Наш процесс сборки / развертывания очень утомителен, достаточно ручен и подвержен ошибкам. Не могли бы вы дать предложения по улучшению?

Итак, позвольте мне описать нашу стратегию развертывания и процесс сборки. Мы разрабатываем систему под названием Application Server (для краткости AS). По сути, это веб-приложение на основе сервлетов, размещенное на веб-сервере JBoss. AS может быть установлен в двух «средах». Каждая среда представляет собой каталог с кодом веб-приложения. Этот каталог размещен в сетевом хранилище. Хранилище смонтировано на нескольких производственных серверах, на которых установлены экземпляры JBoss. Каталог связан с каталогом webapps JBoss. Таким образом, все экземпляры JBoss используют один и тот же код для среды. Конфигурация JBoss отделена от среды и обновляется отдельно для каждого экземпляра.

Итак, у нас есть два типа патчей: патчи для веб-приложений (для разных сред) и патчи для конфигурации (для конфигурации каждого экземпляра)

Патч - это исполняемый файл. Фактически это bash-скрипт со встроенным двоичным rpm-пакетом. Установка довольно проста: вы просто запускаете файл и при необходимости отвечаете на некоторые вопросы. Важным моментом является то, что исправление не является системой в целом - оно содержит только некоторые классы с исправлениями и / или сценариями, которые изменяют файлы конфигурации. Классы копируются в WEB-INF / classes (AS развертывается как развернутый каталог).

Как мы строим эти пути:

1. Мы берем несколько предыдущих файлов патчей и копируем их.
2. Мы модифицируем содержимое патча. Самая важная часть этого - спецификация RPM. Там мы меняем имя патча, меняем его обязательные rpm-пакеты и записываем фактические команды bash для резервного копирования, копирования и изменения файлов. Это одна из самых раздражающих частей, потому что мы не всегда можем получить реальный набор изменений. Это особенно верно для новых сложных функций, которые охватывают несколько запросов на изменение и фиксацию. Кроме того, написание этих команд для набора изменений утомительно и подвержено ошибкам.
3. Для исправлений веб-приложения мы также изменяем спецификации для других сред. Обычно они идентичны, за исключением имени пакета rpm.
4. Мы помещаем все связанные с rpm файлы в VCS
5. Мы модифицируем build.xml, добавив пару целей для создания нового патча. Модификация выполняется копированием и редактированием.
6. Мы изменяем конфигурацию CruiseControl, копируя проект и изменяя в нем цели муравья
7. Наконец, мы строим систему

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

Answer 1

В месте, где я работаю, были похожие проблемы, но, возможно, не такие сложные.

Мы отреагировали, полностью исключив концепцию патча.Мы перестали вносить исправления и начали просто устанавливать все приложение (даже если мы сделаем небольшое изменение).

Теперь у нас есть готовые установочные комплекты для круиз-контроля, которые содержат временную метку сборки в имени установочного комплекта.Это артефакт сборки Cruise Control.

Cruise Control автоматически устанавливает их на тестовом сервере и запускает некоторые автоматические тесты дыма.Затем мы запускаем ручные тесты на тестовом сервере.Затем мы устанавливаем артефакт на промежуточный, а затем на производственный сервер.

Избавление от исправлений привело к тому, что некоторые люди начали болтать: «Разве это не расточительно, если вы просто меняете пару вещей?»и «почему вы перезаписываете все программное обеспечение просто для того, чтобы что-то исправить?»

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

Answer 2

Мы также пытаемся перейти к выпускам исправлений / исправлений, а также к выпуску полных установочных пакетов на основе RPM.

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

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

Таким образом, RPM с полной версией и RPM-пакеты с патчами одинаковы, единственное отличие - это количество RPM, которые вы упаковываете в ISO доставки.

У меня есть еще один вопрос, касающийся этой проблемы, вы можете посмотреть на него:

Исправление патч-сборки для доставки подход