Стратегическое ветвление кода

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

Team Foundation предоставляет гибкую и надежную систему управления версиями. Team Foundation (подсистема контроля версий) можно использовать для управления различными версиями в процессе разработки исходного кода, документов, рабочих элементов и другой важной информации, над которой работает команда. Дополнительные сведения об управлении версиями в Visual Studio Team Foundation Server см. в разделе Использование управления версиями.

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

При работе с системой управления версиями необходимо тщательно обдумать настройку структуры ветвления. Для создания ветви можно использовать зеркальное отображение файла с исходным кодом. После этого можно менять ветвь, не меняя сходного кода. Например, как показано в структуре ветвей на следующем рисунке, ветвь MAIN содержит полностью реализованные функциональные возможности, прошедшие интеграционное тестирование, а ветвь DEVELOPMENT содержит код в процессе разработки. После завершения реализации новых функциональных возможностей в ветви DEVELOPMENT, которые готовы к прохождению интеграционных тестов, можно перевести код из ветви DEVELOPMENT в ветвь MAIN. Такой процесс называется обратной интеграцией. Слияние кода из ветви MAIN с кодом из ветви DEVELOPMENT называется прямой интеграцией.

Дополнительные сведения о создании и слиянии ветвей кода см. на странице Team Foundation Server Branching Guide 2.0 веб-сайта CodePlex.

Процесс ветвления и слияния основан на следующих общих принципах.

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

2. Ветвь MAIN должна содержать код, прошедший тесты интеграции и всегда готовый к выпуску.

3. Ветвь DEVELOPMENT (рабочая) постоянно изменяется, потому что участники команды периодически возвращают в нее изменения.

4. Метки представляют собой снимки файлов в ветви в определенный момент времени.

   Дополнительные сведения см. в разделе Использование меток для создания снимков файлов.

Team Foundation Build позволяет выбрать несколько типов построений ветвей: ручное, непрерывное, с условным возвратом, последовательное и запланированное. Для ветви MAIN рекомендуется использовать тип построения с условным возвратом. Это значит, что перед фиксацией обратной интеграции нужно убедиться, что ветвь DEVELOPMENT удовлетворяет всем требованиям к ветви MAIN. Ветвь DEVELOPMENT должна выполняться в непрерывном режиме построения, поскольку команда должна как можно раньше получать сведения о выполнении возврата, влияющего на ветвь DEVELOPMENT.

Как часто команда должна выполнять обратную и прямую интеграцию?

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

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

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

Как команда управляет различными исходными кодами, реализующими разные пользовательские описания функциональности?

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

Когда команде следует добавлять новую ветвь?

Новые ветви следует создавать в следующих ситуациях.

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

• Когда код требует применения другой политики ветвления. При создании новой ветви с новой политикой можно добавить в проект стратегическое значение.

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

Не рекомендуется создавать ветвление для каждого пользовательского описания функциональности, поскольку это обуславливает высокие затраты на интеграцию. Хотя Team Foundation Server 2010 делает процесс ветвления простым, общее управление большим числом ветвей может потребовать значительных ресурсов.

Как команда управляет выпусками с почки зрения системы управления версиями?

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

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

При создании ветви для выпуска следует создавать ответвление от ветви MAIN, как наиболее стабильной. Создание ветви для выпуска путем ответвления от рабочей ветви создаст проблемы с интегрированием, поскольку рабочие ветви не являются гарантированно стабильными.