Опыт использования TFS 2010: (Система контроля.Ветки.Создание)

image
Очень часто мне приходится слышать, что система контроля версий от 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.
image
image
Рисунок 1 — Deliver и Rebase операции

На деле же это выглядит немного запутанно, см. Рисунок 2, но в любом случае все это не очень сложно и, в конце концов, даже начинаешь думать, что по-другому быть и не может.
image
Рисунок 2 — Дерево операций в ClearCase

И так, нам требовалось средство, которое позволит нам работать, следуя точно такому же процессу. Попробуем сделать все тоже самое с TFS2010.

Создание веток

Для начала нужно создать ветки. Нам необходима Интеграционная ветка, которая позволит хранить только релизы, которые идут пользователям, ветка, которую мы называем сайтовой, для обмена изменениями между разработчиками, и собственно ветка разработчика, в которой разработчик делает свои задачи.
Для этого, сделаем тестовый проект в TFS2010 и подключимся к нему, см Рисунок 3.
image
Рисунок 3 — Подключение к тестовому проекту

Теперь откроем Source Control Explorer нажав на Source Control проекта в Team Explorer, см Рисунок 4 и добавим в проект папку Project-Integration, эта папка будет являться для нас базовой для хранения кода Релизов, собственно, она будет являться Веткой интеграции, после её создания и добавления по контроль версий, сразу преобразуем её в ветку, см Рисунок 5 и Рисунок 6.
image
Рисунок 4 — Вызов Source Control Explorer

image
Рисунок 5 — Cоздание ветки интеграции

image
Рисунок 6 — Cоздание ветки интеграции

Теперь надо создать сайтовую ветку, которая будет являться местом, через которое разработчики будут обмениваться кодом. Эта ветка должна ответвляться от нашей созданной интеграционной ветки, см. Рисунок 7, и мы будет создавать ветку от неё, Рисунок 8.
image
Рисунок 7 — Дерево веток

image
Рисунок 8 — Создание сайтовой ветки

Ну и наконец, нам необходимо сделать ветку разработчика по тому же самому алгоритму, только ветвиться мы уже будет от сайтовой ветки. Сделаем две ветки для двух разработчикво см Рисунок 9.
image
Рисунок 9 — Ветка разработчика

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

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

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

Полезные ссылки:
Командная разработка с использованием Visual Studio Team Foundation Server: Справочник
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 46

    +5
    На втором рисунке все же граф, а не дерево.

    А по делу: самого интересного тут и нет. Ну создал кучу веток, ну красиво их подписал — но это только вершина айсберга. В работе-то оно все как? Как мучаются разработчики с baseless-мерджами? Как конфликты разрешают рудиментарными ТФС-ными средствами?
      –2
      Спасибо за совет,
      Я попытаюсь дальше эту тему раскрыть, только начала писать…
      Дальше напишу про права, политику и собственно и от лица разработчика сделаем код и попробуем его смерджить, черновик статьи сделал, в ближайшее время выложу, надо немного подредактировать.
      +1
      И это в тот момент, когда всё прогрессивное человечество работает с git'ом, а отдельные ретрограды с hg.

      Откуда вы это выкопали? Закопайте обратно.
        –1
        Основной минус таких систем, как и SVN — это бесплатность. Они просто запрещены к использованию в большинстве корпораций, поэтому все реальное человечество работает на платных системах типа TFS и ClearCase, хотя я конечно же ничего против не имею против бесплатных систем, и даже за их использование, например, Тортила мне нравиться, вот только она у нас запрещена.
          0
          эээ, а что плохого в бесплатных системах? Не совсем понятно, честно говоря.
            0
            Ну скажем так, большим компаниям, типа Моторолы, Интел, Сименс и так далее, нужна нормальная сервисная поддержка по всему миру. Если что случиться с бесплатной системой контроля, например в подразделениями во Вьетнаме, к кому обращаться за помошью.
            Именно поэтому в Мотороле, например, запрещено… да и у нас тоже.
              0
              очевидно к любому мейнтейнеру бесплатного проекта. в конце концов можете нанять вменяемого программиста, посадить его на пару месяцев в код «бесплатной системы контроля версий» и получите вменяемую поддержку по всему миру с гораздо большей отзывчивостью и меньшими затратами.
                0
                Там где нужно, моторолла нормально использует git & gerrit и не жужит. Инсайдерская информация, да :)
              +2
              Оригинальная точка зрения о реальном человечестве…
              Граф изменений по сравнению с DVCS страшен.
              Запрещение к использованию SVN — совершенно непонятны причины.
              И совсем непонятно, чем же провинились git, mercurial и bazaar…
                +2
                Покажите пальцем компанию, где запрещено пользоваться SVN?
                  +5
                  У нас за svn будут больно бить по голове учебником по git'у :)
                    0
                    немного кардинально, я бы не сказал, что нужно всегда использовать самое свежее и самое модное если инструменты покрывают нужды
                      –4
                      Если человек лично свои файлы хранит в svn, то это его личные половые проблемы. У нас даже два человека в отделе разработки винды используют, хоть и стесняются этого.

                      Если же он хочет svn использовать для взаимодействия с другими сотрудниками — то бить git'ом по голове, пока не прозреет.
                        +2
                        Да, что вы говорите, hg уже моветон, git единый нам озаряет путь :) И господи, они используют винду, я единственны сотрудник который использовал винду в офисе для разработки на PHP почему то не умер от стыда.
                  0
                  Видимо, мы находимся в разных мирах.

                  Кстати, что использует гугль у себя? А facebook? А redhat? Неужели платные системы?

                  Или вы про старые сдыхающие конторы типа Axapa и Navision, которые ждут-недождутся, пока их кто-нибудь не купит?
                    –1
                    Я не знаю, что использует Гугль, думаю, что они используют свои системы, которые сами и написали, также наверняка поступает и Microsoft…

                    Точно знаю, что Моторола, да и вообще многие американские конторы используют ClearCase.
                      +2
                      Майкрософт — разумеется. Эти чудики даже сайты на IIS держат, вместо haproxy.

                      А вот насчёт facebook/google — позвольте не согласиться. Тот же flashcache опубликован именно на гитхабе — видимо, потому что у людей был гит (врят ли они его конвертили для публикации, проще было бы просто тарбол выложить).
                        –1
                        Возможно, но опять же я не утверждаю что все компании :) Многие, возможно большинство, на этом построено и их развитие.
                        Сделал один раз, у тебя купили, купили поддержку, и платят каждый год, за то, чтобы у проблем не было, а возможно за 10 лет ничего и не случиться.
                        Это как страховка… купил, а в аварию не попал.
                        А ты на эти деньги живешь, обновляешь, всякие фичи каждые два года выпускаешь, все нормально, все довольны :)
                          +1
                          Вы всё это так говорите, как будто предлагаемые решения лучше гита. Лично я могу сказать, что багтрекер у нас в конторе проприентарный. Потому что другие «не пошли».

                          А вот гит — извините, never knows best. Основной же вопрос не что юзает контора, у которой бухгалтерия с 1975 на коболе написана, а что использовать. И ставить какое-то левое проприентарное дерьмо вместо адекватной распределённой vcs — это бред. Особенно в 2011.
                            0
                            Нет, я не говорю, что это решение лучше, я лишь хочу показать, что оно простое в использовании, свои задачи решает, и имеет свои плюсы, как впрочем и минусы.
                            Идеальной системы нет и не будет.
                            В принципе меня устраивал и ClearCase, но просто не дружит IBM с Microsoft, отсюда, куча проблем была с обоими…
                              +1
                              Оно проще гита? Извините, мы, видимо, мыслим разными категориями. Убогая графическая поделка, в которой не работает ничего из coreutils не может быть проще, чем шелловая. Потому что если мне какой-то функции в гите не хватает, она появляется простым pipe в другие утилиты. А в вашем случае что делать?

                              Допустим, мне нужно посмотреть все коммиты, которые были между коммитами aaaaaaa и bbbbbbb, в которых был затронут файл foobar.c, авторства Foo J. Bar и с словом baz в описании.

                              Ваше решение?
                                0
                                Он возможно и не проще, потому что я не спец по гиту.
                                В данном случае, если я вас правильно понял, то это можно сделать двумя путями в TFS, по нашему процессу.
                                1. Встать на ветку разработчика Foo J. Bar, нажать на файл foobar.c, и получить весь список changesetов. Берем чендсеты с аааа и смотрим до вввв… см картинку, там поле юзер скрыто… буква S. (это я он же lamerok), потому что к сожалению пользователя Foo J. Bar нету.
                                2. Тоже самое только с метками
                                Единственно проблема с описание, хотя оно есть, но фильтра по нему нет, хотя можно и отсорторовать. Но опять, же все зависит от того, как у вас построен процесс, вы его строите, так, чтобы не возникало желаний делать такие запросы :) Но это ИМХО.
                                image

                                  +1
                                  Нету «ветки разработчика». Есть общее дерево коммитов, среди которых есть коммиты человека.

                                  А «единственная проблема» — это то, про что я говорю. Все эти гуёвые перделки тут же сливаются, как только речь заходит о «нам бы тут подобие grep, awk и ещё чуть-чуть sed».
                      0
                      Гугл вроде использует perforce, платную, 740$ за пользователя. Вместе с ними ее используют JetBrains, HP, Samsung, HTC, Cisco, nVidia, Blizzard, Sony, да дофига, кто еще.

                      На самом деле, большие репозитории гит (а возможно и другие DVCS) так себе обрабатывает. Под большими имеются в виду размером в несколько гигабайт. А на относительно небольших проектах он более чем удобен.
                        0
                        Ядро линукса — достаточно большой проект?
                          0
                          Репозиторий ядра линукса занимает вроде порядка 300М, а после вызова git-prune вообще до сотни ужимается — так что не очень большой (я там выше про гигабайты писал).
                            0
                            Ну, я не думаю, что есть отдельные репозитории существенно большего размера.
                              0
                              Да ладно. В репо ядра линукса только исходники, т.е. текстовые файлы, хорошо жмущиеся zip'ом.

                              Графических ресурсов там, например, нет. Зависимостей в бинарных файлах — тоже. У меня сейчас пруненый репо занимает полсотни метров (всего в два раза меньше ядра линукс, ага), при том, что я его разрабатываю существенно меньше по времени и существенно меньшим количеством человек — так что я вполне могу представить проект с репо в несколько гигов.

                              Да, про плюсы гита я в курсе, сам его использую, и в большинстве случаев это VCS №1. Но в то же время, я представляю себе его недостатки, и ситуации, когда его применять не стоит.
                      +1
                      GPL не запрещает продавать программы. Вы купите у меня git, скажем, за 1000$? Тогда он уже перестанет быть для вас бесплатной системой и вы, наконец, сможете им пользоваться.
                        +3
                        Крупные Корпорации не используют Нищебродский Софт по $1k за копию. Крупные Корпорации используют только ПО с лицензированием от $30k за первый год и от $20k за каждый последующий, умножающийся на 4% в год (инфляция) за каждое ядро и каждые 4Гб используемой памяти?
                          –1
                          Все верно… так и выходит. Из-за одного антивируса всем компьютеры поменяли на XEONы. Трудно понять логику Крупных корпораций, но скорее всего, она заключается в том, что лучше заплатить побольше денег и потом иметь меньше гемора и хорошую поддержку.
                          Только так могу объяснить…
                          Для малых и средних, все верно — хорошие, проверенные временем бесплатные системы.
                            +1
                            Вопрос про vcs у гугля и фейсбука вы проигнорировали или не заметили?
                    0
                    Автор действительно только «прошелся по верхам». Самого интересного не поведал :)
                    У меня есть более года плотного общения с TFS 2010 (установка, администрирование, поддержка команд разработки в плане TFS, трекинг багов/тасков, континиус-интегэйшин и прочее). У TFS есть плюсы, есть и минусы. Если у вас есть вопросы, задавайте, попробую ответить.
                      0
                      мы работаем с TFS 2010 больше года. До этого я работал с SVN Tortoise — земля и небо. Жаль, что TFS платный, юзал бы его в домашних условиях.

                      1. Если я начинаю изменять файл, то получаю новую версию. Если файл уже был кем-то изменён, пока я «чесался», то TFS скачает прежде новую версию, чем даст мне возможность править. Так я избегаю большую часть серьезных конфликтов при дальнейшем мердже. Своеобразный Lazy Load. И это всё помимо регулярного получения последних версий и коммитов. При этом нет такого, что если кто-то залил свои изменения, то все они прилетели ко всем остальным разработчикам и проекты перестают собираться у всех.

                      2. Обычные конфликты в 90% случаев разрешается сами. Если нужно что-то подправить, то WinMerge подсвечивает лучше стандартного Tfs редактора. Но и тот отлично справляется.

                      3. Contineus Integeration сразу присылает сообщение на мыло разрабу, если он, нерадивый, залил код, который не собирается или падают тесты. Сообщения и билды весьма гибко настраиваются. Можно даже запретить заливать новый код, если тесты не проходят.

                      4. TFS ещё и рулит тасками и багами. Таски назначает лидре или разраб. Баги через таск-систему назначает тестировщик. Можно выполнить, вернуть, отказаться, перенаправить на другого, разделить на подзадачи (ветвление дерева), проставить различные статусы, комментарии с датой и временем, прикрепить файлы (например доки или дамп базы). Менеджеры по таскам строят свои графики проекта (их там очень-очень много)

                      5. Каждый коммит можно (а у нас и нужно) прикреплять к отдельному таску. Так видно какая задача какие изменения вызвала. И какие коммиты были привязаны к той или иной задаче. А не искать всё только по комментариям.

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

                      7. Можно «зашелвить» задачу — «положить изменения на полку», т.е. создать отдельную «ветку» только для своих локальных изменений и расшаривать их между несколькими разрабами не заливая все изменения в основную ветку. Таким образом не нужно больше плодить кучи веток. У нас их, например 2: для тестировщиков (более стабильная) и для разработчиков. Работает человек 40-50 всего. Проблемы с упавшими билдами возникали раза 2-3 в неделю(когда было можно заливать такой код), но решались быстро. ДА и всегда можно откатиться на предыдущую версию.

                      PS на одной конференции рассказывал некий git — евангелист как круто работать с гитом и гитхабом. Слушая его сравнивал с TFS. Помню, что по ощущениям я бы не стал менять систему контроля версий на git. Не знаю, может быть там и есть всё, что я здесь описал для TFS, но он об этом не рассказал.

                      8. Все файлы хранятся на компе. скачиваются 1 раз и потом изменённые только перезаписываются.
                        +1
                        Все, кроме 1, прекрасно работает в меркуриале. Бесплатно, быстро, не требуя связи с центром.
                          0
                          1. Не его собачье дело, что и в какой версии я буду менять.

                          2. Не есть достижение TFS; в современных VCS'ах все именно так. WinMerge хорош, но это не TFS, встроенные средства которого — обнять и плакать.

                          3. CI это хорошо, но там типичный Enterprise Bloatware. И как, позвольте узнать, будете тесты исправлять, если запретите новый код коммитить?

                          4, 5. Не бином Ньютона.

                          6, 7. Об этом упоминать вообще стыдно.
                            +1
                            1. Все еще забавнее — если он мне скачает только 1 файл, а не сделает update всей рабочей копии, то у меня в 99% случаев будет что-то сломано и хорошо, если только сборка.
                              –1
                              и это есть правильно, т.к. после этого придётся скачать все остальные модули, зависимые от данного файла. Как правило, это 1 сборка.
                              А иначе, если вы будете менять уже неактуальную старую версию, добавлять в неё свою логику, то когда вы начнёте её мержить, то врагу больше такого не пожелаете.

                                +1
                                Это не есть правильно, потому что в нормальных VCS версию имеет не файл, а репозитарий, что абсолютно логично для исходных тесктов программ, автоматически обеспечивая их согласованность между собой.
                                Т.е. вместо того, чтобы спокойно сделать update рабочей копии и получить новую версию или не делать update, взяв merge на себя, мне автоматически ломают рабочую копию, обновить которую до согласованного состояния я должен уже руками?
                            0
                            TFS-ом пользуемся уже более 2 лет. Готов согласится практически со всем. Действительно удобная система. Хотя и не лишенная некоторых недостатков. Как всегда от крупных вендоров, чтобы насладиться всеми плюшками приходится вкладываться в дополнительное ПО.
                            Так, если хочешь полноценную систему отчетов, то будь добр раззорись на нормальный SQL сервер с поддержкой репортинга (можно поставить на бесплатный SQL Express, но отчетам — гуд бай). Тоже самое и с SharePoint, можно поставить на бесплатный Foundation (и потерять часть функционала), а можно на SharePoint Server и получить парочку дополнительных вкусностей.
                              +1
                              Чем эта система удобнее того же меркуриала?
                                0
                                Я Mercutial не пользовался, но судя по информации на сайте, это система контроля версий. TFS — это система управления проектами. Т.е. система контроля версий и плюс много всего того, что позволяет сделать разработку проще. Классический сценарий. Нарисовали в Visual Studio диаграмму Use Case (UML). К каждому прецеденту добавили Product Backlog Item. Затем разбили его на Tasks, которые запланировали по времени. Разработчик берет задачу, решает, делает комит. Как только все задачи решены и функционал проверен, Product Backlog Item закрывается. Все эти активности можно отслеживать. Причем когда человек начинает работать по задаче, он может пройти по всем этим деревьям до диаграмм и выяснить глобальные вещи. TeamLead может в обратную сторону проверить открыть диаграмму и идя вниз по дереву посмотреть, как идут работы по каждой UserStory. Ну и много всего еще.
                                  +1
                                  Ставим бесплатный redmine — имеем все то же самое, кроме фазы с UML (интеграция с мерком там из коробки).
                                  Итак — есть интеграция с UML. Что еще?
                                    0
                                    Еще раз, мне сложно судить, не имея опыта работы с системами, которые вы упоминаете. Я допускаю, что все то, что есть в платном TFS, есть в бесплатных версиях от других разработчиков. И это просто замечательно.
                                    Мы используем TFS в связи с тем, что у нас разработка ведется на Silverlight или WPF. Я знаю только одну версию инструментальной среды разработки, которая поддерживает эти технологии в полном объеме, на уровне последнего framework. Это Visual Studio 2010. А дальше все просто. Единственный программный продукт, который обеспечивает поддержку всего цикла разработки от проектирования, до тестирования и развертывания, это TFS. Поэтому мне некуда деваться с подводной лодки. Если есть возможность получить все то, что мне дает связка VS 2010 + TFS 2010 в другой компоновке, то я бы с удовольствием такой вариант рассмотрел. Но! VS 2010 пока является обязательным условием. Поэтому, если знаете, где можно почитать о том, как интегрировать VS 2010 + <продукт нейм>, чтобы все работы архитектор, проектировщик баз данных, программист, тестировщик, специалист по развертыванию, делали в VS и все это адекватно сохранялось в <продукт нейм>, отпишитесь здесь, или на почту.
                                      0
                                      Спасибо за полный ответ. Нужной глубины интеграции со студией у сторонних бесплатных продуктов, естественно, нет и это реально киллер-фича.
                              +1
                              вот же поведение школоты на хабре.
                              называется — «Поделись своим опытом и получи минус в карму от очередного обиженного жизнью евангелиста»
                              Мне кармы не жалко, но грустно смотреть на таких.

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

                            Самое читаемое