Лучшие практики для информации о версии?

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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