Я опытный разработчик Angular 1, который теперь читает на Angular 2. Мы планируем сделать большой проект, состоящий из нескольких небольших «перекрывающихся» приложений, которые используют один и тот же удаленный API. Меня интересует ваше мнение о том, как настроить этот проект в отношении правильного управления проектами, тем более что мое знание git ограничено.Лучший способ настроить мой угловой проект
Подумайте об этом, как о продуктах Google, где один пользователь может использовать или не использовать несколько продуктов с той же учетной записью. Некоторые данные и «виджеты» используются в нескольких продуктах, а некоторые компоненты зависят от продукта. Это выглядит примерно так (оранжевые части повторно используемые компоненты в продуктах):
Подробнее:
- Мы не должны беспокоиться о бэкэнде API и т.д. Это все позабоченное из.
- Должно быть одно приложение-контейнер, которое обрабатывает auth, session и т. Д. И имеет несколько пунктов меню, которые позволяют пользователю переключаться между продуктами (предпочтительно всегда оставаться в контейнеровом приложении).
- Я хотел бы управлять продуктами (все серые пунктирные элементы) отдельно в терминах git и разворачиваться (например, я не хочу, чтобы каждый раз, когда я его обновлял, каждый раз добавлял все свои whitelabels).
- Я хотел бы иметь возможность использования многократных меньших компонентов, которые я могу обновить во всех проектах в процессе редактирования одного из моих проектов. Поэтому скажите, что я работаю над whitelabel Customer Y, и я хочу отредактировать один из моих повторно используемых компонентов, которые я использую там, я не хочу открывать отдельный проект, нажимать обновления, а затем вытаскивать обновления в свою whitelabel проект для каждого небольшого изменения, которое я делаю.
Вопросы:
- Что бы это выглядит с точки зрения управления проектами (мерзавца)?
- Где мои службы подходят в этом контакте с API?
Надеюсь, это достаточно ясная история. Пожалуйста, спросите, могу ли я объяснить что-нибудь лучше.
Это отличный вопрос, но я боюсь, что он может быть немного шире. Кроме того, пункты 3 и 4 пули выглядят так, как будто они могут противоречить друг другу. Чтобы быть успешным с этим типом архитектуры, вы действительно должны развертывать свои компоненты в виде пакетов (npm/bower/etc), которые вы можете использовать независимо. То, как вы развертываете, зависит от того, как выглядит ваша конфигурация непрерывного развертывания (т. Е. Jenkins-> Sinopia), но это еще одна длинная тема. – axlj