Интегрировать версии git как номера сборки или нет?

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

Мы считаем, что достоинства включают в себя:

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

Проблемы, которые возникли (для нас), включают в себя:

• Системы сборки, производные от IDE (например, MPLABX), могут затруднить поиск мест для размещения этих типов хуков (и в итоге это может оказаться довольно глупым)
• Больше работы для фактической интеграции этого в скрипты сборки / make-файлы
• Соединение с конкретным подходом к сборке (например, что, если один человек строит с помощью XCode, а другой MPLABX) может создать сюрпризы

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

Есть ли обоснованный ответ, на какую сторону лучше приземлиться?

Мы используем git description с тегами версий. Поток в основном:

• создать тег для версии, над которой мы работаем (например, v1.1.2)
• каждый запуск сборки git describe
• когда мы отправляем, используйте имя тега

git describeпредоставляет имя тега, количество коммитов с момента тега и хэш тега. Пример тега выглядит так:

v1.1.2-6-a3b27gae

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

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

В настоящее время у нас есть немного более сложная версия этого, но идея остается.

Раньше мы были магазином SVN, поэтому эта математика была проста - номер сборки был SVN rev, и это было так. Мы попытались сохранить это, когда начали переходить на DCVS, и обнаружили, что это не удалось по нескольким причинам.

Во-первых, кто знает, является ли rev 69bc333bc8d8 до, после или одновременно с rev 25b0f0d1052c? Существует очень мало контекста по сравнению с системой SVN, когда вы, по крайней мере, знали, что 101 был после 100. Во-вторых, природа контроля источника DCVS делает вещи нелинейными во многих отношениях, когда последующие сборки могут не продвигаться по тому же шару.

Мы наконец-то решили использовать сервер сборки для распределения номеров сборки по вещам, так как он имел правильную видимость и способность справляться с этим.

Я использую следующую схему для системы сборки Visual Studio библиотеки C # DLL для автоматического генерирования номеров версий (у нас исторически были проблемы с развертыванием, которое выполнялось неправильно, поэтому требовался чистый способ гарантировать правильное развертывание версии).

• Major - жестко закодированный 1, как правило, определяется бизнес-стороной
• Незначительный - жестко закодированный 0, как правило, определяется бизнес-стороной
• Редакция - Количество дней с 1 января 2010 г. (или любая другая произвольная дата начала)
• Build - половина числа секунд с полуночи (поскольку это 16-разрядное число без знака)

Обратите внимание, что это предполагает, что у вас есть 2 функциональных 16-битных числа без знака для игры. Создание эквивалентной системы, которая использует меньшие числа, также может быть сделано.

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

Я напрямую связываю вывод состояния git, log и diff в исполняемый файл. Тогда есть возможность напечатать это. Преимущество заключается в том, что вы можете не только выяснить, из какой ветки был собран ваш бинарный файл, но и какие незафиксированные изменения исходного кода включены. Посмотри пожалуйста:

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

Вы должны быть в состоянии использовать эти 3 файла для создания своей собственной библиотеки состояний SCM.

Я бы порекомендовал использовать Autorevision .

Вы можете получить вывод в различных форматах, например, заголовок в стиле c .

Есть также несколько примеров (в директории contribs) того, как вы можете соединить вещи так, чтобы независимо от того, кто строит и как они это делают, они всегда получали одинаковую информацию о версии, даже если они строят из tarball.

Кроме того , поскольку в дополнение к gitAutorevision работает svnи hgэто делает проще переключаться от SVN без изменения слишком много , как только вы его создали.