Поддерживать сотни настраиваемых ветвей над главной ветвью

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

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

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

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

135 голосов | спросил Fernando Tan 9 12015vEurope/Moscow11bEurope/MoscowMon, 09 Nov 2015 19:00:34 +0300 2015, 19:00:34

9 ответов


303

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

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

Основная инфраструктура и любые общие функции затем должны быть сохранены, сохранены и протестированы один раз .

Вы должны были сделать это с самого начала. Если у вас уже есть пять сотен вариантов продукта (!), Исправление этого задания будет огромным , но не более того, чем текущее обслуживание.

ответил Lightness Races in Orbit 9 12015vEurope/Moscow11bEurope/MoscowMon, 09 Nov 2015 19:03:13 +0300 2015, 19:03:13
91

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

Во-первых, я надеюсь, что вы зарядите своих клиентов достаточно, чтобы покрыть ВСЕ расходы на поддержку своих пользовательских версий. Я предполагаю, что клиенты ожидают получить новые версии, не заплатив за свои настройки, которые будут сделаны снова. Я бы начал с поиска всех файлов, которые одинаковы в 95% ваших филиалов. Это 95% является стабильной частью вашего приложения.

Затем найдите все файлы, у которых есть только несколько строк, отличных между ветвями, - попробуйте ввести конфигурационную систему, чтобы эти различия можно было удалить. Так, например, вместо того, чтобы иметь 100 файлов с текстовыми полями, которые отличаются друг от друга, у вас есть 1 файл конфигурации, который может переопределять любую текстовую метку. (Этого не нужно делать за один раз, просто создайте метку текстового поля, которую можно настроить при первом изменении клиентом клиента.)

Затем переходите к более сложным вопросам, используя шаблон стратегии, инъекцию зависимостей и т. д.

Рассмотрим сохранение json в базе данных, а не добавление столбцов для собственных полей клиента. Это может сработать для вас, если вам не нужно искать эти поля в SQL.

Каждый раз, когда вы проверяете файл в ветке, вы ДОЛЖНЫ разделить его на main и оправдывать каждое изменение, включая пробел. Много изменений не потребуется и может быть удалено до проверки. Это может быть просто для одного разработчика, имеющего разные настройки в своем редакторе, как форматировать код.

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

У вас может быть 500 филиалов за много лет, но если им намного легче управлять, тогда вы выиграли.


Основываясь на комментарии от br3w5:

  • Вы можете выбрать каждый класс, который отличается от клиента.
  • Сделайте «xxx_baseclass», который определяет все методы, вызываемые в классе извне.
  • Переименуйте класс, чтобы xxx назывался xxx_clientName (в качестве подкласса xxx_baseclass)
  • Используйте инъекцию зависимостей, чтобы для каждого клиента использовалась правильная версия класса
  • И теперь для умных прозрений, которые возникли у br3w5! Используйте инструмент анализа статического кода, чтобы найти дублированный код и переместите его в базовый класс и т. Д.

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

ответил Ian 9 12015vEurope/Moscow11bEurope/MoscowMon, 09 Nov 2015 21:56:37 +0300 2015, 21:56:37
40

В будущем спросите тестовые вопросы Joel в своем интервью. Вы, скорее всего, не будете ходить в поход.


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

Насколько интегрированы с «ядром» эти пользовательские изменения? Можете ли вы сделать им свою собственную библиотеку и иметь одно «ядро», а каждый конкретный клиент имеет свой собственный «дополнительный»?

Или это все очень незначительные конфигурации?

Я думаю, что решение представляет собой комбинацию:

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

Ничто не будет тривиально, как если бы вы оказались здесь с 500 + клиентами, вы, вероятно, не делали реального различия в этом. Я ожидаю, что ваши изменения в разделении этой задачи будут очень трудоемкими.

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

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

ответил Elysian Fields 9 12015vEurope/Moscow11bEurope/MoscowMon, 09 Nov 2015 19:13:35 +0300 2015, 19:13:35
17

Это один из худших анти-шаблонов, которые вы можете поразить любым VCS.

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

Это позволяет сохранить одну ведущую ветвь с вашим производственным кодом.

ответил Daenyth 9 12015vEurope/Moscow11bEurope/MoscowMon, 09 Nov 2015 19:03:42 +0300 2015, 19:03:42
13

Цель филиалов - изучить один из возможных путей развития, не рискуя нарушить стабильность основной отрасли. В конечном итоге они должны быть объединены в подходящее время или отброшены, если они приведут к тупиковой ситуации. У вас есть не столько ветки, сколько более 500 forks одного и того же проекта, и попытка применить жизненно важные их изменения для всех из них - задача sisyphean.

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

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

ответил back2dos 9 12015vEurope/Moscow11bEurope/MoscowMon, 09 Nov 2015 20:08:45 +0300 2015, 20:08:45
7

Все важные вещи были предложены хорошими ответами здесь. Я хотел бы добавить пять пенсов в качестве предложения процесса.

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

Это означает:

  1. Уточнить обязанности по управлению изменениями: если клиенту нужны некоторые адаптации, кто продает их, кто позволяет им и кто решает, как код будет изменен? Где поворачивать винты, если какие-то вещи должны быть изменены?
  2. Уточнить роль, Кому в вашей команде разрешено создавать новые репозитории, а кто не работает.
  3. Постарайтесь убедиться, что все в вашей команде видят необходимость шаблонов, которые обеспечивают гибкость программного обеспечения.
  4. Уточнить инструмент управления: как вы быстро знаете, что у клиента есть, какие усыновления кода. Я знаю, какой-то «список из 500» звучит раздражающе, но вот какая-то «эмоциональная экономика», если хотите. Если вы не можете быстро сообщить об изменениях клиента, вы чувствуете себя еще более потерянными и нарисованными, как будто вам нужно начинать список. Затем используйте этот список, чтобы сгруппировать функции, как показали вам другие люди:
    • клиентов группы по незначительным /крупным изменениям.
    • по связанным с объектами изменениям
    • группа с изменениями легко объединяется, и изменения трудно слить
    • найдите группы равных изменений, внесенных в несколько репозиториев (о да, будут некоторые).
    • возможно, самое важное для того, чтобы поговорить с менеджером /инвестором: группа с помощью дорогих изменений и дешевых изменений.

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

Затем попробуйте установить окно с длительным сроком, в котором вы готовите эту вещь на маленьком пламени. Предложение: попытайтесь объединить по крайней мере два репозитория каждую неделю, и поэтому удалите хотя бы один . Вы можете узнать, что часто вы можете объединить более двух филиалов, поскольку вы получаете рутину и контроль. Таким образом, через год вы можете справиться с самыми худшими (самыми дорогими?) Филиалами, и через два года вы можете уменьшить эту проблему, чтобы иметь явно лучшее программное обеспечение. Но не ожидайте большего, так как в конце никто не «успеет» для этого, но вы тот, кто больше не позволит этого, так как вы являетесь архитектором программного обеспечения.

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

ответил peter_the_oak 10 22015vEurope/Moscow11bEurope/MoscowTue, 10 Nov 2015 09:11:36 +0300 2015, 09:11:36
5

Контрастируя всех nay-sayers, давайте предположим настоящую потребность в бизнесе.

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

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

Мой (и nay-sayers) вопрос, есть ли у вас выделенный человек , ответственный за доставку каждому клиенту? Если вы, скажем, компания в 10 000 человек, это может быть так.

В некоторых случаях это может быть обработано архитектурой плагинов , скажем, ваше ядро ​​- это соединительная линия, плагины могут храниться в соединительных линиях или ветвях, а конфигурация для каждого клиента либо является уникальным файлом, либо является проведенных в отделении клиентов.

Плагины могут быть загружены во время выполнения или встроены во время компиляции.

Поистине, многие проекты выполняются, как это, принципиально такая же проблема по-прежнему применяется - простые изменения ядра тривиальны для интеграции, изменения конфликта должны быть либо откатными, либо изменениями необходимы для многих плагинов.

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

В идеале это будет обрабатываться аспектно-ориентированным программированием , где trunk - это основной код, а ветви - это аспекты (это дополнительный код и инструкции по подключению дополнительных компонентов к ядру)

Простой пример: вы можете указать, что пользовательский foo запускается до или после core klass.foo или заменяет его или обертывает его и может изменять ввод или вывода.

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

Наконец, такой бизнес действительно должен заботиться о обслуживании филиалов , а именно, о характеристике, характерной для клиента X, настолько распространенной, что дешевле перенести ее в ядро, хотя не все клиенты платят за нее

ответил Dima Tisnek 10 22015vEurope/Moscow11bEurope/MoscowTue, 10 Nov 2015 18:50:03 +0300 2015, 18:50:03
3

Вы не решаете первопричину болезни, глядя на симптом. Использование подхода «управление кодами» является симптоматичным, но не решит проблемы для вас в долгосрочной перспективе. Основной причиной является отсутствие «хорошо управляемых» продуктов, возможностей и возможностей; их расширениях и вариациях.

Ваш «пользовательский» код не представляет ничего, кроме расширений функций продукта и amp; возможности и в других.

Насколько обширны пользовательские функции, насколько они различны, насколько они похожи друг на друга или похожи друг на друга, будут сильно «дезактивировать» базу кода вашего продукта.

Больше, чем код и версия, это место, в которое входит управление продуктом, архитектура продукта и архитектура данных . Серьезно.

Потому что, в конце концов, код - это не что иное, как ваше предложение бизнес-функций и функций /услуг для ваших клиентов. Это то, за что платит ваша компания.

Получение лучшей справки по этому вопросу должно осуществляться с точки зрения «возможностей», а не с точки зрения кода.

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

И если вы предлагаете несколько вещей, было бы разумно модулизовать ваши возможности продукта организованным образом.

Насколько широки и глубоки будут ваши продукты? Или иначе это приведет к проблемам «качества обслуживания» и amp; «разбавление и фрагментация продукта», когда вы идете вниз по линии.

Вы будете CRM или ERP или обработка заказов /отправка или Microsoft Excel?

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

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

  • Мастер-ветвь, ее возможности продукта и функциональные возможности
  • Пользовательские расширения, типы и варианты расширения
  • Значение и изменение «настраиваемых полей»

.. для создания дорожной карты ассимиляции и согласования всех этих нитей /ветвей продукта в главном контексте вашего основного приложения.

PS: Соединитесь со мной, я знаю человека, который может помочь вам исправить это:)

ответил Alex S 10 22015vEurope/Moscow11bEurope/MoscowTue, 10 Nov 2015 08:21:18 +0300 2015, 08:21:18
-5

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

  • Теперь, когда клиент запрашивает обновление, переместите их в новый разветвленный репозиторий.
  • Если вы хотите объединить их, чтобы справиться с ними, сделайте это как первое и разрешите конфликты.
  • Затем управляйте своими проблемами и спринтами с помощью своего репозитория и сохраняйте тех мастеров, которые хотите запустить в главном. Это может привести к большей нагрузке на периоды выпуска, но это сэкономит вам время.
  • Поддерживать основную ветку основного репозитория для новых клиентов, а основной репозиторий должен иметь только те ветви, над которыми вы работаете, для будущих вещей. Затем ветви ветвей можно удалить после их переноса в клиентские репозитории.

Я лично импортировал репозиторий из GitHub с 40 филиалами в Bitbucket и создал 40 репозиториев , Прошло всего четыре часа. Это была вариация темы WordPress , поэтому нажатие и вытягивание было быстрым.

Есть много причин «не делать это правильно в первый раз», и я думаю, что те, кто принимает их быстро и перейдут к «сделать это правильно на этот раз», всегда будут успешными.

ответил Farrukh Subhani 10 22015vEurope/Moscow11bEurope/MoscowTue, 10 Nov 2015 00:01:04 +0300 2015, 00:01:04

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132