Версія - це те, про що я дуже захоплююсь і витратив тривалий час, намагаючись придумати просту у користуванні систему версій. З того, що ви вже сказали у своєму запитанні, видно, що ви зрозуміли один важливий момент, номери версій збірки не є синонімом версії продукту. Один технічно керований, а другий - бізнес.
Далі передбачається, що ви використовуєте певну форму управління джерелом і сервер збірки. Для контексту ми використовуємо TeamCity та Subversion / Git. TeamCity безкоштовний для невеликої (10) кількості проектів і є дуже хорошим сервером збірки, але є й інші, деякі з яких є абсолютно безкоштовними.
Що означає номер версії
Те, що версія означає для однієї людини, може означати щось інше для іншої, загальна структура - основна, другорядна, макро, мікро. Те, як я дивлюсь на номер версії, - це розбити її на дві частини. У першій половині описується основна версія (основна) та будь-які ключові оновлення (мінор). Друга половина вказує, коли вона була побудована та якою була версія вихідного коду. Номери версій також означають різні речі залежно від контексту, це API, веб-додаток тощо.
Major. Minor. Build.Revision
Revision Це число, взяте з джерела контролю для виявлення того, що насправді було побудовано.BuildЦе постійно зростаюча кількість, яку можна використовувати для пошуку конкретної збірки на сервері збірки. Це важливе число, оскільки сервер збірки, можливо, двічі будував одне і те ж джерело з різним набором параметрів. Використання номера збірки спільно з номером-джерелом дозволяє визначити, що було побудовано та як.MinorЦе має змінитись лише тоді, коли відбудеться значна зміна загальнодоступного інтерфейсу. Наприклад, якщо це API, чи споживаючий код все-таки вдасться зібрати? Це число повинно бути скинуто до нуля, коли зміниться Основне число.Majorвказує, яку версію продукту ви використовуєте. Наприклад, майором усіх зборів VisualStudio 2008 є 9, а VisualStudio 2010 - 10.
Виняток із правила
З правила завжди є винятки, і вам доведеться адаптуватися, коли ви натрапляєте на них. Мій оригінальний підхід базувався на використанні підриву, але нещодавно я перейшов до Git. Управління джерелами, як підривна та безпечна для джерел, що використовують центральний сховище, має номер, який може бути використаний для ідентифікації певного набору джерел у заданий час. Це не стосується управління розподіленими джерелами, наприклад, Git. Оскільки Git використовує розподілені сховища, які є на кожній машині розробки, немає автоматичного збільшення номера, який ви можете використовувати, є хак, який використовує кількість реєстрацій, але це некрасиво. Через це мені довелося розвивати свій підхід.
Major. Minor. Macro.Build
Номер редакції тепер пішов, збірка перемістилася туди, де раніше була редакція, і макрос був вставлений. Ви можете використовувати макрос як вважаєте за потрібне, але більшу частину часу я залишаю його в спокої. Оскільки ми використовуємо TeamCity, інформацію, втрачену з ревізійного номера, можна знайти в збірці, це означає, що є двоступеневий процес, але ми нічого не втратили і є прийнятним компромісом.
Що встановити
Перше, що потрібно зрозуміти, це те, що версія збірки, версія файлу та версія продукту не повинні збігатися. Я не прихильник наявності різних наборів чисел, але це значно полегшує життя при внесенні невеликих змін у збірку, які не впливають на жодні публічні інтерфейси, які ви не змушені перекомпілювати залежні збірки. Я вирішую це з приводу того, щоб лише встановити основні та малі номери у версії збірки, але встановити всі значення у версії файлу. Наприклад:
- 1.2.0.0 (AssemblyVersion)
- 1.2.3.4 (FileVersion)
Це дає вам змогу виконувати гарячі виправлення, які не порушують існуючий код, оскільки версії збірки не збігаються, але дозволяють переглянути перегляд / складання збірки, переглянувши його номер версії файлу. Це загальний підхід і його можна побачити на деяких збірках з відкритим кодом, коли ви переглядаєте деталі складання.
Ви, як керівник Команди, повинні відповідати за збільшення незначної кількості, коли потрібні незмінні зміни. Одним із варіантів розгортання необхідної зміни інтерфейсу, але не порушення попереднього коду, є позначення поточного як застарілого та створення нового інтерфейсу. Це означає, що наявний код попереджається про те, що метод застарілий і його можна буде видалити будь-коли, але не вимагає, щоб ви зламали все негайно. Потім ви можете видалити застарілий метод, коли все було перенесено.
Як провести це разом
Ви можете зробити все вищезазначене вручну, але це буде забирати багато часу, далі - як ми автоматизуємо процес. Кожен крок можна виконати.
- Видаліть атрибути
AssemblyVersionта AssemblyFileVersionатрибути з усіх файлів проекту AssemblyInfo.cs.
- Створіть загальний файл інформації про збірку (називайте його VersionInfo.cs) та додайте його як пов'язаний елемент до всіх своїх проектів.
- Додайте
AssemblyVersionта AssemblyFileVersionатрибути до версії зі значеннями "0.0.0.0".
- Створіть проект MsBuild, який будує ваш файл рішення.
- Додайте завдання перед збіркою, яка оновлює VersionInfo.cs. Існує декілька бібліотек MsBuild з відкритим кодом, які містять завдання AssemblyInfo, за допомогою яких можна встановити номер версії. Просто встановіть його на довільне число і протестуйте.
- Додайте групу властивостей, що містить властивість для кожного з сегментів номера збірки. Тут ви встановлюєте головне та другорядне. Номер збирання та перегляду повинен бути переданий як аргументи.
З підривом:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
Сподіваюсь, я зрозумів, але в цьому багато чого. Будь ласка, задайте будь-які питання. Я буду використовувати будь-який зворотній зв'язок, щоб скласти більш стисну публікацію в блозі.