Як я можу правильно керувати комітетами, запобігати конфліктам між функціями та керувати залежностями за допомогою VCS?

Це стало дратівливим фактором роботи з великими командами: як ти керуєш чеками та запобігаєш конфліктам між функціями та керуєш залежностями з контролем джерел належним чином?

Наразі на моєму робочому місці ми використовуємо TFS 2008 і переходимо до TFS 2010 на початку грудня. По-перше, будь-яке управління джерелами краще, ніж жодне, але який підхід хтось вважає корисним для запобігання декількох реєстрацій та відкатів у всій історії управління джерелами? Чи є летючий магістраль найкращим способом перейти або відключитися під час впровадження нової функції, і як тільки ви будете щасливі, об'єднайтеся назад у багажник?

Я дуже хотів би почути досвід інших людей та, можливо, найкращі практики управління джерелами.

TFS? Бігайте за пагорби! Рухайтеся якомога швидше. Він робить багато різних речей, але жодна з них не є такою доброю, як найкращі інструменти породи.

Але серйозно:

Після того, як у вас є пристойна система управління версіями (SVN, GIT тощо), я рекомендую встановити правила для управління філіями, наприклад, коли створювати гілки, для чого, коли об’єднувати, хто та багато іншого.

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

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

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

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

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

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

Я виступаю за одну гілку за функцією, оскільки це дозволяє велику гнучкість у вирішенні, які функції надсилати, а які відкладати.

Наскільки добре це працює у вашій ситуації, залежить від того, наскільки добре ваш VCS обробляє гілки та ще важливіше злиття. DVCS на зразок Git & Mercurial роблять це відносно тривіальною вправою. SVN менше. Мені вдалося уникнути TFS, хоча я багато читав про це, боюсь, головним чином, некомплектно. Якщо ви застрягли з TFS, зробіть невеликий пілотний реліз на основі однієї функції на галузь, і подивіться, наскільки добре злиття йде для вас.

По-перше, відмова від відповідальності. Важко сказати, який найкращий спосіб управління джерелом, оскільки ми не усвідомлюємо, як працює ваша команда чи команди щодня.

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

Об'єднання нового коду регулярно мінімізує біль від злиття великих фрагментів коду у фазі масової інтеграції. Поширюючи біль, ви відчуєте її менше. Чим частіше члени вашої команди вводять код, тим менше їм доведеться зливатися - адже вони завжди будуть в останньому джерелі.

Я ніколи не використовував TFS 2008/2010, але з того, що я читав на різних форумах, є багато негативу щодо використання TFS для контролю версій. Це змусило мене поки що залишатися ясним від TFS.

Зараз я використовую SVN та Git, я вважаю їх хорошими для невеликих команд або одиноких команд, але особисто не рекомендую SVN для великої команди.

У мене були очі на PlasticSCM, і я спробую це зробити найближчим часом.

Прошу вибачення за те, що не відповів на ваше конкретне запитання, я б опублікував коментар, якщо мої привілеї дозволили мені.

Я думаю, що git робить усі інші програмні засоби управління джерелами застарілими. Розгалуження та злиття легко, і якщо є проблеми, вони містяться, але багато проблем можна уникнути тим, як це заохочує дуже часті вчинення, розгалуження та злиття. Кожен користувач отримує повну копію репо (це можна виправити, але я працюю з досить величезною базою кодів, і це не проблема), тому є щось із автоматичного резервного копіювання. Коміти / push / pull є швидкими, і однією з найважливіших речей є те, що він порушує зв'язок між назвою файлу та відстеженням. Дані файлу, включаючи ім'я та шлях, - це блок даних, на який посилається вузол дерева, незалежний від шляхів. Це не тільки безпечніше, але певні типи "ніколи не роби цього" проблем у чомусь на зразок SVN не є проблемою. Він може використовуватися як традиційна конфігурація концентратора або одноранговий, і ці можливості можна вільно змішувати в одній програмі. Це криптографічно захищено від незадокументованих вставок. І це дуже швидко.

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

Недолік - це трохи крута крива навчання, оскільки вона тонко порушує всі правила, до яких люди звикли керувати джерелами, але це коротка крута крива навчання.

Деякі з добрих практик, яких ми справді дотримуємось, і нам дуже допомогли:

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

2) Маркуйте свої файли періодично, після будь-яких невеликих важливих етапів.

3) Дайте хороші заїзди або каси. Це допоможе при перегляді, іноді не потрібно відкривати та порівнювати між версіями.

як ви керуєте реєстраціями та запобігаєте конфліктам між функціями та правильно управляєте залежностями з керуванням джерелами?

Це, з мого POV, завдання з двома факторами: ви повинні виконати це з технічної (хорошої та легкої та бездоганної розгалуження | об'єднання | аудиту тощо) та управління (чітко встановлена ​​політика "що" "коли" коли "як"). Два або навіть три яруси коду розділення в ALM: щось на кшталт "стабільний" (пройшов тестування одиниці), "нестабільний" (кожна включена функція закінчена, але додаток як продукт має питання після інтеграції / так, це може статися /) і " в роботі". Таким чином належний менеджер проектів може зменшити спільну роботу окремих розробників.

TFS (який я не використовував, не використовую і не буду використовувати) має деякі, AFAIK, фундаментальні проблеми в аспекті управління контролем над джерелами. Я просто посилаюся тут на деякі тексти Джеймса Маккея:

• Team Foundation Server - це Lotus Notes інструментів контролю версій
• Безосновні злиття в сервері Team Foundation - чому?

Справді приємна та нещодавня стаття, яка чітко та стисло порівнює та протиставляє декілька різних способів роботи з керуванням джерелами, знаходиться тут: Управління джерелами зроблено правильно .

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

Щодо того, які інструменти ... Це майже не має значення. Що насправді важливо - це те, щоб усі у вашій команді були на одній сторінці, що стосується використання. Це означає, що всі повинні розуміти, як управляється рядок коду та що вони очікують робити. І в будь-якому випадку, на практиці у вас НЕ ВИБОРЬ, який інструмент використовувати. Зробіть найкраще з усього, що ви використовуєте.