Який реалістичний спосіб попрацювати з програмними виправленнями, пов'язаними з клієнтом?

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

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

Наша стратегія розгалуження подібна до такої (заснована на Посібнику з розгалуження Visual Studio TFS , хоча для цього ми використовуємо Subversion)

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

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

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

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

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

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

Довга коротка історія. Довгостроково це виправити технічно, Короткострокова справа з цим.

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

Ми також використовуємо підрив - і трапляємося саме в такому сценарії.

Ось кілька ключових моментів, які слід пам’ятати:

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

2. Окремі клієнтські відділення повинні походити з нового випуску. Припустимо, у вас є версія 1.2 і ніж ви отримали версію 1.2.1 до 1.2.11 - відділенням клієнтів слід дозволити всі виправлення, отже, відділення клієнта має залишатися сумісним щодо основної версії.

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

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

Я спробував об'єднати цю ідею, щоб показати :

Як щодо впровадження механізму розширення у свій код?

Ваш основний код:

class Foo
{
}

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

class FooForABC : Foo
{
}

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