Каков рекомендуемый способ настройки таких проектов?

Question

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

Внешние сайты позволяют клиенту запрашивать различные вещи, которые мы предоставляем, оплачивать счета за коммунальные услуги и многое другое. Мы решили разбить многие из этих функций на части, потому что большинство из них работают совершенно иначе, чем другие. Так что это одно решение Visual Studio с WebUI и уровнем базы данных, разбитым на два проекта каждый. Например, утилита биллинга имеет проект Utility.WebUI и проект Utility.Domain. Вся БД / бизнес логика хранится в доменном проекте.

Внутренние сайты устраняют разрыв между бэк-офисной системой (IBM i) и веб-базой данных. Также заменит / улучшит некоторые из наших старых программ RPG. Теоретически они должны использовать ту же логику базы данных, что и внешние сайты, потому что имеют доступ к одной и той же базе данных. Как лучше всего ссылаться на эти проекты из другого решения? Должен ли я просто добавить ссылку на DLL или я должен импортировать этот проект из решения внешнего приложения во решение внутреннего приложения?

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

Имеет ли это смысл? Есть мысли?

Answer 1

Используйте свойство svn: externals , чтобы ссылаться на общий проект в ваших проектах.

Вы должны выбрать между 1) ссылкой на каталог, содержащий исходный код общего проекта (т. Е. Там, где находятся файлы csproj и cs), или 2) ссылкой на каталог, содержащий выходные данные сборки общего проекта (assembly / dll).

Обычно я предпочитаю метод 1), поскольку он упрощает изменение исходного кода общего проекта (вы можете вносить изменения без необходимости открывать решение общего проекта во втором экземпляре Visual Studio). Если вы не собираетесь часто вносить изменения в общий проект, лучше использовать метод 2). Это сокращает время компиляции и предотвращает случайные изменения исходного кода общего проекта. Оба метода хороши - дело вкуса.

Для обоих методов рекомендуется версия вашего общего проекта. т.е. создавать теги с номерами версий и ссылаться на теги, а не на ствол. Когда выйдет новая версия общего проекта, вы можете обновить свойство svn: externals других ваших проектов новым номером версии, запустить svn update, чтобы загрузить новую версию общего проекта, и перекомпилировать. Это особенно хорошо работает, если у вас есть сервер сборки для общего проекта, который выполняет тегирование автоматически.

Answer 2

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

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

В этом сценарии вы можете рассмотреть возможность использования инструмента управления зависимостями, такого как NPanday или NDepend, где вы должны указать, от какой версии каких сборок зависит каждый проект; Используя эти инструменты, вы можете иметь локальный репозиторий (например, Artifactory или Nexus) бинарных сборок для ссылки или выбрать использование внешних SVN для прямой ссылки на исходный код.