Як ви тримаєте випущені бінарні файли під контролем версій?

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

Два варіанти:

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

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

Так чи інакше, бінарні файли та інший вихід збірки не належать під контролем джерела з численних причин.

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

Дивіться, наприклад, сховища Maven як сховище для архівування / публікації / пропозиції випусків та інших бінарних файлів (наприклад, таких як документація)

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

Більшість дельта-бінарних файлів SCM досить добре, ми використовували для того, щоб увімкнути dll ресурсу 2 Мб у наш SVN, і він буде дельтувати до декількох кб кожного разу.

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

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

Я не тримаю бінарні файли випуску під контролем версій. Натомість я публікую їх у чітко визначеному місці, щоб інші інструменти перевіряли та використовували їх. Я багато працюю в Java, тому це означає, що я публікую Jars у місцевих сховищах Maven. Однак я не використовую ці інструменти для відстеження того, що змінилося за випуск. Зрештою, вони є двійковими файлами, і відстежити, окрім кількості файлів, насправді не так багато.

Для того, щоб відстежувати зміни між випусками, я маю теги або мітки випусків у своїй системі управління версіями з номером версії випуску. Але це насправді лише для відстеження вихідних файлів, а не бінарних файлів. Бінарні файли - це артефакти збірки, і їх не потрібно контролювати версії.

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

Це систематично прив’язує звільнені бінарні файли до вмісту сховища, не потребуючи фактичного зберігання бінарних файлів у сховищі.

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

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

• / builds / trunk / [rev] [дата] [build_id] /
• / builds / tags / release_0_1_3beta4 / [rev] [дата] [build_id] /

Системі збірки потрібно буде ставитись до каталогу / builds / trunk /, як до кругового буфера, зберігаючи останні n збірки, видаляючи старі збірки в міру його виконання.

Каталог / builds / tags / , з іншого боку, є постійним магазином. Самі артефакти збірки зберігаються в каталогах з іменами, згенерованими відповідно до наступної схеми:

• [rev] [дата] [build_id]

де [rev] - ідентифікаційний номер редакції SVN, [дата] - дата у форматі YYYYMMDD, а [build_id] - це 3-значний унікальний лічильник, що збільшується від першої збірки вперед, що робить кожен каталог збірки унікальним.

Детально описаний вище процес дає вам наступні переваги:

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

2. Це є основою для подальшої автоматизації випуску. Наприклад, автоматична генерація документів, що випускаються тощо ...