Як слід зберігати код у контролі версій?
Дружній для розробників ? так що програміст може швидко взяти останню версію та змогти запустити від свого редактора, не зробивши багато змін? (наприклад, конфігураційні файли, що вказують на DB DB іetc)
або
Чи повинно бути виробництво дружнє ? джерело має бути таким, який легко розгорнути у виробничому середовищі, і коли розробник приймає останнє, він повинен виконувати зміни відповідно до своїх потреб у розробці.
Відповіді:
Чому вибирати? Це повинно бути і те, і інше.
У вашому середовищі розробки має бути налаштовано так просто, як робити замовлення, відкривати, будувати, запускати, налагоджувати (наприклад: немає абсолютного шляху!). Це можна легко зробити, використовуючи директиви компіляції, клас конфігурації + введення залежності, або навіть хитрощі, як perso.config в ASP.NET
Ваш автоматизований сценарій збірки повинен бути налаштований так, щоб він відповідав конкретній конфігурації виробництва, очищенню, упаковці тощо.
Коли це проект з відкритим кодом, де люди, як очікується, можуть зробити свій внесок, я б неодмінно вибрав розробник.
Моя найбільша неприязнь до проектів з відкритим кодом полягає в тому, що дуже рідко репозиторій містить усі залежності, необхідні для побудови коду (іноді з практичних чи юридичних причин), але коли вони цього не роблять - деякі навіть не намагаються розповісти, які залежності вам потрібно або, що ще важливіше, яка їх версія вам потрібна. (а краще, звідки їх взяти)
Іноді ви можете витратити більше пів дня на отримання та складання кількох інших проектів, щоб створити проект, який ви шукаєте.
Звичайно, це дійсно актуально лише для розробки в Windows.
І те й інше, але це залежить від того, наскільки часто ви робите своє виробництво. Для багатьох налаштованих програм розгортання здійснюються вручну та локально. З іншого боку, розробник буде постійно вводити код, незалежно від того, наскільки проект малий чи великий. На мою думку, я вважаю, що важливіше переконатися, що розробник може правильно керувати версіями, а отже, полегшити їхнє життя, щоб вони встигли зосередитись на коді, а не знаходити шлях через контроль версій.
Це повинно бути зручним для виробництва, інакше підтримувати автоматизовані конструкції проблематично.
Я все для зниження тертя, щоб легше було виконати роботу, але також потрібно враховувати режими відмов.
Якщо версія вихідного репозиторію завжди налаштована для використання у виробництві, то який результат розробник не зможе переконфігурувати перед запуском системи? Код розробника, який працює проти виробництва.
Незалежно від того, чи існують інші перешкоди на шляху розробника вносити випадкові зміни у виробництво, будівництво в режимі відмови, що спонукає його до цього, здається небезпечним.
Я вважаю, що значення за замовчуванням, включені у вчинений код, завжди повинні бути безпечними . Перевірте файли конфігурації виробництва і в керуванні джерелами, якщо вам подобається - я майже завжди це роблю, - але зберігайте їх десь "не жити".
Я прагну до виробництва, сприятливого для виробництва. Він підтримує чистоту вашої конструкції та запобігає перетворенню сторонніх параметрів у виробництво.
Безумовно, дружній для розробників, зі сценаріями для автоматизації змін для забезпечення якості та виробництва.
Чому б не мати відділення (залежно від того, який контроль над версіями ви використовуєте - я використовую Git) для розгорнутого коду та іншого для готової для розробника версії? Це звучить набагато краще, і це не так важко налаштувати.
Ви можете працювати та вносити зміни, а потім об'єднувати їх у розгорнутій версії.