Інтегрувати версії git як номери збірки чи ні?

Ми з колегою по черзі обговорювали / обговорювали проблеми / достоїнства інтеграції версії, отриманої з поточного сховища git, до нашого коду кожного разу, коли вона створюється.

Ми вважаємо, що заслуги включають:

• Не потрібно турбуватися про помилки людини при оновленні номера версії
• Простежуваність між тим, що ми знаходимо в пристрої, та вихідним кодом, з якого він отриманий

Питання, що виникли (для нас), включають:

• Системи побудови IDE (наприклад, MPLABX) можуть ускладнити розуміння, куди можна розмістити ці гачки (і в кінцевому підсумку це може бути досить ситним)
• Більше роботи над тим, щоб насправді інтегрувати це в сценарії складання / makefiles
• З'єднання з конкретним підходом побудови (наприклад, що якщо одна людина будує з XCode, а інша MPLABX) може створювати сюрпризи нижче за течією

Тож нам цікаво, де інші приземлилися на цій дискусії. Це дуже просто, щоб дискусія стала анекдотичною. Там багато людей, які наполягають на автоматизації в кінці, підвішують кількість передньої роботи та з'єднання, яке вона створює. І є багато інших з іншого боку дебатів, які просто роблять найпростіше, що працює і живе з ризиками.

Чи є аргументована відповідь, на яку сторону краще приземлитися?

Ми використовуємо опис git з тегами версій. Потік в основному:

• створити тег для версії, над якою ми працюємо (наприклад, v1.1.2)
• кожен запуск збірки git describe
• коли ми відправляємо, використовуйте ім’я тегів

git describeнадає ім'я тегу, кількість комірок з моменту тегу та хеш тегу. Зразок тегу виглядає так:

v1.1.2-6-a3b27gae

Це має перевагу в тому, що розробники отримують хеші, тому якщо щось перерветься між збірками, розробник може легко розмежувати зміни. Також дурно просто керувати; просто попросіть команду створити та натиснути тег на новій гілці помилок, і ваша система збирання подбає про інше.

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

Наразі у нас є дещо складніша версія цього, але ідея залишається.

Ми були магазином SVN, тому ця математика була простою - номер збірки був SVV оборотом, і це було те. Ми намагалися продовжувати це, коли ми почали переходити до DCVSes і виявили, що це не вдалося з кількох причин.

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

Ми нарешті вирішили використовувати сервер збірки для розподілу номерів збірки на речі, оскільки він мав правильну видимість та можливість обробляти це.

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

• Основний - жорстко кодований 1, зазвичай визначається стороною бізнесу
• Незначні - жорстко кодовані 0, зазвичай визначаються сторонами бізнесу
• Версія - кількість днів з 1 січня 2010 року (або будь-яка інша довільна дата початку)
• Збірка - Половина кількості секунд з півночі (Оскільки це 16-бітне неподписане число)

Зауважте, що це передбачає, що у вас є 2 мінливі 16-бітні безпідписані номери. Створення еквівалентної системи, яка використовує менші числа, також може бути зроблена.

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

Я безпосередньо пов'язую висновок статусу git, журналу та відрізняюся від виконуваного файлу. Тоді є можливість роздрукувати це. Перевага полягає в тому, що ви не тільки можете зрозуміти, з якої гілки було побудовано ваш бінарний файл, але і які невмінні зміни вихідного коду включаються. Будь ласка, дивіться:

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

Ви повинні мати можливість використовувати ці 3 файли, щоб зробити свою власну SCB-контенту.

Я б рекомендував використовувати Авторевізію .

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

Також є декілька прикладів (в редакції dir), як можна підключити речі, так що незалежно від того, хто будує і як вони це роблять, вони завжди отримуватимуть однакову інформацію про версію, навіть якщо вони будуються з тарболу.

Крім того, оскільки на додаток до програми gitAutorevision працює svnі hgполегшується перемикатися з svn, не змінюючи занадто сильно після встановлення.