Розгалуження порушує безперервну інтеграцію?

Я думаю, що ця стаття, «Успішна модель розгалуження Git» , дуже відома серед досвідчених користувачів DVCS.

Я використовую hgздебільшого, але я можу стверджувати, що це обговорення добре для будь-яких DVCS.

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

Таким чином, ми хочемо налаштувати такі сервери CI, як Jenkins, та покращити наш робочий процес із майбутніми системами забезпечення (шеф-кухар, маріонетка, відповідальний тощо).

Справжня частина

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

Скажімо, Аліса та Боб працюють над двома функціями. Але Аліса робиться на наступний день. Особливість Боба займає тиждень. На момент закінчення роботи Боб його зміни застаріли (можливо, Аліса переробила / перейменувала деякі класи).

Одне рішення - щоранку розробники повинні витягнути, master/originщоб перевірити, чи є якісь зміни. Якщо Аліса погодилася, Боб повинен витягнути і об'єднатися у свою робочу область, щоб його галузь функцій була актуальною.

1. Це хороший спосіб?
2. Чи повинні ці гілки існувати в master repo (чи не локальний клон?). Що означає, чи повинен кожен розробник взяти на себе привілей на головне репо на GitHub / Bitbucket, щоб вони могли створити нову гілку? Або це робиться на місцях?
3. Нарешті, модель, представлена ​​статтею, повинна порушити CI, якщо гілки не синхронізуються з origin/master. Оскільки ми хочемо робити нічні побудови, чи повинні розробники витягувати та об’єднуватись, перш ніж вони залишають роботу, і чи працює також ІС на кожній гілці функцій?

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

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

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

• Регулярно перетягуйте зміни, що вносяться до основної галузі розвитку, у функціональну галузь (наприклад, щодня)
• Коли функція виконана, об'єднайте головну гілку розвитку в гілку функції та натисніть на результат злиття на основну гілку розвитку.

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

У відповідь на 1)

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

2)

Переважно, гілки створюються в Mercurial шляхом клонування сховищ, тому не потрібно давати кожному розробнику привласнення привілеїв для майстра репо. Напевно, проте ви хочете надати розробникам можливість створювати клоновані репозиції на сервері безперервної інтеграції, оскільки це не завжди можливо запустити тести на місцевому рівні. (У мене колись була система CI, де на тестуванні блоків на 128-ядерному кластері працювало 8 годин) - Потрібно сказати, що розробники цього не робили, не могли запускати тести локально.

3)

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

Ось як це можна зробити: функції розгалуження.

1. Для будь-якого нового завдання (помилка, функція тощо) запустіть нову гілку (наприклад, bugfix-ticket123-the_thingie_breaks)
2. Під час роботи постійно оновлюйте та об’єднуйте за замовчуванням (або майстер у git) у свою галузь функцій . Це допоможе вам оновлювати свою філію без роботи в гілці за замовчуванням
3. Коли ваша функція готова і ваш тест одиниці пройде , потім витягніть і з’єднайте за замовчуванням ще раз, закрийте свою гілку і натисніть її без злиття , ваш інтегратор помітить нову голову і, що це закрита гілка, тож він / вона подбає про її інтеграцію. Якщо у вас немає інтегратора, переключіться на типовий і з’єднайте гілку функцій за замовчуванням .

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

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