Чи існує інструмент ІС, який не гарантує регресу на рівні якості галузі?

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

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

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

Оновлення: припущення полягає в тому, що відповідні автоматизовані верифікації якості з відповідним покриттям для виявлення відповідних регресій доступні для виклику інструментами CI.

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

Atlassian має кілька цікавих застосувань гачків Git :

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

Якщо ви використовуєте Git, гачки є дуже потужними (і подібні гачки є для SVN , Mercurial та інших систем управління версіями), і вам може бути корисним використовувати їх для запуску перевірок попереднього вчинення.

Документація Git містить сторінку про створення гачка для відхилення натискань, якщо вони не відповідають певним критеріям, які легко можна адаптувати до цього випадку використання.

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

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

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

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

Як правило, не особливо складно (залежно від використовуваних інструментів) визначити, чи відповідає галузь джерела в PR-цілі цільовим, а також чи має збірну CI збірку. Ви можете використовувати це як вимогу (за політикою та / або нав'язаною програмою) для об'єднання запиту на витяг.

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

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

ApartCI - це система CI, розроблена саме для запобігання регресу, гарантуючи таким чином рівне або підвищення рівня якості філій. Ще в бета-версії.

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

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

Інструмент також розроблений для легкого масштабування - здатний підтримувати дуже високі темпи змін, що надходять, та підтримувати 100s / 1000s розробників, що працюють в одній галузі інтеграції.

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