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

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

Archive for Декабрь 2009

Выполняя слияние между двумя ветвями с выбранной опцией “Все изменения до определенной версии”, какой тип версии предпочтителен (“Последняя Версия” [по умолчанию], “Набор изменений”, «Дата», «Метка» или «Версия рабочей области»)?

Posted by Шамрай Александр на Декабрь 26, 2009

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

Вопрос

Выполняя слияние между двумя ветвями с выбранной опцией «Все изменения до определенной версии», какой тип версии предпочтителен («Последняя версия» [по умолчанию], «Набор изменений», «Дата», «Метка» или «Версия рабочей области»)?

Ответ

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

  • «Последняя версия» – все наборы изменений, которые не были объединены из исходной ветви от последней операции слияния, будут объединены с целевым потоком. Однако с момента последнего слияния в исходной ветви может вестись активная разработка, поэтому какие точно изменения будут объединены, может быть не четко определено.
  • «Набор изменений» – все наборы изменений из исходного ветви, которые были зарегистрированы до указанного набора изменений, будут объединены с целевой ветвью (определение набора изменений эквивалентно определению даты, где дата – дата регистрации набора изменений).
  • «Дата» – все наборы изменений исходной ветви, которые были зарегистрированы до указанной даты, будут объединены с целевым потоком.
  • «Метка» – все наборы изменений, которые помечены в исходной ветви, будут объединены с целевым потоком. Поскольку метки в TFS не включают удаления, то изменения удаления, никогда не будут объединены в целевой ветви.
  • «Версия рабочей области» – все изменения ветви до версий в указанном рабочем пространстве будут объединены с целевым потоком. Также как и для опции «Метка» изменения типа «удаление» не будут объединены.

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

Опция «Последняя версия» может использоваться, когда четко понятно, какие изменения будут содержаться в последней версии. Можно временно «заморозить» исходную ветвь на время проведения операции слияния с использованием блокировки до начала слияния.

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

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

Posted in Microsoft, Team Foundation Server FAQ, TFS Branching Guidance, Visual Studio | Отмечено: , , , , , , , | 2 комментария »

Можно ли удалять ветви?

Posted by Шамрай Александр на Декабрь 26, 2009

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

Вопрос

Можно ли удалять ветви?

Ответ

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

  • Есть ветвь от А к B
  • Есть ветвь от B к C

Слияние от А к C возможно (от А к B, от B к C) как и слияние С к А (от C к B, от B к A). Однако если поток B будет удален, то дальнейшее такое слияние становится невозможным. Поэтому, если необходимо удалить папку ветви, то нужно определить, есть ли у нее какие-нибудь дочерние потоки, созданные от нее. Если такие потоки существуют, то лучше сделать ветвь невидимой с помощью разрешений системы управления версиями, что не ограничит будущие слияния, пока папка скрыта от конечного пользователя.

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

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

Что такое слияние без базовой версии и чем оно отличается от обычного слияния?

Posted by Шамрай Александр на Декабрь 26, 2009

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

Вопрос

Что такое слияние без базовой версии и чем оно отличается от обычного слияния?

Ответ

Слияние без базовой версии позволяет объединять две папки, которые не связаны ветками, создаваемыми через команду branch клиента командной строки tf или с помощью Обозревателя управления исходным кодом. Как только слияние без базы будет один раз выполнено, то в дальнейшем между этими папками можно будет выполнять обычное слияние (как будто эти папки связаны ветками). Хотя слияние без базовой версии может быть полезно для двух логически связанных каталогов, но не связанных ветками, в нем есть определенные недостатки по сравнению с обычной операцией ветвления/слияния:

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

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

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

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

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

Posted by Шамрай Александр на Декабрь 21, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

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

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

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

Posted by Шамрай Александр на Декабрь 21, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

Posted by Шамрай Александр на Декабрь 21, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

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

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

Posted by Шамрай Александр на Декабрь 21, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

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

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

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

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

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

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

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

Posted by Шамрай Александр на Декабрь 21, 2009

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

Вопрос

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

Ответ

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

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

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

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

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

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

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

Posted by Шамрай Александр на Декабрь 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 Шамрай Александр на Декабрь 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 »

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