Front-end vs back-end организация решений

Question

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

Мы являемся магазином Microsoft, поэтому внешний интерфейс (проект MVC) и внутренний интерфейс (WebAPI) сосуществовали в решении для визуальной студии, и все было хорошо.

Мы переходим к угловому интерфейсу, и сторонники предпочитают другую IDE, менеджер пакетов и т. Д. (WebStorm, NPM и т. Д.). И это правильно, поскольку MS не спешит внедрять эти новые передовые технологии.

Вопрос

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

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

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

Answer 1

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

У нас было несколько проектов, для которых нам нужно было обновить интерфейсный и внутренний код, но им также нужно было иметь свои собственные "настройки" в папке "Содержимое".

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

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

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

Мы обнаружили, что этот рабочий процесс является лучшим способом предотвращения конфликтов.

Это на самом деле не решает вашу проблему с инструментами, но может дать вам некоторые идеи о том, как вы могли бы подойти к этой проблеме. Тем не менее, я считаю, что Visual Studio + Resharper намного удобнее, чем Webstorm. JetBrains сделал и Webstorm и Resharper, так что вы получите в Resharper те же функции, что и в Webstorm.

Я согласен с вами, что Nuget - отстой для установки библиотек JS - вы никогда не представляете, что именно произойдет, когда вы его используете. Я обычно делаю установку NPM в другое место на моем жестком диске и просто копирую нужные мне файлы в каталог Scripts. Это также позволяет избежать большого количества пуха, который вы получаете при установке NPM. Но если вы хотите использовать NPM или bower, нет никаких причин, по которым вы не могли бы использовать его в проекте VS и либо изменить каталог, для которого он настроен для установки, на Scripts, либо изменить путь в вашем скрипте BundleConfig или Grunt/Gulp для использования node_modules или bower_components, соответственно.