Как модифицировать и управлять компонентами углов для разных проектов

Question

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

Вот что это будет выглядеть в реальном сценарии жизни:

компании 1

• Модуль 1
• Модуль 2
• Модуль 3

Company 2

• Модуль 1 (с определенной функцией или изменения)
• Модуль 3

Company 3

• Модуль 2
• Модуль 3
• модуль 4 (только для этого проекта)

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

Вы можете увидеть ад, которым это стало. Это очень сложно поддерживать, и еще сложнее развернуть разные версии приложения.

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

Спасибо!

Answer 1

Вы ищете руководство по управлению технологическими процессами или инструментам?

С точки зрения инструментов вы можете использовать npm со своим частным сервисом или просто направлять на некоторое частное ретрансляции git. Бауэр может сделать то же самое.

В пространстве Windows есть NuGet, на котором вы можете разместить свои репозитории или для этого есть службы.

Git поддерживает подмодули и поддеревья, но я лично их не рекомендую. Создание зависимостей часть вашей реальной истории git сложна.

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

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

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