Пропозиція моделі розгалуження для декількох клієнтів одного проекту

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

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

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

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

• Різні основні етапи для кожного клієнта: Це означає, що кожна команда повинна виробляти версії як різні часи, без решти зобов'язань, що впливають на стабільність або їхній продукт.
• Різні вимоги, які можуть або не впливають на ядро ​​системи в деяких випадках.
• Великі команди (20+ членів команди)
• Поводження з помилками в системі: Що робити, якщо команда знайде помилку в своєму проекті, яка може вплинути на інших клієнтів?

Примітка. Ми говоримо про проект, який має 10 + M LOC.

Примітка. Ми використовуємо Team Foundation System, Visual Studio 2008 та C # (в основному).

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

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

Назва такого підходу - це програмні лінії або інколи інженерія продуктових ліній . Від сторінки цей програмний продукт Лінії ЇХ ОЙ :

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

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

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

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

Деякі додаткові корисні посилання:

• Вікіпедія: Інженерія продуктів
• Тематичні дослідження КМУ SEI
• Рядки програмного продукту - сайт з великою кількістю вступного матеріалу.

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

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

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

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

Наприклад

• для випуску 1.0 потрібна бібліотека A 1.0, бібліотека B 2.0, бібліотека C 5.6
• для випуску 2.0 потрібна бібліотека A 1.0, бібліотека B 3.7, бібліотека C 5.7
• для випуску 3.0 потрібна бібліотека A 1.2, бібліотека B 3.7, бібліотека C 5.8

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

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

Рішенням для вашої основної системи може бути трактування як бібліотеки, для якої ви підтримуєте різні версії. Що по суті означає, що вам потрібно встановити різні гілки для кожної версії. Потім клієнтська програма може використовувати належну "версію" вашої основної системи, посилаючись на відповідну папку гілки основної системи.

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

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