Настройка Visual SourceSafe - PullRequest
2 голосов
/ 22 июля 2009

В настоящее время наш .net проект 3.5 распространяется на три отдельных сервера представления, бизнес-логики и серверы состояний. Пожалуйста, порекомендуйте, как настроить этот проект под VSS 6.0, учитывая, что у нас есть несколько проектов в dotnet, и над ними работает группа разработчиков. В настоящее время мы имеем их как Проект 1:

>Business Object Layer
>WebService
>Proxy
>Web

Проект 2:

>Business Object Layer
>Proxy
>Web

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

Ответы [ 2 ]

3 голосов
/ 22 июля 2009

Я бы выложил рабочие каталоги разработчика так:

c:\src\
    solutions\
        *.sln files with references to the project files
    project1\
        project1.csproj
        *.cs
    project2\
        project2.csproj
        *.cs
    ...

То есть: один проект (* .csproj) на каталог, без вложенной структуры каталогов. Все файлы решений в отдельном каталоге. (дополнительно поместите файлы решения в корневой каталог (src)).

Разработчики открывают файлы решения для той части системы, над которой они работают.

Структура папок на сервере VSS должна быть точно такой же.

На производственных серверах я просто перенесу все на все серверы (то есть, если вы строите на серверах, то есть. Если вы не строите на серверах, я бы создавал сценарии развертывания, которые создают правильное решение для разработчика машины, затем копирует все из bin\Debug|Release в правильное местоположение).

Кстати, я бы рекомендовал использовать другую систему контроля версий, например, subversion. С VSS нелегко работать, и он мешает вам, ИМО.

0 голосов
/ 22 июля 2009

Поскольку вы не можете использовать какие-либо инструменты сторонних разработчиков, рассматривали ли вы использование Team Foundation Server (по крайней мере, компонента управления версиями), а не VSS? Из моего опыта TFS - достойная система контроля версий. С TFS у вас есть приятная функциональность редактирования-слияния, а не эксклюзивная проверка, которая делает разработку более чем одним человеком намного приятнее. Кроме того, ветвление и слияние в TFS намного лучше, чем в VSS.

Существует бесплатная лицензия рабочей группы для TFS, которая дает вам до 5 именованных пользователей, после 5 пользователей или, если вы хотите аутентификацию / авторизацию Active Directory, вы должны использовать стандартную версию. В зависимости от вашего уровня льгот MS Partner ваша компания может уже иметь лицензию на TFS.

Кроме того, все клиенты должны иметь клиентскую лицензию (и установленный Team Explorer). Из моего понимания MS Licensing не требуется, чтобы у всех, кто будет иметь доступ к серверу TFS, был Team SKU Visual Studio, и чтобы вы могли продолжать использовать VS Pro и приобрести TFS CAL (которая поставляется с Team Explorer). Я реализовал это точное решение у предыдущего работодателя.

В TFS я бы настроил ваше решение следующим образом (я только показал Trunk как полностью расширенный и (частичный) ответвление функции):

$/Project1/
   Branches/
       /Spike1/
           BusinessObject/
               BusinessObject.sln
               BusinessObjectProject1/
               BusinessObjectProject2/
           WebService/
               WebService.sln
               WebServiceProject1/
               WebServiceProject2/
           <etc>
   Tags/
   Trunk/
       BusinessObject/
           BusinessObject.sln
           BusinessObjectProject1/
           BusinessObjectProject2/
       WebService/
           WebService.sln
           WebServiceProject1/
           WebServiceProject2/
       Proxy/
           Proxy.sln
           ProxyProject1/
           ProxyProject2/
       Web/
           Web.sln
           WebProject1/
           WebProject2/
$/Project2/
   Branches/
   Tags/
   Trunk/
       BusinessObject/
           BusinessObject.sln
           BusinessObjectProject1/
           BusinessObjectProject2/
       Proxy/
           Proxy.sln
           ProxyProject1/
           ProxyProject2/
       Web/
           Web.sln
           WebProject1/
           WebProject2/

Папка Branches позволяет легко реализовать стандартное ветвление и слияние, особенно потому, что TFS позволяет выполнять только операции ветвления / слияния между ветвью и ее прямым предком и прямым потомком. Идея состоит в том, что большинство повседневных разработок происходит в Trunk, и когда вам нужно временно изолировать изменения для работы над основной функцией или шипом, вы берете ветку из Trunk в Branches, которую затем можете объединить обратно в Trunk, когда вы будете готовы интегрировать (а также продолжать объединять текущие изменения из магистрали в вашу функциональную ветвь).

Папка «Теги» позволяет вам как переходить к тегу, когда вы готовы сделать снимок определенной версии вашего кода, так и использовать эту папку для сборки и развертывания. Для сборки и развертывания вы создаете ветку из Trunk в / Tags / Test и из / Tags / Test в / Tags / Production, а затем объединяете свои изменения из / Trunk в / Tags / Test, когда вы готовы продвигать свои изменения в тестовая среда. Вы можете иметь либо непрерывную интеграционную сборку, работающую в / Tags / test, либо сборку по требованию, которая выполнит сборку из этой ветви и скопирует необходимые артефакты в соответствующие местоположения. Вы можете иметь аналогичные функции в ветке / Tags / Production, чтобы при объединении изменений из Test в Production вы продолжали выполнять автоматическую сборку и развертывание.

В дополнение к лучшему контролю исходного кода, с TFS вы также получаете такие вещи, как сервер сборки OK CI (с использованием Team Build и сборкой на коробке TFS или выделенном сервере сборки), отслеживание рабочих элементов (что довольно хорошо и приятно настраиваемый) и достойный проектный портал с использованием интеграции SharePoint с TFS. Все эти дополнительные функции также очень привлекательны, и я рекомендую взглянуть на некоторые другие отличные материалы TFS, доступные в Интернете, для получения более подробной информации.

...