Автоматичне повернення комітетів, які не виконують збірку

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

Це найкраща практика чи це може бути більш проблематично, ніж просто залишити masterзламаним, поки розробник не виправить це?

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

редагувати: Не має значення, чи це masterбудь-яка інша галузь розвитку, але питання залишається таким же: чи система CI скасувати комісію, яка не вдалася зібрати?

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

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

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

Я був би проти цього робити з наступних причин:

• Щоразу, коли ви налаштовуєте автоматизований інструмент для зміни коду від свого імені , є ризик, що він помилиться або виникне ситуація, коли вам це потрібно, щоб припинити вносити ці зміни (наприклад, остання версія Google Mock помилка в ньому, тож ваш код не піддається), і вам доведеться витрачати час на його перенастроювання. Крім того, завжди є невеликий ризик, що збірка вийде з ладу через помилку в системі збірки, а не помилку у вашому коді. Для мене КІ - це здобуття впевненості, що мій код правильний; це просто перетворить це на ще одне джерело потенційних проблем, про які я повинен хвилюватися.

• Види помилок, які порушують "складання", повинні бути дурними помилками, які потребують виправлення дуже мало часу (як ви вказали в коментарі, це справедливо для вас). Якщо більш тонкі та складні помилки регулярно роблять це на майстер, то правильним рішенням є не «виправити це швидше», це бути обережнішим при перегляді гілок функцій, перш ніж вони об’єднаються.

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

Давайте спочатку домовимось про умови.

Я особисто використовую терміни Неперервна збірка та Постійна інтеграція, щоб виділити два різні сценарії:

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

Останнє, Безперервна інтеграція, означає, що сховище, яке він захищає, завжди зелене ¹ : це суворо краще.

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

¹ : Причини навколишнього середовища також можуть зіпсувати збір, наприклад, тест із жорстким кодом року (2015) може почати виходити з ладу січень 2016 року, диск може заповнитися, і, звичайно, є чума нестабільної тести. Я тут сміливо ігнорую ці питання; інакше ми нікуди не потрапимо.

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

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

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

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

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

Спробувавши обидва, це суворо краще.

Це найкраща практика чи це може бути більш проблематично, ніж просто залишити майстра зламаним, поки розробник не виправить це?

Це проблематично. Людина, яка вирішила, що "головна голова зламана; я поверну верхні зміни" зовсім інша, ніж система CI, яка робить те саме.

Ось кілька недоліків:

• Помилки в процесі автоматичного повернення призведуть до викручування сховища;

• це передбачає, що один набір змін (верхній) накрутив збірку (що нереально)

• Обслуговувачам доведеться зробити більше роботи над вирішенням проблеми, ніж просто розслідування та вчинення (їм також доведеться переглянути зворотну історію)

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

Це переконання (гілки проти КІ) неправильне. Подумайте про збереження однієї стабільної гілки, де ви здійснюєте лише тестовані набори змін. Решта (включаючи гілки та місцеві відділення) несе відповідальність кожного розробника, а не є частиною вашої політики CI.

У функціональних галузях ви хочете бути ізольованими від інших розробників. Це дозволяє:

• виконувати дослідницьке кодування

• експериментуйте з базою коду

• виконувати часткові комісії (ефективно виконувати непрацюючий код), щоб встановити точки резервного копіювання (у випадку, якщо ви закінчитесь), створити більш значущу історію змін (через повідомлення про фіксацію), а також створити резервну копію вашої роботи та повністю перейти на щось інше (в час, який вам знадобиться для написання "git commit && git checkout")

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

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

Це не повинно. Здійснення стабільного коду у вашій гілці CI - це відповідальність виконавця, а не автоматизована система.

Я б запропонував використовувати середовище Gerrit + Jenkins, щоб завжди підтримувати хорошу форму вашого майстра. Люди підштовхують свій новий код до Герріта, що запускає роботу Дженкінса, щоб витягнути цей патч, складати, перевірити тощо. Якщо інші розробники, такі як ваш патч та Дженкінс, успішно виконали свою роботу, то Герріт з’єднає цей фрагмент коду з вашим головним відділенням.

Подібне середовище описане @ brian-vandenberg

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

[1] Дженкінс https://jenkins-ci.org/

[2] Герріт https://www.gerritcodereview.com/

ІП ніколи не повинен змінювати історію подій репо.

Правильне рішення тут полягає в тому, що жодних зобов’язань не додавати в головну гілку, якщо вони не були перевірені та не перевірені.

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

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

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

Коміти висуваються опосередковано через завиток до Дженкінса, де він клонує головний репо, після чого тягне за собою коміти (и), які повинні бути об'єднані, і виконує всі необхідні збірки (для Linux / solaris). Якщо всі збірки завершені, комісія стає натиснутою.

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

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

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

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

Якщо система точно не знає, я, звичайно, не хочу її автоматизувати.

Поставлене запитання є хибним. Я поважаю це твердження, хоча

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

Що ви повинні зробити, хоча це ці кроки

• працюйте майстром, якщо вам подобається (це добре, і продовжуйте тягнути зміни від усіх), Але НЕ НЕ зобов'язуйтесь освоювати локально
• ПІД ЧАС перед тим, як ви збираєтеся здійснити свої зміни в master, створіть гілку з submit_XXXXXX
• попросіть автоматизовану збірку забрати всі відділення submit_XXX
• Варіант 1: побудувати перерви або перерви об'єднання ... зміна відхилена, і вона ніколи не приземляється на головний
• Варіант 2: будує роботи, джинкіни підштовхує майстра та оновлює його

ТОГО, що ми робимо, це покласти гачок на вчинення git, щоб запобігти ВСЕГО дійсно взяти на себе зобов’язання освоїти. Це чудово працює .... НЕ порушених побудов ніколи, і НЕ повертає жодних зобов'язань від майстра.

пізніше, Дін