Важкий досвід виграв мене, що майже все належить до управління джерелами. (Мої коментарі тут забарвлені півтора десятиліття, що розвиваються для вбудованих / телекомунікаційних систем на власні пристрої з власними, а іноді і важко знайти).
Деякі з відповідей тут говорять: "не ставити двійкові файли в управління джерелами". Це неправильно. Коли ви працюєте над продуктом з великою кількістю стороннього коду та безліччю бінарних бібліотек від постачальників, ви перевіряєте в бінарних бібліотеках . Тому що, якщо ви цього не зробите, то в якийсь момент ви збираєтеся оновити, і ви зіткнетеся з проблемою: збірка перервана, оскільки машина для збирання не має останньої версії; хтось дарує новому хлопцеві старі компакт-диски для встановлення; у вікі проекту є несвіжі інструкції щодо того, яку версію встановити; І ще гірше, якщо вам доведеться тісно співпрацювати з постачальником, щоб вирішити певну проблему, і вони надсилають вам п'ять наборів бібліотек за тиждень, ви повиннівміти відстежувати, який набір бінарних файлів демонстрував, яку поведінку. Система управління джерелом - це інструмент, який вирішує саме цю проблему.
Деякі з відповідей тут говорять "не ставити ланцюжок інструментів у контроль джерел". Я не скажу, що це неправильно, але найкраще поставити ланцюжок інструментів у керування джерелами, якщо у вас немає системи управління твердою конфігурацією (CM) . Ще раз, розгляньте проблему оновлення, як згадувалося вище. Що ще гірше, я працював над проектом, коли чотири окремих аромату інструментальної ланцюга плавали навколо, коли мене найняли - всі вони в активному використанні ! Однією з перших речей, які я зробив (після того, як мені вдалося домогтися роботи), було поставлено ланцюжок інструментів під контроль джерел. (Ідея міцної системи КМ була поза надією.)
А що відбувається, коли різні проекти вимагають різних ланцюжків інструментів? Справа в суті: Через пару років один з проектів отримав оновлення від постачальника, і всі Makefiles зламалися. Виявляється, вони покладалися на новішу версію виробництва GNU. Таким чином, ми все модернізували. Ну, ще один Makefiles проекту зламався. Урок: введіть обидві версії GNU make і запустіть версію, яка постачається з замовленням проекту.
Або якщо ви працюєте в місці, де все інше дико виходить з-під контролю, у вас є розмови на кшталт "Гей, сьогодні починається новий хлопець, де CD для компілятора?" "Данно, не бачив їх з тих пір, як Джек відмовився, він був охоронцем компакт-дисків". "Ага, чи не це було раніше, ніж ми піднялися з другого поверху?" "Можливо, вони в коробці чи щось таке". А оскільки інструментам три роки, сподівання отримати цей старий компакт-диск від постачальника немає.
Усі ваші сценарії побудови належать до управління джерелами. Все! Повністю до змінних середовища. Ваша машина збирання повинна мати змогу запустити збірку будь-якого з ваших проектів, виконавши єдиний скрипт у корені проекту. ( ./buildце розумний стандарт; ./configure; makeмайже настільки ж хороший.) Сценарій повинен створити середовище, як потрібно, а потім запустити будь-який інструмент, який створює продукт (make, ant, тощо).
Якщо ви думаєте, що це занадто багато роботи, це не так. Це фактично економить тонну роботи. Ви створюєте файли один раз на початку часу, а потім під час оновлення. Жоден самотній вовк не може модернізувати власну машину і здійснити купу вихідного коду, який залежить від останньої версії якогось інструменту, порушуючи збірку для всіх інших. Коли ви наймаєте нових розробників, ви можете сказати їм перевірити проект та запустити ./build. Коли версія 1.8 має багато настройки продуктивності, а ви підправити код, прапори компілятора, і змінні оточення, ви хочете , щоб переконатися , що нові прапори компілятора випадково не одержати застосовуються до версії 1.7 патча будує, тому що вони дійсно потребують код зміни, які відбуваються разом з ними, або ви бачите деякі волохаті умови перегонів.
Найкраще , що це врятує вашу дупу колись: уявіть, що ви доставляєте версію 3.0.2 свого продукту в понеділок. Ура, святкуй. У вівторок вранці VIP-клієнт зателефонував на гарячу лінію підтримки, поскаржившись на цей надкритичний, терміновий помилку у версії 2.2.6, який ви доставили 18 місяців тому. І вам все одно доведеться підтримувати це, і вони відмовляються від оновлення, поки ви точно не зможете підтвердити, що помилка зафіксована в новому коді, і вони досить великі, щоб змусити вас танцювати. Є два паралельних всесвіту:
У Всесвіті, де у вас немає бібліотеки, ланцюжка інструментів та сценаріїв побудови в керуванні джерелами, і у вас немає надійної системи CM .... Ви можете перевірити правильну версію коду, але це дає ви всілякі помилки при спробі створення. Подивимось, чи ми оновили інструменти в травні? Ні, це були бібліотеки. Гаразд, поверніться до старих бібліотек - зачекайте, були два оновлення? Ага так, це виглядає трохи краще. Але зараз ця дивна аварія лінкера виглядає знайомою. О, це тому, що старі бібліотеки не працювали з новою ланцюжком інструментів, тому нам довелося оновити, правда? (Я пошкодую вам агонію решти зусиль. Минуло два тижні, і ніхто не буде радий після цього, не ви, не керівництво, не замовник.)
У Всесвіті, де все знаходиться в контролі джерел, ви перевіряєте тег 2.2.6, готові налагодження налагодження через годину або близько того, проводите день чи два, відтворюючи "VIP-помилку", відслідковуйте причину, усуньте її поточний випуск та переконайте замовника оновити. Стресовий, але не настільки ж поганий, як в іншому всесвіті, де ваша волосся на 3 см вище.
З урахуванням сказаного, ви можете зайняти це занадто далеко:
- У вас повинна бути стандартна установка ОС, на якій у вас є "золота копія". Задокументуйте це, ймовірно, у системі README, яка знаходиться у контролі джерел, щоб майбутні покоління знали, що версії 2.2.6 та новіші лише побудовані на RHEL 5.3 та 2.3.0, а пізніше лише на Ubuntu 11.04. Якщо вам легше керувати ланцюжком інструментів таким чином, перейдіть до цього, просто переконайтеся, що це надійна система.
- Проектна документація громіздка для підтримки в системі управління джерелами. Документи проекту завжди випереджають сам код, і не рідкість працювати над документацією для наступної версії, працюючи над кодом для поточної версії. Особливо, якщо всі ваші документи проекту - це бінарні документи, які ви не можете розрізнити чи об'єднати.
- Якщо у вас є система, яка контролює версії всього, що використовується в збірці, використовуйте її ! Просто переконайтесь, що легко синхронізувати всю команду, щоб усі (включаючи машину збирання) тягнули з одного і того ж набору інструментів. (Я думаю про системи, такі як Debian pbuilder і відповідальне використання virtuolenv python.)