Практические рекомендации

Миграция

• Как осуществить перенос исходного кода с Visual SourceSafe.
• Как осуществить перенос исходного кода из других систем управления версиями.

Как осуществить перенос исходного кода из Visual SourceSafe

Для переноса исходного кода из VSS выполните следующие действия.

Примечание Для выполнения этих действий нужно быть членом группы администраторов Team Foundation.

1. Подготовка VSS. Приготовьтесь к переходу, создав резервные копии базы данных VSS и убедившись в том, что файлы возвращены в систему. Запустите инструмент Visual SourceSafe Analyze для выявления и разрешения конфликтов целостности данных в существующей БД.

2. Анализ проектов. Запустите конвертер (инструмент командной строки VSSConverter.exe ), передав ему с ключом analyze имя XML -файла, содержащего необходимые параметры, как показано в примере:

   VSSConverter analyze conversionsettings.xml

   Пример XML -файла параметров:

   <?xml version="1.0" encoding="utf-8"?> 
     <SourceControlConverter>
     <ConverterSpecificSetting> <Source name="VSS">
        <VSSDatabase name="c:\VSSDatabase"></VSSDatabase> 
      </Source> <ProjectMap>
      <Project Source="$/MyFirstProject">
        </Project> <Project Source="$/MySecondProject"></Project>   
      </ProjectMap> </ConverterSpecificSetting> 
    </SourceControlConverter>

   Файл параметров содержит имя БД VSS. В атрибуте name задается имя папки, содержащей .ini -файл хранилища исходного кода. Элементы <Project> определяют пути к проектам в БД VSS, которые вы собираетесь преобразовать. Для миграции всей БД VSS введите <Project Source="$/"></Project> .

   Команда analize инструмента VssConverter.exe создает файл usermap.xml. Добавив сопоставления в этот файл, вы можете изменить имена, связанные с историей версий и другие, с регистрационных имен VSS на регистрационные имена TFS Windows.

3. Перемещение проектов. Выберите папки, которые хотите перенести, и запустите инструмент VSSConverter.exe с аргументом migrate, как показано в примере:

   VSSConverter migrate conversionsettings.xml

   Вы снова передаете команде XML -файл параметров настройки, но на этот раз с двумя важными дополнениями:

   <?xml version="1.0" encoding="utf-8"?> 
     <SourceControlConverter> <ConverterSpecificSetting> 
       <Source name="VSS">
   <VSSDatabase name="c:\VSSDatabase">
     </VSSDatabase> </Source> <ProjectMap>
      <Project Source="$/MyFirstProject" 
        Destination="$/MyTeam_ ProjectOne"></Project>
      <Project Source="$/MySecondProject" 
     Destination="$/MyTeam_ ProjectTwo"></Project> </ProjectMap>   
     </ConverterSpecificSetting> 
     <Settings>
     <TeamFoundationServer name="YourTFSServerName"
      port="PortNumber" protocol="http">
     </TeamFoundationServer>
    </Settings> 
   </SourceControlConverter>

   Обратите внимание на дополнительный атрибут Destination в элементах <Project> . Значение этого атрибута указывает на командный проект TFS (созданный вами заранее). Элемент <Settings> содержит подробности подключения уровня приложений TFS.

Дополнительные ресурсы

• Дополнительную информацию о подготовке к миграции вы найдете в статье "Walkthrough: Preparing to Migrate from Visual SourceSafe to Team Foundation" по адресу http://msdn2.microsoft.com/en-us/library/ms181246 (en-us,vs.80).aspx.
• Дополнительную информацию о миграции вы найдете в статье "Walkthrough: Migrating from Visual SourceSafe to Team Foundation" по адресу http://msdn2.microsoft.com/en-us/library/ms181247(VS.80).aspx.
• Дополнительную информацию об ограничениях конвертера Visual SourceSafe вы найдете в статье "Visual SourceSafe Converter Limitations" по адресу http://msdn2.microsoft.com/en-us/library/ms252491(VS.80).aspx.

Как осуществить перенос исходного кода из других систем управления версиями

Вы можете вручную экспортировать файлы из прежней системы управления версиями, а затем импортировать их в Team Foundation Server. Чтобы сохранить историю и другие атрибуты системы, воспользуйтесь объектной моделью Team Foundation Server, чтобы написать собственный инструмент миграции.

В настоящий момент корпорация Microsoft ведет работу по созданию конвертера ClearCase. О выпуске конвертера будет объявлено дополнительно в блоге TFS Migration по адресу http://blogs.msdn.com/tfs_migration. Существует также конвертер, созданный компанией Component Software, совместимый с GNU RCS, CS-RCS, GNU CVS, Subversion (SVN) и Visual SourceSafe (VSS) .

Дополнительные ресурсы

• Загрузить набор инструментов Visual Studio Team Foundation Server SDK можно из источника, расположенного по адресу http://go.microsoft.com/ fwlink/?linkid=68586.
• Дополнительную информацию о расширяемости системы Team Foundation Server вы найдете в статье "Walkthru: The Version Control Object Model" по адресу http://msdn2.microsoft.com/en-us/library/bb187335 (VS.80). aspx.
• Дополнительную информацию о конвертере компании Component Software вы найдете на сайте компании по адресу http://www.component-software.com/Products/Converter/.

Управление проектом и рабочей областью

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

Как выбрать между созданием одного командного проекта и нескольких

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

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

Основные вопросы, которые вам предстоит ответить, таковы:

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

Далее описаны типичные структуры проектов.

Один проект на все приложение

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

• Почему следует использовать эту структуру?
  • Она упрощает перенос кода, рабочих элементов и прочих ресурсов.
• Почему не следует использовать эту структуру?
  • В параллельно разрабатываемых выпусках приходится использовать бщие политики возврата после правки, схему рабочих элементов и уководство по процессам.
  • Сложно составлять отчеты об ошибках: стандартные отчеты составляются для всего проекта, поэтому вам придется производить фильтрацию по выпуску.
  • Если у вас сотни приложений, каждое из которых находится в собственном проекте, вы можете превысить предел масштабируемости TFS.
  • По мере роста количества выпусков у вас накапливается солидный "багаж". Лучший способ избавиться от него - создать новый проект и перенести в него нужный вам в будущем код.

Один проект на один выпуск

Создается новый проект для каждой версии вашего приложения.

• Почему следует использовать эту структуру?
  • Она удобна, если вы хотите начинать проект заново после каждого выпуска.
  • Старый проект можно использовать для сопровождения выпуска, передав отдельной группе.
  • Легко перемещать исходный код из одного проекта в другой.
• Почему не следует использовать эту структуру?
  • Достаточно сложно перемещать рабочие элементы и ресурсы TFS из одного проекта в другой. Рабочие элементы можно копировать в другой проект только по одному. Если вам захочется переместить наборы элементов, придется делать это вручную или написать собственную утилиту.
  • Если вы управляете сотнями проектов, то рискуете превысить предел масштабируемости TFS.

Выбирая стратегию, имейте в виду следующее:

• Выбирая структуру, думайте о дне завтрашнем: реструктуризация существующих командных проектов - трудное занятие.
• Имеются способы организовать общий доступ к исходному коду из нескольких командных проектов:
  • ветвлением исходного кода из одного проекта в другой;
  • сопоставлением исходного кода из другого проекта в вашу рабочую область.
• Система Team Foundation Server способна вместить около 500 проектов icrosoft Solution Framework (MSF) , основанных на шаблоне процесса gile Software Development (MSF Agile) , или 250 проектов на шаблоне процесса MSF CMMI. Создавая собственный процесс или настраивая существующий, помните, что на масштабируемость сервера оказывает огромное влияние схема рабочего элемента. Чем сложнее схема, там меньше проектов сможет поддерживать сервер.

Дополнительные ресурсы

• Дополнительную информацию о стратегии выбора проекта вы найдете в логе Эрика Ли (Eric Lee) "When to use Team Projects" по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

Как организовать дерево исходного кода

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

• Main - контейнер для всех объектов, необходимых для передачи проекта аказчику.
  • Source - контейнер для всех объектов, необходимых для выполнения борки.
    • Code - контейнер для исходного кода.
    • Shared Code - контейнер для исходного кода, используемого совместно с другими проектами.
    • Unit Tests - контейнер для модульных тестов.
    • Lib - контейнер для двоичных зависимостей.
  • Docs - контейнер для документации, поставляющейся с проектом.
  • Installer - контейнер для исходного кода и двоичных файлов программы установки.
  • Tests - контейнер, содержащий результаты испытаний, проводимых тестовой командой.

При ветвлении папки Main структура папок и файлов будет скопирована в новую ветвь, например:

• Development - ветвь разработки.
  • Source - контейнер для всех объектов, необходимых для выполнения борки.
    • Code - контейнер для исходного кода.
    • Shared Code - контейнер для исходного кода, используемого совместно с другими проектами.
    • Unit Tests - контейнер для модульных тестов.
    • Lib - контейнер для двоичных зависимостей.
• Main - ветвь интеграции.
  • Source - контейнер для всех объектов, необходимых для выполнения борки.
    • Code - контейнер для исходного кода.
    • Shared Code - контейнер для исходного кода, используемого совместно с другими проектами.
    • Unit Tests - контейнер для модульных тестов.
    • Lib - контейнер для двоичных зависимостей.
  • Docs - контейнер для документации, поставляющейся с проектом.
  • Installer - контейнер для исходного кода и двоичных файлов программы установки.
  • Tests - контейнер, содержащий результаты испытаний, проводимых тестовой командой.

Как определять сопоставления рабочей области

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

Создание сопоставления рабочей области для проекта, которого еще нет на жестком диске

1. В окне Source Control Explorer выделите корневую папку исходного кода.
2. Щелкните ее правой кнопкой и выберите команду Get Latest Version.
3. Выберите локальную папку, в которую хотите отобразить рабочую область.

Изменение сопоставления рабочей области проекта, уже имеющегося на жестком диске

1. Выберите в меню File команды Source Control и Workspaces.
2. В диалоговом окне Manage Workspaces добавьте, удалите или отредактируйте существующую рабочую область.

Просмотр существующего сопоставления рабочей области

1. В окне Source Control Explorer выделите папку с исходным кодом.
2. Щелкните ее правой кнопкой и выберите команду Properties. В разделе Local Name будет отображено сопоставление рабочей области на локальном диске.

Создавая сопоставления рабочей области, используйте следующие рекомендации:

• Сопоставляйте рабочие области на корневом уровне командного проекта В новых командных проектах сопоставляйте корень проекта ( $/ MyTeamProject ) с папкой на локальном диске, имеющей то же имя, например, C:\TeamProjects. Вся структура локальной папки создается автоматически и будет в точности повторять структуру в системе управления исходным кодом.
• Используйте уникальный путь к локальной папке на совместно используемых компьютерах Два пользователя одного и того же компьютера не могут использовать одно сопоставление рабочей области. Допустим, вы и ваш коллега не можете сопоставить один командный проект ( $/MyTeam-Project ) с одной и той же папкой на локальном компьютере. Создавайте сопоставления в папке Мои документы (хотя это удлиняет путь) или разработайте соглашение об именах для папок на локальном компьютере (например, C:\TeamProjects\User1, C:\TeampProjects\User2 и т. д.).
• Подумайте, нужно ли вам все дерево Чтобы увеличить производительность и сократить занимаемый объем диска, сопоставляйте только те файлы, которые требуются для проекта разработки. Как правило, вам требуются файлы и проекты, связанные с решением, над которым вы работаете.
• Не используйте сопоставление рабочей области для поддержки зависимостей между различными проектами Как правило, следует избегать зависимостей, пересекающих командные проекты. Старайтесь объединить все связанные и зависимые решения и проекты в одном командном проекте. Это позволит реже придется прибегать к настройке сборочного сценария. Если у вас есть зависимость, для ее определения используйте ссылки на проект или перенесите зависимость из общего проекта в свой проект. Следует избегать файловых ссылок, потому что ими сложнее управлять. Исключение составляют случаи, когда параллельно ведется разработка зависимого проекта, и вам нужно получать изменения в реальном времени. В этом случае вы можете воспользоваться сопоставлением рабочей области. Если зависимый код приводит к появлению большого количества серьезных ошибок, используйте ветвление.

Дополнительные ресурсы

• Дополнительную информацию о создании рабочей области вы найдете в статье "How to: Create a Workspace" по адресу http://msdn2.microsoft.com/ en-us/library/ms181384(VS.80).aspx.
• Дополнительную информацию о редактировании рабочей области вы найдете в статье "How to: Edit a Workspace" по адресу http://msdn2. microsoft.com/en-us/library/ms245466(VS.80).aspx.