Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘TFS Branching Guidance’ Category

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

Posted by Shamrai Alexander на 20 декабря, 2009

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

Вопрос

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

Ответ

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

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

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 20 декабря, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

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

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 20 декабря, 2009

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

Вопрос

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

Ответ

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

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

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 20 декабря, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 20 декабря, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | Leave a Comment »

В чем недостаток выбранных наборов изменений?

Posted by Shamrai Alexander на 20 декабря, 2009

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

Вопрос

В чем недостаток выбранных наборов изменений (cherry picked changeset)?

Ответ

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | Leave a Comment »

 
%d такие блоггеры, как: