Як уникнути розгалуження з великими організаціями?

10

Як уникнути розгалуженої ситуації під час роботи з великими організаціями?

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

Мої запитання до громади:

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

release process branch

— Марк Вілер
джерело

Гей, Марк, це здається, що ти маєш цікаву дилему. Як вам вдається розробити ці оновлення для кожного клієнта? Ви розробляєте їх одноразово для кожного клієнта, або це щось, що ви розробляєте та застосовуєте до всіх клієнтів?

— PrestonM

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

— Джеймс Швай

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

— Марк Вілер

3

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

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

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

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

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

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

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

— Ден Корнілеску
джерело

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

— Марк Вілер

1

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

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

— Майкл Перейра
джерело

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

— Марк Вілер