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

Question

Мы находимся в процессе адаптации нашей процедуры сборки и выпуска одного из наших продуктов на основе Java для поддержки выпусков исправлений / исправлений.

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

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

Я хотел бы услышать о том, как вы управляете конвейером сборки - упаковкой и управлением версиями (поскольку это также является основной проблемой управления выпусками) для поддержки такого рода развертываний исправлений?

Answer 1

Я хотел бы услышать о том, как вы управляете своим конвейером сборки - упаковка и контроль версий

Я ввел (рабочую) концепцию:

Отчет об ошибках в качестве идентификации, такой как bug711, для всех источников, которых коснулся, чтобы исправить эту ошибку, будет помечен (Контроль версий) отчетом об ошибке №.

Этот тег можно использовать для извлечения всех источников, необходимых для создания патча (в случаях, когда речь идет о статических файлах, таких как html,js,css и т. Д.), А также для объединения веток в головную ревизию.

В случае java-кода минимальным для развертывания будет артефакт (jar,ear,war-file). Который требует перезагрузки приложения. В случае сервера приложений JBoss мы обнаружили, что "развернутое" развертывание позволяет нам устанавливать патчи без простоев.

Это действительно зависит от серверной среды и типа приложений, которые лучше всего подойдут для вас. Боюсь, что нет единой лучшей практики.