Как избежать разветвленных связей с крупными организациями?

10

Как избежать ситуации с филиалами при работе с крупными организациями?

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

Мои вопросы к сообществу:

Испытывали ли вы аналогичные подходы к принятию обновлений от ваших клиентов?
Какие предложения у вас есть, чтобы помочь работать с этим подходом?
Какие предложения у вас есть, чтобы помочь изменить подходы организаций к использованию обновлений программного обеспечения?

release process branch

— Марк Уилер
источник

Эй, Марк, похоже, у тебя интересная дилемма. Как вам удается разрабатывать эти обновления для каждого клиента? Вы разрабатываете их на разовой основе для каждого клиента, или это то, что вы разрабатываете и применяете ко всем клиентам?

— PrestonM

Лично я мог бы искать другую работу в этой ситуации. Это звучит как инцидент безопасности, ожидающий случиться ... Я могу сказать вам о поставщике устройств, на которого я работал, у них была серьезная ошибка, которая была исправлена в обновлении, к которому, по сообщениям, они не могли обратиться. Они хотели индивидуальное исправление. Мы отказались от их создания и сказали, что им нужно исправить свою бизнес-политику - мы не собирались выпускать специальное исправление для ошибки, которую мы уже исправили, просто чтобы они могли избежать внутриполитических проблем.

— Джеймс Шиви

Мы управляем специальными обновлениями для конкретного клиента через несколько ветвей кода и перекрестно фиксируем обновления безопасности для всех ветвей, а также взаимно исправляем код ветки обратно в транк. Часто клиент A не будет принимать обновления клиента B в своем филиале, он будет принимать только свои собственные обновления и исправления безопасности. Это обусловлено стремлением к стабильности в их ветке, поэтому им нужно только тестировать соответствующие обновления. Они получают обновления магистрали реже (то есть месяцы или годы), когда они готовы выполнить повторные тесты, которые могут занять месяцы. Автоматическое тестирование может быть ответом!

— Марк Уилер

3

Как упоминал Майкл, предложите стандартное решение, основанное на версиях / номерах выпусков, с разумно долгим сроком службы для вашей отрасли (возможно, с чередованием с одной или несколькими промежуточными версиями с более коротким сроком службы, если это имеет смысл для ваших типичных клиентов).

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

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

Выставление счетов за переменную поддержку, постепенно увеличивающееся с возрастом версий выпуска, из которых происходят пользовательские ветви, также может стимулировать клиентов к более быстрому переходу на новые ветви, помогая быстрее закрывать старые пользовательские ветви. Это может помочь уменьшить количество пользовательских веток на клиента - если у вас есть клиенты, которые одновременно запускают несколько версий вашего программного обеспечения.

Убедитесь, что вы не попадете в ловушку полного слияния веток из / в любую из веток релиза (как стандартных, так и пользовательских), все изменения в них должны быть либо индивидуально разработаны, либо исправлены слитными исправлениями.

Поскольку каждая из этих ветвей будет постепенно отличаться друг от друга, количество исправлений, требующих индивидуальной настройки / индивидуальной разработки, будет расти в геометрической прогрессии (обычное слияние вишенек не удастся). Вы должны принять во внимание стоимость разработки для них.

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

— Дэн Корнилеску
источник

Дэн - такой очевидный и простой, но в нем есть смысл. Деньги заставляют мир вращаться и, в свою очередь, должны помочь нам либо компенсировать нам стоимость долгоживущих филиалов, либо побудить клиентов обновиться и оставаться рядом с магистралью. Спасибо за хороший совет.

— Марк Уилер

1

Может быть, если вы будете поддерживать ветки по версиям, а не по клиентам, это поможет уменьшить их количество?

В противном случае единственный способ по-настоящему избавиться от него - это иметь возможность самостоятельно разместить программное обеспечение и переключиться на модель SaaS, где вы сможете поддерживать только одну его версию.

— Майкл Перейра
источник

К сожалению, наши клиенты часто работают в очень закрытых средах из-за финансовых данных, с которыми они работают, поэтому модель SaaS не будет приемлемой.

— Марк Уилер