Чи відмовляють DVCS від постійної інтеграції?

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

Якщо вони використовували централізований CVS на зразок SVN, кожного разу, коли один з них здійснює, сервер збірки інтегруватиме та перевірятиме їх зміни на предмет роботи дев'яти інших розробників. Сервер збирання буде працювати майже весь день.

Але якщо вони використовували DCVS на зразок git, розробник може почекати, поки вони виконають завдання, перш ніж підштовхнути всі свої локальні комітети разом до центрального сховища. Їх зміни не будуть інтегровані до кінця дня.

У цьому сценарії команда SVN постійно інтегрується частіше та виявляє проблеми інтеграції набагато швидше, ніж команда git.

Чи означає це, що DVCS менш придатні для постійних команд, ніж старі централізовані інструменти? Як ви, хлопці, обходите це питання відкладеного поштовху?

Відмова: Я працюю в Atlassian

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

Традиційно існує дві проблеми із DVCS та CI:

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

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

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

Як би там не було, якщо ви зацікавлені дізнатися більше, перегляньте мою публікацію в блозі "Здійснення ефективності галузей ефективності при постійній інтеграції"

Моя маленька команда перейшла на DVCS рік-два тому, а решта моєї компанії пішла за цим прикладом пару місяців тому. З мого досвіду:

• Люди, які використовують централізований VCS, як і раніше, як правило, тримаються на комісіях, коли вони роблять великий проект. Це не проблема, унікальна для DVCS. Вони матимуть набори змін, які чекають кілька днів, перш ніж здійснити вчинення. Велика різниця полягає в тому, що якщо вони помиляються в якийсь момент протягом цього часу або якщо комп'ютер виходить з ладу, для його виправлення потрібно значно більше зусиль.
• Ми використовуємо робочий процес фіксації, коли кожен розробник працює над власною названою гілкою, і лише особа, яка переглянула їх код, може об'єднати свої зміни в голову. Це зменшує ймовірність того, що вчинення може спричинити проблеми, тому люди дійсно звертають увагу, коли сервер збирання видає повідомлення про помилку. Це також означає, що інші розробники можуть продовжувати працювати над власними гілками, поки голова не зафіксується.
• На DVCS люди, як правило, витрачають більше часу на програмування, перш ніж об'єднати свій код із головою. Таким чином, це, як правило, незначне відставання у безперервності нарощування. Але різниця недостатньо значна, щоб протистояти перевагам DVCS.

Нещодавно я спостерігав за 19 проектами, які використовували Mercurial over SubVersion (я був підлітком підривника ): розробники почали ставати справді індивідуалістами, працюючи над власною філією та інтегруючись лише після сервальних днів чи тижнів. Це спричинило серйозні інтеграційні проблеми та проблеми.

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

Схоже, Мартін Фаулер написав про це на своєму сайті.

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

Розробник все ще несе відповідальність незалежно від VCS, який вони використовують.

Ідея, на якій ви базуєте свої міркування, дуже хитка, тихо кажучи. Розробник може чекати, поки вони не виконають завдання, це питання команди / управління / процесу .

Робити це так чи інакше, "чекати" або "поспішати", спільний стовбур або відокремлене відділення, відоме як стратегія розгалуження , і якщо ви вивчите інформацію, доступну в Інтернеті , ви дізнаєтесь, що вибір конкретної стратегії в основному не має нічого спільного VCS централізується або розподіляється.

Скажімо, для розподілених VCS, таких як Mercurial, ви можете легко знайти настійні рекомендації щодо частого злиття :

По-перше, часто зливайтеся! Це полегшує злиття для всіх, і ви дізнаєтесь про конфлікти (які часто кореняться у несумісних дизайнерських рішеннях) раніше ...

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

Тепер давайте розглянемо ситуацію на стороні централізованого VSC, Subversion. Вивчаючи інформацію в Інтернеті, можна знайти серед популярних стратегій, так звану стабільну магістраль та нестабільну магістраль - кожна має протилежний вплив на частоту злиття. Розумієте, люди обирають той чи інший спосіб робити, навіть не звертаючи уваги на централізацію VCS.

• ^{Я бачив сильно затримки злиття, що відбуваються (навіть заохочується кульгавим управлінням) з централізованим VCS, а також часті злиття, здійснені з DVCS, коли команда / управління просто думали, що це правильний шлях. Я бачив, що нікого не хвилює, чи розподіляється або централізується VCS, приймаючи рішення так чи інакше.}

З огляду на вище, схоже, що правильна відповідь на те, чи не підтримує DVCS безперервна інтеграція? було б Му .

Поширюваний або не VCS не робить суттєвого впливу на це.

Мій досвід - якраз навпаки , команди, які використовують svn, не натискатимуть цілими днями, оскільки код, над яким вони працювали, призведе до того, що магістраль не збирається для всіх інших, не витрачаючи часу на ручне злиття. Тоді, наприкінці спринту, усі зроблять, відбудеться злиття божевілля, речі переписуються і втрачаються, і їх потрібно відновити. Система CI перейде на ЧЕРВОНУ, і настане вказівка ​​пальцем.

Ніколи не було цієї проблеми з Git / Gitorious.

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

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

Наявність чогось подібного до Gitorious як посередника для перегляду коду за допомогою запитів на об'єднання робить управління багатьма філіями та багатьма учасниками дуже безболісним.

Налаштувати Дженкінса / Хадсона для відстеження всіх активних гілок у сховищі Git також дуже просто. Ми отримали більше тяги із CI та частіші відгуки про стан сховищ, коли ми перейшли до Git із SVN.

Побудувати сервери дешево. Просто ваш сервер CI підбере всі гілки, про які ви знаєте.

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

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

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

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

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

Однак, якщо хтось не може дочекатися, коли наші зміни приєднаються до головного, оскільки їх зміна залежить від нашої, він може об'єднати наш відділ розробників на місцевому рівні та продовжити свою роботу. Це те, що багато людей, які звикли до CVCS, пропускають. За допомогою CVCS єдиний спосіб поділитися своїми змінами - це об'єднання їх у центральний репо, і саме тому об'єднання часто є більш критичним. У DVCS у вас є інші варіанти.

Я б сказав, що DVCS сприяє постійній інтеграції. Злиття не так дратує їх. Однак це вимагає більшої дисципліни. Вам слід дотримуватися локальної фіксації, потягнувшись від основи, щоб злитися, а потім натиснути, коли ваше завдання завершено (перед тим, як перейти до наступного).

Коли моя команда перейшла на Git, ми явно виклали наш процес таким чином, що натискання слід було трактувати точно так само, як виконувати старі VCS, а місцеві комітети можна робити так часто / нечасто, як обирала кожна людина. З цим немає ніякої різниці для системи ІС, використовуємо ми DVCS або централізований VCS.

Відповідь і так, і ні.

Різниця тут полягає в тому, щоб здійснити пряму передачу в центральний репортаж, який переглядає CI, і переміщенням змін у центральне репо, яке переглядає CI. "Проблема", яку ви можете виявити, полягає в тому, що користувачі DVCS можуть насправді не виконувати цей натиск регулярно.

Я б сказав, що це невід'ємна особливість дизайну DVCS, він не розроблений для того, щоб постійно переносити зміни на центральний сервер - якби вони були, ви могли б замість цього використовувати CVCS. Тому відповідь полягає в тому, щоб забезпечити кращий робочий процес серед ваших розробників. Скажіть їм, щоб вони штовхали зміни. Симплекс!

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

Git не перешкоджає постійній інтеграції. Ваш робочий процес на основі магістралі є.

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

Я стверджую, що робочий процес на базі магістральної системи Google є контрпродуктивним для VCS, такого як Git, де об’єднання легко. Ось що я б порадив замість цього:

• Особливості перерви вниз досить малі, щоб на розробку жодного не пішло більше дня або двох.
• Кожна функція розробляється на приватній гілці.
• Розробник часто інтегрується в приватне відділення ( git fetch origin; git merge master). Я зазвичай роблю це багато разів на день, коли працюю таким чином.
• Коли розробник подає відділення для злиття та перегляду, сервер CI робить автоматизовану збірку. Злиття відбувається лише тоді, коли це пройде.

Отже, у вас це є: невеликі коміти, часта інтеграція та простежена історія того, які коміти належали до якої функції. Гілки, використовувані правильно, є ключем до всього, що варто про Git, тому уникати їх - велика помилка.

Існують дивовижні технічні рішення на зразок згадуваного @jdunay, але для нас це питання людей - таким же чином, як створення умов, коли люди зобов'язуються часто звертатися до svn, - це питання людей.

Що для нас працює: (замініть "master" на поточну діючу гілку розробників)

1. Часті злиття / знижки від головного
2. Досить часто натискання оволодіти

3. Усвідомлення речей, які спричиняють пекло злиття, як-от певні рефактори, і пом’якшення цього шляхом спілкування. Наприклад:

   • Переконайтеся, що всі підштовхуються до обіду
   • Під час обіду виконайте та натискайте на рефакторинг
   • Переконайтесь, що всі тягнуть після обіду