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

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

Версионный контроль Visual Studio Team System 2010

Posted by Шамрай Александр на Июль 14, 2009

Систем версионного контроля на сегодняшний день уже много, как коммерческих, так и бесплатных (Microsoft VS TFS, IBM Rational ClearCase, SVN и т.д.). И по большому счету, все они решают одни и те же задачи, но каждый немного по-своему. Можно выделить следующие задачи:

  1. Обеспечение механизмов безопасного хранения проектных артефактов. Все что ни создается в течение проекта (файл, документ, модель, тестовый сценарий и т.д.) – все это имеет важное значение для проектной команды и потеря любого из этих компонентов крайне нежелательна и может привести к задержкам работ. Поэтому для всего, что команда создает, с чем работает каждый день, должно быть специальное хранилище, которое обеспечит не только хранение файла, но и хранение всей истории развития каждого элемента этого хранилища.
  2. Обеспечение механизмов доступа к проектным артефактам. Собственно возможность чтения и изменения всех проектных артефактов. Причем, система должна обеспечить доступ не только к последней версии файла, но и предоставлять возможность просмотра любой ранее созданной версии элемента хранилища, для того, чтоб можно было понять почему было внесено то или иное изменение. И тут же не стоит забывать о разграничении доступа к различным элементам версионного хранилища, т.е. к одному и тому же файлы различные пользователи могут иметь доступ на чтение/запись или только на чтение.
  3. Обеспечение параллельного доступа к проектным артефактам. Параллельная разработка – это уже давно стандарт для любой команды разработки ПО. Одновременное изменение одного и того же файла несколькими членами команды и объединение этих изменений с возможностью разрешения конфликтных блоков исходного кода. Использование веток для распределения разработки между внутренними группами или по функционалу, разрешение конфликтных ситуаций при слиянии веток.

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

  • Интеграция с существующими системами управления изменениями и другими смежными системами. Интеграция с системой управления изменениями, управления требованиями и т.д. обеспечивает возможность понять для чего были написаны какие строки исходного кода, сколько и что было добавлено и изменено при реализации конкретных требования или задачи. Готовые интеграции присущи в основном коммерческим системам, ограничение только в том, что интегрированы они только с системами того же производителя. Для бесплатных систем интеграции обычно не поставляются.
  • Расширяемость системы. Возможность собственной разработки интеграции с системами, если необходимая отсутствует. Открытое API позволяет написать свои методы взаимодействия со смежными системами или реализовать какие-то дополнительные функции, которые будут полезны в разработке.
  • Командная строка. Не самая главная, но полезная функция. Использование командной строки позволяет автоматизировать некоторые рутинные процессы, например, связанные со сборкой определенной версии системы.

Checkin/chekout

Основные функции любой версионной системы (Check in/chek out), описывать которые большой необходимости нет. С этими функциями знаком каждый разработчик, который уже имел опыт общения с «версионниками»:

  • Chek out – это изъять на редактирование файл. При этом TFS дает возможность следующих операций при редактировании, которые позволяют избежать конфликтных ситуаций при работе над одним файлом нескольких разработчиков:
    • Эксклюзивное извлечение, т.е. файл может редактировать только тот пользователь, который первый его взял на редактирование;
    • Извлечение только для редактирования, т.е. когда файл могут редактировать несколько разработчиков, но изменения они могут регистрировать только в том случае, если предыдущий до него разработчик зарегистрировал свои. При этом используется проверка на возможные конфликты между внесенными изменениями.
  • Check in – вернуть/зарегистрировать сделанные с файлом или группой файлов изменения.

Рисунок 1. Взятие на редактирование

Аннотирование

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

Рисунок 2. Аннотирование кода

Отложить

Еще одна полезная функция, которая означает «отложить текущие изменения». Эта функция полезна в следующих случаях:

  • Если пришли новые более важные задачи, а уже выполнено много изменений для текущей работы. И получается, что и откатить некуда и зарегистрировать изменения еще рано. Для того, чтоб не копировать в какие-то временные папочки на локальном диске текущие файлы, которые иногда имеют свойства пропадать, в TFS есть функция «отложить», которая позволяет сохранить все сделанные изменения на сервере без их регистрации в основном потоке разработки. После того как срочные работы будут выполнены, всегда можно вернуться к отложенным изменениям и доделать свою работу.
  • Если есть необходимость передать код на рецензирование. Разработчик может выполнить операцию «отложить» для своих изменений и дать необходимую информацию рецензенту. Рецензент может найти эти отложенные изменения и «подгрузить» их к себе в рабочее пространство. После того, как проверка кода закончена, свое рабочее пространство рецензент может вернуть в исходное состояние, т.е. до того как он начал рецензирование.

Рисунок 3. Отложить

Ветвление

Говорить, почему использование веток полезно, наверно, лишнее. Используют различные подходы в использование веток:

  • По функционалу. Для продукта создается основной поток разработки, в котором будет храниться готовый продукт. Для каждой функциональной возможности создается отдельная ветка. Когда функционал реализован и оттестирован, все изменения переносятся в основной поток.
  • По группам разработки. Для каждой группы разработки создается отдельный поток и используется отдельный поток, в котором будет использоваться как основной и с ним будут синхронизироваться все группы. Такой подход полезен, когда в организации большое количество разработчиков или используется географически разделенная разработка.
  • По заказчикам. Если в организации есть продукт, который поставляется нескольким заказчикам, и для каждого заказчика формируются отдельные уникальные функциональные возможности, то можно использовать для отдельного заказчика отдельную ветвь.
  • И многое другое. С различными видами ветвления можно познакомиться тут: Microsoft Team Foundation Server Branching Guidance.

Ветвление приобрело новые возможности в TFS 2010. Эти возможности связаны с визуализацией иерархии потоков разработки (см. Рисунок 4).

Рисунок 4. Иерархия веток

Кроме общей визуализации теперь доступна визуализация направления изменений между потоками разработки. Такой визуализатор позволяет сделать следующее:

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

Рисунок 5. Просмотр истории изменений

Рисунок 6. Направление изменений

Разрешение конфликтов

Когда возникают конфликтные ситуации?

  1. Изменение одного файла. При изменении двумя разработчиками одного и того же файла необходимо слияние их результатов работы.
  2. Возврат отложенных изменений. После того как разработчик делал операцию «отложить» для того, чтоб выполнить какие-то другие задачи, он через какое-то время возвращает выполненные им ранее изменения. Сделав возврат, он фактически возвращается к предыдущему состоянию своей разработки и продолжает незаконченную работу. И понятно, что то что он сделает для продолжения отложенной работы не должно конфликтовать с тем, что было сделано ранее.
  3. Слияние потоков разработки. Когда необходимо объединить изменения двух веток разработки, то конечно также будут возникать конфликты.

Большинство всех конфликтных ситуаций TFS попытается решить автоматически, но это невозможно во всех случаях. Поэтому в состав TFS включена утилита, которая позволяет решить конфликты в ручном режиме.

Рисунок 7.Список конфликтов

Рисунок 8. Ручное слияние

Дополнительно

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

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