Больше на: Помощь Структурирование Решений VS2010 / Проекты и TFS2010 - PullRequest
Новая
       30

Больше на: Помощь Структурирование Решений VS2010 / Проекты и TFS2010

0 голосов
/ 22 февраля 2011

Это продолжение нашего предыдущего поста (Справка по структурированию решений / проектов VS2010 и TFS2010).

У нас есть несколько вопросов относительно того, как структурировать наши решения и проекты VS2010 для наилучшей организации, а также сохранить и использовать TFS2010.

В настоящее время наш код структурирован примерно так: 

/OverallAppName  
OverallAppName.sln  
-/Client  
-    -/WindowsFormsProject1  
WindowsFormsProject1.sln  
-    -/WindowsFormsProject2  
WindowsFormsProject2.sln  
-/Components  
-    -/ClassLibrary1 (common library referenced by other projects)  
ClassLibrary1.sln  
-    -/ClassLibrary2  
ClassLibrary2.sln  
-    -/ClassLibrary3  
ClassLibrary3.sln  
-    -/ClassLibrary4  
ClassLibrary4.sln  
-    -/ClassLibrary5  
ClassLibrary5.sln  
-/Server  
-    -/WindowsServiceProject1  
WindowsServiceProject1.sln  
-    -/WindowsServiceProject2  
    WindowsServiceProject2.sln  
-    -/WebProject1  
    WebProject1.sln  
-    -/WebProject2  
    WebProject2.sln

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

Любые предложения ????? Как мы можем структурировать все эти различные типы проектов VS2010 в логическую структуру, в которой отдельные группы могут работать над отдельными частями (а не над всем решением), у нас все еще могут быть ссылки на проекты, мы можем хранить их в TFS2010, собирать и разветвлять в них, и следовать «рекомендуемым лучшим практикам»?

Спасибо. (Извините, я не уверен, что форматирование получилось очень хорошим.)

1 Ответ

0 голосов
/ 30 июня 2012

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

Причина, по которой я это говорю, заключается в том, что вы можете использовать сборки, запускаемые при регистрации, чтобы немедленно собрать код, чтобы доказать, что он работает (или, что еще лучше, использовать проверку Gated).Полезность этих сборок обратно пропорциональна времени, затрачиваемому на их запуск.Таким образом, если у вас есть масштабное решение, для сборки которого требуется 20 минут, оно лишит вас преимуществ этих типов сборок.Однако, если у вас было несколько небольших решений, которые занимали около 5 минут каждое, то вы получите только модифицированные решения, основанные на регистрации, и узнаете результаты раньше.

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

Структура папок не будет сильно отличаться от того, что у вас есть выше (при условии, что я правильно его интерпретирую) 

/OverallApplication
    /Clients
        /Client1
            -Client1.sln
            /Client1Project1
                -Client1Project1.csproj
            /Client1Project2
                -Client1Project1.csproj
            ...
         ...
    /Components
         -Components.sln
         /ClassLibrary1
             -ClassLibrary1.csproj
         /ClassLibrary2
             -ClassLibrary2.csproj
         ...
    /Server
        /WebApp1
            -WebApp1.sln
            /WebApp1Project1
                -WebApp1Project1.csproj
            /WebApp1Project2
                -WebApp1Project1.csproj
            ...
         ...     
    /CodeSigningKey
        -KeyPair.snk
    /ReferencedAssemblies
        /Manufacturer1
            -Manufacturer1Assembly1.dll
            ...
        ...

Общие библиотеки по-прежнему можно добавлять в качестве ссылок на проекты в решениях сервера и клиента.Я представил несколько новых папок для общих элементов, таких как ключ подписи кода и сторонние сборки, на которые есть ссылки (например, Enterprise Library).

Кроме того, вы захотите использовать ветвлениекакая-то стратегия, позволяющая разделить ветви кода Main, Dev и Release.Для этого я рекомендую немного прочитать руководство по ветвлению ALM Rangers на codeplex.http://vsarbranchingguide.codeplex.com/releases

...