Методології розробки, коли сотня розробників працює над одним єдиним рішенням?

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

Завдяки величезній кількості розробників, ми намагаємось створити "крос-функціональні" команди з приблизно 10 розробниками в кожній команді, в результаті чого в організації налічується близько 20 команд розвитку.

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

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

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

Інший кінець спектру може бути таким (ми думаємо, що це робить Лінус Торвальдс / Linux) дерево або структура піраміди, де "основний сховище" має лише три джерела витягування, у цих трьох є лише кілька надійних джерел витягу тощо. Однак ми вважаємо, що при такій структурі зміни мають довгий ланцюг, щоб піднятися, щоб потрапити в "основне сховище". Плюс у тому, що якщо виникає конфлікт злиття, проблема потрапляє на іншого розробника, ніж "оригінальний розробник".

З огляду на всю цю довідкову інформацію та думки, як ми можемо вивчити та читати рекомендовані методики розробки для багатьох розробників? Як великі організації (Microsoft, Facebook, Ubuntu тощо) структурують свій розвиток?

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

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

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

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

Можливо, варто розглянути процес Agile розробки, подібний Scrum , мета якого - розбити складний продукт на керовані фрагменти приросту продукту (звані спринти). Це забезпечило б можливості інтеграції між сховищами.

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

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

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

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

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

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

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

Є кілька кроків, які допоможуть вам краще підтримувати команду та проект:

1. розділити функціональність на модулі. Функціонал слід розділити на незалежні максимальні модулі, використовуючи принципи високої згуртованості, низької зв'язку та інверсії залежності. Перший принцип допоможе вам створити логічно послідовні модулі. Другий допоможе зберегти ці модулі максимально незалежними. Третій допоможе одночасно розробити залежні модулі (якщо модуль A залежить від модуля B, B повинен забезпечити інтерфейс, який A може використовувати навіть тоді, коли B не повністю готовий).

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

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

4. чітка система завдань. Кожен із 200 розробників повинен чітко знати, над чим працювати. Це допоможе вам відстежувати, що вже зроблено, над чим працює кожна людина та скільки роботи залишилось.

5. контроль джерела. (Думаю, це досить добре окреслено в інших відповідях)))

І нарешті, спробуйте створити максимально просту структуру команд та модулів. Ви не можете дозволити собі складність такого величезного проекту.

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

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

У цьому сценарії існує безліч різних гілок повної бази кодів, які регулярно оновлюються зі своєї вихідної гілки, але відповідальність за просування коду у більш видимі / публічні зони покладається на одну людину (або невелику групу людей), і, як правило, прив’язаний до процесу перегляду коду. З добре організованою структурою розгалуження це може спрацювати РЕАЛЬНО добре. Для отримання додаткової інформації перегляньте це посилання .

Я працював над величезною системою, яка мала кілька сотень розробників, які працювали над нею одночасно з близько 150 мільйонами SLOC. Це було на мейнфреймі, тому ми не говоримо про Visual Studio, але принципи все одно можуть бути прийняті.

Перш за все, якщо ви використовуєте Java, я б точно сказав, що використовуйте Maven. Якщо ви використовуєте VS, ви також можете використовувати Nuget, хоча я не зовсім впевнений, чи є він там з Maven ще (він також дещо інший). Використання такої системи дозволить витягнути свої залежності та дозволить їм функціонувати індивідуально. У вас буде сценарій збірки, щоб витягнути відповідні залежності і побудувати як пакет.

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

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

Наприклад, як простір імен, ви б мали організувати Organisation.Security.DirectoryServices. Вмістивши всю логіку у відповідних сферах, команди працювали досить автономно. Очевидно, що великі проекти, що вимагають участі декількох команд, траплялися, але вони в основному були плавними.

Я сподіваюся, що це допомагає.