Когда создается новый командный проект, когда нужно использовать «Создать новую ветвь системы управления версиями”?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Когда создается новый командный проект, когда нужно использовать «Создать новую ветвь системы управления версиями»?

Ответ

При создании нового проекта, в диалоговом окне «Указание параметров системы управления версиями» находятся следующие пункты: «Создать пустую папку системы управления версиями», «Создать новую ветвь системы управления версиями» или «Не создавать в этот момент папку системы управления версиями».

При выбранном пункте «Создать новую ветвь системы управления версиями» создается новая папка системы управления версиями для проекта, которая будет содержать все данные, содержащиеся в папке системы управления версиями другого существующего проекта. Т.е. выбирая этот пункт, говорится, что «проект X будет содержать все исходные коды проекта Y».

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

Однако если существующий проект содержит несколько релизов (даже если они внутренние), то лучше использовать » Создать пустую папку системы управления версиями » для нового проекта, и затем выполнить ветвление от определенного каталога в существующем проекте, а не от корневой папки. Это позволит получить только необходимые каталоги, и даст более гибкое решение при формировании необходимой внутренней структуры нового проекта. Ниже диаграммы иллюстрируют подобную проблему:

Ветвление проекта

Ветвление каталога

Можно ли использовать ветвление между проектами?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Можно ли использовать ветвление между проектами?

Ответ

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

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

• Смотрите Branching and Team Projects в руководстве Branching Guidance

Что такое метки и когда они должны использоваться?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Что такое метки и когда они должны использоваться?

Ответ

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

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

• Team Foundation Server не сохраняет историю изменений метки.
• Учитывая определенные разрешения, метки могут быть удалены или изменены, при этом нет способов отследить эти изменения.
• При создании метки необходимо помнить, что наименование метки должно быть уникальным по всей ее области видимости.
• Удаленные элементы не будут доступны в метке.

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

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

Как управлять ошибками при ветвлении?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Как управлять ошибками при ветвлении?

Ответ

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

Вариант 1: Ответственность и принадлежность для ошибок должны также переноситься в новый ответвленный проект разработки.

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

• Рабочий элемент принадлежит проекту разработки, в котором он был создан, и не может быть перемещен (только дублирован) в другой проект
• Значения полей могут быть только перенесены, если в конечном типе рабочего элемента определены те же самые поля
• Необходимы соответствующие разрешения для обоих проектов

Оригинальная ошибка должна быть закрыта и со ссылкой на скопированную ошибку.

Вариант 2: Ветвление выполняется только для исходного кода (в пределах того же проекта или в другой проект разработки). Ответственность и принадлежность для ошибок останутся в оригинальном проекте.

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

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

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

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

• «How to: Copy a Work Item» – http://msdn.microsoft.com/en-us/library/ms181321.aspx
• «Walkthrough: Adding Links and Attachments to Work Items» – http://msdn.microsoft.com/en-us/library/ms181270.aspx

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

<< Назад в TFS Branching Guidance – Q&A

Вопрос

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

Ответ

Управление доступом и разрешениями для системы управления версиями должны быть точно определены. Необходимо оценить уровни доступа, которые необходимы для ролей, определить матрицу ролей и обязанностей, которая поможет получить непротиворечивое и направленное на безопасность решение. Используйте группы на основе Active Directory, так как TFS будет автоматически обновлять произошедшие там изменения. Не забывайте о внешних пользователях, которым также может понадобиться доступ, это могут быть IT-специалисты или служба поддержки. При управлении разрешениями также необходимо учитывать любые существующие корпоративные политики управления безопасностью.

С точки зрения системы управления версиями, разрешения в TFS 2008 можно определяться отдельно от проектов, порталов, web-доступа и для служб отчетности. У пользователя могут быть различные разрешения для каждой ветви, к которой ему необходим доступ. Разрешения могут быть унаследованы или уставлены явно. Необходимые шаги, которые нужно выполнить для установки разрешений в потоках разработки, описаны в статье MSDN «How to: Control Access to Team Foundation Version Control«.

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

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

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

• «How to: Control Access to Team Foundation Version Control» – http://msdn.microsoft.com/en-us/library/ms253158.aspx

Существует ли наиболее предпочтительный метод идентификации при создании ветки?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Существует ли наиболее предпочтительный метод идентификации при создании ветки?

Ответ

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

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

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

Что необходимо для объединения или перемещения потоков разработки?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Что необходимо для объединения или перемещения потоков разработки?

Ответ

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

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

1. Каковы важные причины для проведения таких операций?
2. Какое будет преимущество от этих операций? Что будет при сохранении текущего состояния?
3. Каковы риски объединения?
4. Какие ресурсы необходимы для проведения объединения?
5. Какой план завершения?
6. Какие эффекты это даст для будущей разработки?
7. Как будут и какие существующие лучшие практики включены?
8. Должны ли сохраниться история и связанные рабочие элементы с исходным кодом?

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

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

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

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

• “How to: Branch Files and Folders” – http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx
• “How to: Merge Files and Folders” – http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
• Раздел Baseless Merge рукодства Branching Guidance

Можно ли объединить все изменения вручную?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Можно ли объединить все изменения вручную?

Ответ

Когда два потока объединены, TFS не будет создавать конфликты для элементов, которые были изменены (или добавлены) только в исходной ветке и не были изменены в конечном потоке от последней операции объединения, такие изменения будут объединены автоматически.

Возможно, Вы захотите просмотреть каждое изменение до объединения, но TFS не будет создавать конфликты для таких элементов, и создание конфликта не может быть вызвано.

Но так как любое изменение результата слияния необходимо зарегистрировать, то можно сделать обзор всех изменений, которые ожидают регистрации после операции объединения.

Когда авто-объединение не работает?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Когда авто-объединение не работает?

Ответ

Когда операция слияния выполнена и есть конфликты, в диалоговом окне «Разрешение конфликтов» появляется опция «Автоматическое слияние». Для того чтобы эта опция работала, необходимо соответствие следующим критериям:

1. Объединение файла должно быть разрешено для типа файла (Параметры Team Foundation Server
   -> Типы файлов системы управления версиями). По умолчанию, все типы файлов для исходного кода, которые используются Visual Studio, разрешены для объединения.
2. Изменения, сделанные в исходном и конечном файле, должны иметь тип редактирование (переименование/удаление не поддерживается).
3. Изменения должны быть сделаны в различных частях файла (в различных строках).

Иногда «Автоматическое слияние » выполняется и в других случаях. При объединении двух потоков, некоторые из файлов будут автоматически объединены из исходного в конечный файл без привлечения пользователя. Это будет выполнено в отношении файлов, которые были изменены в исходном потоке и не были изменены в конечном потоке от предыдущего слияния. В обратном случае необходимо будет решить конфликт процесса слияния.

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

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

• См. раздел Baseless Merge руководства Branching Guidance
• «Understanding Merging» – http://msdn.microsoft.com/en-us/library/ms181427(VS.80).aspx

Рабочие элементы являются частью модели ветвления/слияния?

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Рабочие элементы являются частью модели ветвления/слияния?

Ответ

Нет, рабочие элементы существуют на другом логическом уровне, в отличие от репозитория версионного контроля. Это означает ветвление или объединение ветвей не влияет на рабочие элементы:

• Рабочие элементы не будут дублироваться во время процессов ветвления или объединения
• Ссылки на рабочие элементы не будут обновляться или расширяться ссылками, которые ссылаются на новые элементы ветвления/объединения

Все операции ветвления/объединения требуют новой регистрацию (check-in) в версионном хранилище, они не переносят историю предыдущего рабочего элемента и не затрагивают предыдущие связи нового рабочего элемента при ассоциации. Рабочие элементы могут быть связаны с изменениями ветвления/объединения в процессе их регистрации или принудительно связываться с изменениями с использованием политики регистрации.

При обратной/прямой интеграции Вы можете создавать отдельные рабочие элементы, связанный с объединением. Например, интегрируя код потока разработки в основной поток после завершения интеграционного тестирования, можно создать рабочий элемент «Законченно интеграционное тестирование для релиза X.»

Если необходимо дублировать рабочие элементы для ассоциации с операцией ветвления/слияния, используйте функцию «Copy Work Item» (см. Дополнительные ресурсы). Вы можете скопировать рабочий элемент в того же проект или в другой проект разработки. При этом, после копирования рабочего элемента, ссылки в скопированном рабочем элементе будут ссылаться на те же артефакты как в исходном рабочем элементе.

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

• «How to: Copy a Work Item» – http://msdn.microsoft.com/en-us/library/ms181321.aspx