Як ми уникаємо розвитку, орієнтованого на ІС…?

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

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

В даний час наш CI будує ядро ​​та підтримувані плагіни.

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

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

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

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

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

Розробка, орієнтована на CI, чудово! Це набагато краще, ніж не запускати тести і включати зламаний код! Однак є декілька речей, які полегшають це всім учасникам:

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

• Заохочуйте місцеве тестування: спростіть налаштування тестового середовища для вашої системи. Сценарій, який підтверджує, що всі залежності встановлені? Контейнер Docker, який готовий до роботи? Зображення віртуальної машини? Чи є у вашого тестового бігу механізми, які дозволяють визначити пріоритетніші важливі тести?

• Поясніть, як використовувати CI для себе: Частина розчарування полягає в тому, що цей відгук надходить лише після подання PR. Якщо дописувачі налаштують ІС для власних сховищ, вони отримають попередній зворотній зв'язок - і вироблять менше повідомлень про ІС для інших людей.

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

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

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

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

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

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

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

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

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

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

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

Вам також знадобиться явна версія API плагінів. Це дозволяє розробити v2, тоді як усі v1 плагіни продовжують створювати та працювати.

Я також хотів би поставити під сумнів трохи більше, чому так багато рефакторингу ядра та змін API вноситься. Вони справді потрібні чи просто люди нав'язують своєму особистому смаку проект?

Звучить, як процес ІС повинен бути більш чітким, всеосяжним та більш зрозумілим для учасників, перш ніж вони піднімають PR. Як приклад, у BitBucket є функція конвеєра, яка дозволяє це робити, коли ви надаєте йому файл, який визначає в коді процес збирання CI, і якщо він не вдається, гілка не може бути об'єднана.

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

Проблеми з дизайном було б добре виправити, але вони є ортогональними для цієї проблеми.

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

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

Ваше рішення просте: знизити бар'єр для внеску .

Найпростіший спосіб (1) прискорити цикл редагування-збирання-тестування та (2) плавні відмінності середовища - це надання серверів побудови :

• Підберіть приємні машини: 24, 48 або 96 ядер, 2 Гб оперативної пам’яті / ядро, SSD, щоб прискорити компіляцію.
• Переконайтесь, що вони мають належне обладнання: FPGA, графічну карту, все необхідне.
• Створіть зображення Docker із усіма попередньо встановленими необхідними бібліотеками програмного забезпечення.

А потім відкрийте ці сервери побудови для учасників. Вони повинні мати можливість віддаленого входу в свіже зображення Docker і віддалено редагувати-збирати-тестувати на цій машині.

Тоді:

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

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

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

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

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

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

Ніхто інший, схоже, не підняв це як потенційне рішення.

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

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

Це не забезпечить сумісність на 100%, але це спричинить набагато більше питань і на початку.

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

У мене виникають проблеми з розумінням ситуації, як здається: КІ будує лише одну гілку?

Чи є причина, що ви не можете створити більше одного відділення з ІП?

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

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