Опубликован: 25.03.2010 | Уровень: специалист | Доступ: платный
Дополнительный материал 1:

Руководства

< Лекция 18 || Дополнительный материал 1: 12345678910111213 || Дополнительный материал 2 >
Создавайте командный проект для каждой версии, если хотите с каждой новой версией начинать все заново

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

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

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

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

Используйте ветвление для обеспечения совместного доступа к исходному коду и двоичным файлам

Управление общим исходным кодом или двоичными файлами производится в два этапа:

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

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

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

Не используйте сопоставление для поддержки зависимостей между различными проектами

Как правило, следует избегать зависимостей, пересекающих командные проекты. Старайтесь объединять все взаимозависимые решения и проекты в общем командном проекте. При этом вам реже придется прибегать к настройке сценария сборки. Если у вас есть зависимость, используйте для ее определения ссылки на проект или создайте для зависимости ответвление из общего проекта в свой проект. Избегайте файловых ссылок, потому что ими сложнее управлять. Исключение составляют случаи, когда разработка зависимого проекта ведется параллельно, и вам нужны изменения в реальном времени. В этом случае стоит воспользоваться сопоставлением рабочей области. Тем не менее, даже в этом случае можно использовать ветвление для изоляции, если зависимый код приводит к возникновению слишком большого числа серьезных ошибок.

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

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

В новом командном проекте сопоставляйте корень проекта ( $/ MyTeamProject ) с папкой на локальном диске, имеющей похожее имя, например, C:\TeamProjects. Поскольку сопоставления являются рекурсивными, вся структура локальной папки создается автоматически и будет в точности повторять структуру в системе управления исходным кодом.

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

Используйте уникальный путь к локальной папке на общих компьютерах

Два пользователя одного компьютера не могут использовать одно и то же сопоставление рабочей области. Допустим, вы и ваш коллега не можете сопоставить один командный проект ( $/MyTeamProject ) с одной и той же папкой на локальном компьютере. Создавайте сопоставления в папке Мои документы (хотя это удлиняет путь) или разработайте соглашение об именах для папок на локальном компьютере (например, C:\TeamProjects\User1, C:\ TeampProjects\User2 и т.д.).

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

Сопоставляйте только части дерева исходного кода

Чтобы повысить производительность и сократить использование диска, сопоставляйте только те файлы, которые требуются для проекта разработки. В основном, вам требуются только файлы и проекты, связанные с решением, над которым вы работаете.

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

Структурируйте дерево исходного кода с учетом ветвления

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

  • 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 - контейнер с результатами тестов, проводившихся тестовой командой.

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

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

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

Используйте отложенные правки для архивации незавершенных изменений на сервере

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

Используйте отложенные правки, если вас прервали для выполнения более важного задания

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

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

Дополнительные ресурсы по управлению исходным кодом
< Лекция 18 || Дополнительный материал 1: 12345678910111213 || Дополнительный материал 2 >
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?

Евгений Летенков
Евгений Летенков
Россия, Москва, РУДН, 2005
Алексей Корзинин
Алексей Корзинин
Россия