Очень часто мне приходится слышать, что система контроля версий от Microsoft это некий костыль, сделанный на скорую руку. Я постараюсь, если не опровергнуть это, то показать, что со своими задачами эта система справляется. И если даже это и костыль, то очень качественный, цветной, функциональный, легкий и понятный в использовании.
Введение
Начну с того, что мы имели еще 5 лет назад: У нас стояла, и до сих пор стоит отличная, на мой взгляд, система контроля версий IBM Rational ClearCase, к ней в придачу также имеется и система управления изменениями и раздачи задач IBM Rational ClearQuest. До определенного момента, пока вся разработка велась исключительно на С++, этого было достаточно. Правда была одна небольшая проблема, система отлично интегрировалась во все продукты разработки, кроме Microsoft. Не знаю, было ли это связано с негласной войной между IBM и Microsoft, но система работала крайне нестабильно с Visual Studio 2005, часто неверно отображала состояние файлов, Visual Studio постоянно падала, при включении нужных нам функций. Кроме того, для доступа к системе использовался свой протокол, поэтому в нашей компании, доступ к системе могли получить только пользователи, находившиеся в домене компании, что автоматически не давало возможность заходить в систему с личного ноутбука. Конечно, со временем почти все эти недочеты были устранены, но на тот момент дело обстояло именно так.
Это и послужило причиной поиска новой системы, после не долгих поисков, мы приняли решение попробовать TFS 2005. Собственно на нем, мы, можно сказать, учились работать, и изучали новую для нас систему. Проработали мы на ней не долго, около 2 лет и сразу решили попробовать TFS2010. Про эту систему я и хочу немного рассказать, и начну с самой основной, по моему мнению части – системы контроля версий.
Как я уже говорил, работали мы всю жизнь на ClearCase с настройкой UCM и привыкли делать все в соответствии с процессом UCM. Одним из основных действий в этом процессе являлись операции Deliver (передача изменений от разработчика) и Rebase (получение изменений). Выглядит это на бумаге очень просто, в своей ветке разработчик делает изменения, и когда закончил работу, кидает (в терминах TFS делает Merge) их в ветку интеграции, соответственно, если разработчик хочет получить изменения то он должен сделать Rebase (опять таки сделать Merge в ветку разработчика), см Рисунок 1.
Рисунок 1 — Deliver и Rebase операции
На деле же это выглядит немного запутанно, см. Рисунок 2, но в любом случае все это не очень сложно и, в конце концов, даже начинаешь думать, что по-другому быть и не может.
Рисунок 2 — Дерево операций в ClearCase
И так, нам требовалось средство, которое позволит нам работать, следуя точно такому же процессу. Попробуем сделать все тоже самое с TFS2010.
Создание веток
Для начала нужно создать ветки. Нам необходима Интеграционная ветка, которая позволит хранить только релизы, которые идут пользователям, ветка, которую мы называем сайтовой, для обмена изменениями между разработчиками, и собственно ветка разработчика, в которой разработчик делает свои задачи.
Для этого, сделаем тестовый проект в TFS2010 и подключимся к нему, см Рисунок 3.
Рисунок 3 — Подключение к тестовому проекту
Теперь откроем Source Control Explorer нажав на Source Control проекта в Team Explorer, см Рисунок 4 и добавим в проект папку Project-Integration, эта папка будет являться для нас базовой для хранения кода Релизов, собственно, она будет являться Веткой интеграции, после её создания и добавления по контроль версий, сразу преобразуем её в ветку, см Рисунок 5 и Рисунок 6.
Рисунок 4 — Вызов Source Control Explorer
Рисунок 5 — Cоздание ветки интеграции
Рисунок 6 — Cоздание ветки интеграции
Теперь надо создать сайтовую ветку, которая будет являться местом, через которое разработчики будут обмениваться кодом. Эта ветка должна ответвляться от нашей созданной интеграционной ветки, см. Рисунок 7, и мы будет создавать ветку от неё, Рисунок 8.
Рисунок 7 — Дерево веток
Рисунок 8 — Создание сайтовой ветки
Ну и наконец, нам необходимо сделать ветку разработчика по тому же самому алгоритму, только ветвиться мы уже будет от сайтовой ветки. Сделаем две ветки для двух разработчикво см Рисунок 9.
Рисунок 9 — Ветка разработчика
Теперь мы имеем красивую древовидную структуру, которая в точности соответствует той, что мы использовали в ClearCase UCM.
Вид такой древовидной структуры веток не имеет ничего нового, это обычная практика. Она позволяет отделить временные действия разработчиков от законченных. Разработчик выполняет все свои задачи в своей ветке, не изменяя тем самым основной код, который находится на сайтовой ветке, и только после завершения работы, он скидывает хороший, оттестированный код в сайтовую ветку. Тем самым, мы всегда будем уверены, что в сайтовой ветке находится рабочий код.
Вы также можете создать ответвление от ветки разработчика, если одновременно работаете над несколькими задачами, например, исправление бага и собственно реализация какой-то задачи, и сливать изменения в свою ветку разработчика, по мере необходимости.
Сайтовая ветка может быть также использована и при удаленной разработке, т.е., например одна команда находится на Урале, другая в Москве, и каждая команда реализуют некоторую законченную функциональность в проекте, разработчики, находящиеся на Урале скидывают свой код в свою сайтовую ветку, Московская команда в свою. После того, как команды завершили работать над своей функциональностью, и все изменения лежат в сайтовых ветках, они могут слить все в единую интеграционную ветку.
Есть одна тонкость при работе с российскими разработчиками — они не отличаются особой культурой разработки, и могут вносить изменения в код в любое время, в любую ветку и по любой прихоти. Это часто приводило к тому, что даже такая строгая структура веток не защищала от того, что код в сайтовой ветке получался нерабочий, поэтому следующим нашим шагом будет настройка прав доступа к веткам, и запрещения некоторых действий, дабы код всегда был качественным. Но об этом в следующий раз…
Полезные ссылки:
Командная разработка с использованием Visual Studio Team Foundation Server: Справочник