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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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