Рекомендации по информации о версии?

Question

В настоящее время я работаю над автоматизацией/улучшением процесса выпуска для упаковки всего продукта моего магазина. В настоящее время продукт представляет собой сочетание:

• Java на стороне сервера кодовой базы
конфигурации и файлы приложения
• XML
• Shell и пакетные сценарии для администраторов
• Статически обслуживаемого HTML страницы
• и некоторые другие вещи , но это больше всего.

Все или большинство из них имеют различную информацию о версиях, содержащуюся в них, нас для разных целей. Часть процесса выпуска упаковки включает в себя множество поисков, grep'ing и sed'ing (в скриптах) для обновления информации. Этот клей, который упаковывает продукт, кажется, был вымощен органически, точно в срок, и довольно ужасен для поддержания. Например, некоторые Java-методы создают объекты Date на время выпуска, аргументы для которых обновляются текстовой заменой, без проверки компилятора ... just, urgh.

Я стараюсь избегать примеров использования фактического программного обеспечения (например, CVS, SVN, ant и т. Д.), Потому что я хотел бы избежать использования функции xyz для этого »и больше сосредоточиться на общих практиках. Я бы хотел обвинить дряблый дизайн проблемы, но если бы мне пришлось начинать заново, все еще используя разные технологии, я бы не знал, как лучше всего справляться с этим, помимо принятия конвенций.

Мои вопросы: есть ли какие-либо рекомендации или подсказки и советы по поддержанию и обновлению информации о версиях по различным технологиям, типам файлов, платформам и системам контроля версий?

Answer 1

Действительно, чтобы завершить ответ Craig Ангуса, эмпирическое правило здесь должно быть до не содержат метаданных в ваших нормальных файлах доставки, но сообщить эти метаданные (номер версии, дату выпуска и т. д.) в один специальный файл - включен в релиз.

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

Когда вы готовите доставку (набор упакованных файлов), вы должны спросить об этом инструменте VCS о каждой метаинформации, которую вы хотите сохранить, и записать в специальный файл, включенный в указанный набор файлов.

что поставка должна быть упакована во внешнем каталоге (вне любого рабочего пространства), а также:

• копируется в общий каталог (или хранилище Maven), если он является неофициальными релизом (но просто быстрая упаковка, помогающая команде по соседству, которая ждет вашу доставку). Таким образом, вы можете сделать 10 или 20 дней в день, это не имеет значения: они легко доступны.

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

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

Answer 2

Создайте файл свойств, который содержит номер версии и все различные компоненты ссылаться на файл свойств

• Java файлы могут ссылаться на свойства через
• XML можно использовать включает в себя?
• HTML может использовать JavaScript, чтобы записать номер версии из свойств в HTML
сценарии
• Shell можно прочитать в файле

Answer 3

В дополнение к тому, что Крейг Ангус включает в себя версию используемых инструментов.