Пару слов об интеграции в TFS системы управления дефектами с системой управления версиями

    Введение.



    Продолжаю удивляться делиться опытом перехода из SVN на TFS (или как правильно подметили Team Foundation Version Control (TFVC)).
    В предыдущем посте был описан опыт чисто системы управления версиями.
    В этом посте я хотел бы поделиться маленьким (но важным) сценарием использования интеграции системы «контроля версиями» с системой «управления дефектами» (или как это называется Work Item Tracking).



    Один из наиболее частых (у меня, и как мне представляется у других) сценариев интеграции систем «контроля версий» и «управления дефектами» это привязка к «дефекту» релевантных изменений в «контроле версий». Часто так получается, что один «дефект» (или задача) решается с помощью нескольких изменений (ревизий).
    Кажется, что этот сценарий абсолютно не поддерживается SVN и отлично из коробки поддерживается TFS, по крайней мере так представляют дело продавцы от Microsoft.

    В реальности мы используем в SVN простой прием, который позволяет несколько вещей:
    — прежде всего можно связать каждую ревизию SVN с некоторым количеством «дефектов» TFS;
    — и наоборот, кажый дефект можно связать с некоторым количеством ревизий;
    — далее в окне истории можно видеть колонку с номерами TFS дефектов для каждой ревизии;
    — понятно, что по клику открывается веб интерфейс дефекта;
    — естественно история редактируется (т.е. дефекты можно менять).

    Программист когда выполняет коммит, может указать номер дефекта:
    image

    История показывает колонку с номерами дефектов:
    image

    История, реализованная TortoiseSVN, обеспечивает очень легкий способ нахождения всех ревизий, относящихся к конкретному «дефекту»: просто пишешь номер «дефекта» в фильтре истории и получаешь сразу все изменения данного дефекта. Отмечая отфильтрованные ревизии можно видеть сразу все файлы данных ревизий.

    Не из коробки? Ну да. Может быть кустарно выглядит? Может быть.

    Теперь посмотрим какой уровень интеграции я получил на TFS (контроль версий и управление дефектами). Мне известно 3 способа работы с TFS (исключая командную строку): из Windows explorer, из Visual Studio и через веб-интерфейс.

    Делаем «Check in» из Windows Explorer (Power Tools 2013): Таб «Work Items» позволяет искать «дефект» по номеру только в текущем запросе. Если по какой-то причине нет запроса — нет коммита. Так что, пржде чем чекинить убедись в наличии трапа запроса, по которому можно найти «дефект».

    Делаем «Check in» из Visual Studio: Студия позволяет добавить номер «дефекта» по запросу и собственно номеру.

    Веб-интерфейс для данного сценария не релевантен.

    Теперь как искать ревизии по номеру «дефекта»:
    Windows Explorer (Power Tools 2013) не имеет поиска, чтобы узнать какой «дефект» привязан к ревизии, нужно выбрать ревизию и переключить таб. Таким образом найти все ревизии данного «дефекта» не представляется возможным.

    Студия так же не имеет поиска (ревизий по «дефекту»), но позволяет по «дефекту» (таб Links) узнать его ревизии. Теперь можно кликать по этим линкам, что бы увидеть какие файлы были изменены. Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).

    Веб-интерфейс конечно более цветаст и неплох для визуализации изменений одной ревизии, но все равно не походит для нескольких ревизий.

    Вывод:
    Power Tools выглядит убого для данного сценария. Студия выигрывает у TortioseSVN за счет запросов при чекине.
    Поиск и визуализация изменений (особенно когда есть несколько ревизий) существенно лучше поддерживается в TortioseSVN.
    Немного (или много) раздражает смена инструментов (Power Tools, Studio и web), так нет такого, который работает лучше остальных.

    Замечания:
    — Извините за терминологию: иногда сбиваюсь.
    — Согласен, что я «не разобрался в TFS прежде чем использовать». Помогите разобраться.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 153

      0
      1. Это не система управления дефектами. Потрудитесь открыть переводчик и перевести хотя-бы дословно Work Item. Ибо не хочется дальше даже читать, но я прочитал.
      2. Я так и не понял, чем вас не устраивает работа в VS с привязкой к рабочим элементам исходного кода, причем можно:
      2.1 Просто привязать (association)
      2.2 Привязать и совершить событие (resolve task, us и т.д.)
      После чего, просматривая WorkItems можно видеть все изменения. Более того, в Builds они тоже уйдут.
        +2
        Термин «Система управления дефектами» понятен и является подмножеством Work Item management. Если хотите улучшить мир, добавьте правильный термин тут и я им буду пользоваться.

        Я не нашел способа в TFS увидеть сразу список всех измененных файлов для дефекта. Студия требует перемещаться по каждой привязке (association).
        • UFO just landed and posted this here
            0
            Так «Система управления дефектами» это и есть «Багтрекер».
            • UFO just landed and posted this here
                0
                Вот только TFS больше и того, и другого.
                  0
                  Я не стал отвечать на данный вопрос. Достаточно открыть MSDN и прочитать, даже в русской версии, как правильно называется этот элемент.
                    0
                    Так напишите этот термин тут, и по крайней мере еще один человек его узнает.
                    Или по-русски он называется «система управлениями рабочими элементами»? Как то не совсем понятно о чем речь :(.
          0
          Немного (или много) раздражает смена инструментов (Power Tools, Studio и web), так нет такого, который работает лучше остальных.

          Для всего, что связано с кодом, лучше работает VS. Для планирования — web. Интеграция с Windows Explorer нужна только для edge-case-сценариев, в норме ей лучше не пользоваться.

          Студия позволяет добавить номер «дефекта» по запросу и собственно номеру.

          Еще вы совершенно упускаете My work (хотя он доступен только от Premium и выше).

          Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).

          Тривиально: из WI открываете all links, там будут все changeset, которые ассоциировали с этим WI. Дальше по двойному клику на чейнджсете вы получаете полный список всех изменений этого чейнджсета.
            0
            My work все же несколько иное. Я так и боюсь начать им пользоваться.
            Весь негатив автора вокруг того, что ему не нравится закладка all links, он хочет, чтобы у него все файлы были сразу одним списком, как SVN показывает в хистори.
            Я не нахожу ничего лучше, чем привести пример:
            — я хочу, чтобы как в KDE
            — постойте, мы же в windows
            — а я хочу, иначе, ваш продукт выбросить.
              0
              У меня есть привычный (и очень логичный) сценарий и я ищу как он решается в TFS: так вот он поддерживается очень плохо.
              Не нашел способа увидеть список всех изменений «дефекта».
              И при этом TFS позиционируется (продается) как ALM.

              Цель данного поста показать какие возникнут вопросы у тех, кто переходит с SVN на TFS с надеждой, что более опытные пользователи TFS покажут как им правильно пользоваться.
                0
                Логичность понятие весьма относительно. Я считаю себя достаточно опытным человеком, общающимся с ТФС уже больше 4 лет.
                От установки как есть, до настройки и конфигурации под «иные» требования. Но у меня никогда не возникало необходимости искать все файлы, которые прилинкованы к WI. И ранее, за 5 лет с SVN, не возникало. Что я делаю не так?
                А по теме: простого и удобного способа, лучше чем из All Links нет. Можно, конечно, написать свой запрос, в TFS все хранится в сиквеле, но стоимость и необходимость этого сомнительна, для меня, лично.
                  0
                  Ну, справедливости ради, мне вот очень не хватает в Version History колонки с номерами задач — у меня часто возникает необходимость понять, кто и зачем что-то чекинил, а делать это отдельно по каждому CS — муторно. Но это весьма специфический сценарий, связанный с аудитом работ в команде.
                    0
                    У меня это довольно частый сценарий. И TFS не поддерживает его :(.
                    Такое чувство, что TFS идет не от кода, а от WI (дефект, задача и т.п.), т.е. он более заточен не для программиста, а не понятно для кого. Поэтому и «продают» его не программистам, а более другим людям.
                      0
                      Вы путаетесь. TFS как раз идет от кода, но «от кода» — это «открыл код — сказал annotate — нажал в номер cs — посмотрел комментарии — нажал в wi — посмотрел описание». А то, что нужно мне — это не «от кода», а журнал аудита.
                        0
                        Если TFS идет от кода, то почему в истории нет колонки, которая позволяет увидеть номера WI?
                        Ведь это позволяет глядя историю кода открыть соответствующий WI.

                        TFS заставляет меня найти WI, и в его линках искать изменения в коде.
                          0
                          Ведь это позволяет глядя историю кода открыть соответствующий WI.

                          Зачем? У меня никогда не возникало такого сценария. У меня есть сценарий «мне надо понять, почему в этом месте кода написано такое», и для этого достаточен Annotate.

                          TFS заставляет меня найти WI, и в его линках искать изменения в коде.

                          Если вы, как вы говорите, идете от истории, то достаточно кликать на каждый CS и в его ассоциациях смотреть нужные WI.
                            0
                            едь это позволяет глядя историю кода открыть соответствующий WI.

                            Зачем? У меня никогда не возникало такого сценария. У меня есть сценарий «мне надо понять, почему в этом месте кода написано такое», и для этого достаточен Annotate.


                            Оба эти сценария у меня популярны.
                            Просто история позволяет быстро увидеть все-изменения и понять какие баги решаются этими изменения.

                            Если вы, как вы говорите, идете от истории, то достаточно кликать на каждый CS и в его ассоциациях смотреть нужные WI.


                            «достаточно кликать на каждый CS» — в этом то и дело! SVN позволяет не кликать на каждый, а видеть колонку со всеми номерами дефектов, далее фильтровать ревизии по номеру дефекта и видеть все файлы выбранных ревизий. Это сильно экономит время!
                              0
                              Просто история позволяет быстро увидеть все-изменения и понять какие баги решаются этими изменения.

                              Зачем?
                                0
                                Например:
                                Открываешь вечером историю, сразу видишь кто что сделал сегодня и быстро понимаешь какие баги чинились, какие файлы менялись. Далее, в зависимости от этой информации, изучаешь более конкретно те или иные ревизии.
                                  0
                                  Открываете, читаете комменты и получаете всю ту же информацию.

                                  Важно понять, что по таблице ассоциаций не видно, какие задачи были сделаны, только над какими велась работа.
                                    0
                                    Важно понять, что по таблице ассоциаций не видно, какие задачи были сделаны, только над какими велась работа.


                                    Согласен. Но прежде всего мне надо оценить в общем состоянии истории, а потом заняться конкретными дефектами или ревизиями.
                                      0
                                      Комменты рулят. Они намного информативнее номеров задач.
                                        0
                                        Согласен, а если пометить обязательность постановки и воспитать разработчиков — вообще милость.
                                          0
                                          Хорошие комментарии конечно же облегчают понимание.
                                          Но все-таки легче «заставить» писать хотя бы номер, чем нормальные комментарии.
                                            0
                                            Для читающего в номере пользы нет никакой, их невозможно держать в голове при постоянном потоке.
                                              0
                                              Конечно. Поэтому по номеру можно кликнуть и почитать WI.
                                              Не всегда меня интересует, что написано в WI, а более интересно сколько ревизий, есть ли тесты, какие части проекта затронуты.
                                                0
                                                Это надо делать по каждой задаче отдельно.

                                                А вообще, все, что вам нужно, легко реализуется собственным агентом, благо API у TFS — открытый.
                                                  0
                                                  Почему то никто не написал что-нибудь на уровне TortoiseSVN или я не заметил?
                                                    0
                                                    Потому что не нужно.
                                                      0
                                                      например, не нужно иметь аннотацию из Windows Explorer?
                                                      Почему?
                                                        0
                                                        Потому что основной инструмент для работы с кодом — это IDE. В основных IDE, на которые рассчитан TFS, аннотация встроена. Писать собственный визуализатор, да еще и с поддержкой всего того, что есть в студии — дорого.
                                                          0
                                                          С текущим состояним кода — да, Студия — это все (или почти все).
                                                          С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.

                                                          Я знаю людей, которые открывают отдельную студию только для TFS, а пишут код и дебагируют в другой студии. И я их понимаю, не хочу смешивать код (и дебагирование) с более другими задачами.
                                                            0
                                                            С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.

                                                            При работе с TFS — основной.
                                                              0
                                                              С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.

                                                              При работе с TFS — основной.


                                                              к сожалению ;(
                                                                0
                                                                Это изначальная идеология системы. Если она вам не нравится — просто не надо есть этот кактус.
                                                                  0
                                                                  Не надо. Кто же спорит.

                                                                  Просто я делюсь опытом, который может быть будет полезен тем, кто работает на SVN, но его окучивают «продавцы» от Microsoft.
                                                0
                                                И потом ходить по ним, открывая десятками на вкладках. Путаешься в конец. Мне кажется, в этом нет необходимости. Параллельно анализировать больше одной задачи нереально.
                                                  0
                                                  изучаешь только то, что интересно и по одному.
                          0
                          Уважаемый lair. Я проводил аудит постоянно и решил это тем, что при checkin разработчики должны были заполнить поля Comment и Check-In Notes. Понятно, что пришлось убеждать народ в необходимости этого дела -).

                          * Comment
                          Описание решенных задач, поставленных в JIRA, а также, возможно, не заведенных задач. Пример:
                          ARIJ-345 Прикрутить к Price интерфейс IComparable
                          Не видна часть позиций счета Rс резервами при добавлении в груз

                          Здесь важно иметь не только номера, но и текст задач.

                          * Детальное описание изменений – обязательное
                          Четкое и краткое описание изменений и их смысловая нагрузка.

                          * Изменения в структуре БД
                          Удаление/создание/изменения таблиц, View, хранимых процедур.

                          * Улучшения производительности
                          Описание улучшений в производительности системы, достигнутые при реализации данных изменений.

                          * Изменения, видимые пользователю
                          Кратко описываются изменения в пользовательском интерфейсе

                          * Замечания для группы тестирования
                          Советы группе тестирования о том, как тестировать внесенные изменения

                          * Замечания для группы документирования
                          Советы группе документирования о том, что должно быть изменено в пользовательской документации в связи с данными изменениями
                            0
                            Что у вас использовалось в качестве системы управления требованиями и задачами?
                              0
                              Требования — Confluence. Задачи — JIRA.
                                0
                                А в треде речь идет об использовании для этих целей TFS. В этом случае ваши требования несколько (будем честными, очень сильно) избыточны.
                                  0
                                  Вы сами писали, что вам этого не хватает, я лишь предложил универсальное решение.
                                  Кстати, я не считаю, что оно избыточно.

                                  Можно кликать по строкам истории и справа видеть Related Work Items. Правда, последние 6 checkin notes автоматом там не возникнут -).
                                    0
                                    Мне не хватает конкретных номеров WI, но копировать их в описание когда у TFS уже есть их хранение — нелепо. Аналогично, нет смысла описывать замечания для групп тестирования и документирования, они должны быть описаны в TFS в соответствующем WI.
                                      0
                                      Номер WI без темы бесполезен.
                                      нелепо

                                      Ну, ОК. Double-click на каждой строке вам в помощь. -)
                                      Кстати, у вас нет ни одного checkin без WI?

                                      А вообще, я сейчас вспомнил, что я делал аудит не по истории, а по оповещениям на checkin в почту. Это позволяло (1) видеть не только комментарий, но и checkin notes, (2) понимать, что прошло аудит, что нет (прочитано письмо — прошло), (3) сортировать, например, по людям.
                                        0
                                        >> Номер WI без темы бесполезен.
                                        Ну так TFS не только номер показывает.

                                        >> Кстати, у вас нет ни одного checkin без WI?
                                        Нет. Это как раз запрещено той же самой политикой, которой вы запретили чекины без комментариев.
                                          0
                                          Можно и так. Как и во всем, здесь есть свои плюсы и минусы.
                                          Также, могут быть проблемы, если автоматический билд что-то чекинит.
                                            0
                                            Ну во-первых, лучше ничего не чекинить автоматическим билдом. А во-вторых, это вполне решаемые проблемы в среднем.
                          0
                          Все-таки логично увидеть все изменения связанные с определенным дефектом. Это сразу позволяет оценить несколько аспектов этой починки.
                        0
                        SVN, кстати, тоже так не показывает, там надо ревизию выбрать сначала.
                        0
                        Еще вы совершенно упускаете My work (хотя он доступен только от Premium и выше).


                        Согласен. Не знаю что это такое, но теперь попрбую. Спасибо!

                        Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).

                        Тривиально: из WI открываете all links, там будут все changeset, которые ассоциировали с этим WI. Дальше по двойному клику на чейнджсете вы получаете полный список всех изменений этого чейнджсета.


                        Да, я получу список всех изменений этого чейнджсета, но часто мне необходимо список изменений всего «дефекта» (нескольких чейнджсетов).
                          0
                          часто мне необходимо список изменений всего «дефекта» (нескольких чейнджсетов).

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

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

                              Сочетание правил (2) и (3) означает, что в любом чейнджсете, если это не рефакторинг, должны быть тесты, а рефакторинг тестами покрывать не надо.

                              Соответственно, следствие из правила (2) — оценивать надо каждый чейнджсет отдельно, потому что именно он может уйти в другую ветку/на продуктив.
                                0
                                Все что вы написали правильно, но что бы поддерживать такой способ нужно просматривать историю, проверять что все выполняют эти правила и т.д. и т.п. Эта работа особенно требует быстрый и удобный поиск, чего как раз и не хватает в TFS
                                  0
                                  Не, вот поиска эта работа не требует. Она требует банального просмотра каждого cs отдельно.
                                    0
                                    Не совсем, прежде всего мне надо увидет все изменения дефекта, а не отдельной ревизии.
                                    Например, пишешь в фильтре истории номер дефекта и сразу видишь все ревизии. Сразу понимаешь, что этот человек нарушил правила проекта.
                                      0
                                      Не совсем, прежде всего мне надо увидет все изменения дефекта,

                                      Вы пока так и не объяснили, зачем.

                                      Сразу понимаешь, что этот человек нарушил правила проекта.

                                      Какие именно?
                                        0
                                        Сразу понимаешь, что этот человек нарушил правила проекта.

                                        Какие именно?

                                        два ревизии на один «дефект», например.
                                          0
                                          Зайдите в закрытый WI и посмотрите. Это эффективнее, чем проверять список из 180 чекинов на то, что в 99-ом тот же номер, что и в 15-ом.
                                            0
                                            Я предпочитаю работать от кода, а не от WI.
                                              0
                                              В работе «от кода» ваш сценарий невозможен, потому что в коде видно финальное состояние, а не историю. Не надо путать одно и другое.
                                                0
                                                История кода + фильтр по номеру дефекта показывает полную историю изменений. Это то что мне надо.
                                                  0
                                                  Это не «от кода», это «от истории». Другой сценарий.
                                                    0
                                                    От истории кода, а не от WI.
                                          0
                                          Не совсем, прежде всего мне надо увидет все изменения дефекта,

                                          Вы пока так и не объяснили, зачем.


                                          Не могу это объяснить в общем. Просто я так начинаю: прежде всего оцениваю что произошло за период времени и выбираю наиболее «интересный» баг или ревизию для дальнейшей работы.
                                            0
                                            Это никак не относится к сценарию «мне надо увидеть все изменения по WI».
                                              0
                                              Почему?
                                              Я увидел какой-то WI и он меня почему то заинтересовал.
                                              Набираю его номер в фильтре (SVN) и сразу вижу все релевантные ревизии и изменения.
                                                0
                                                А в TFS вы набираете его номер и сразу видите сам WI, а потом и релевантные изменения.

                                                Вы просто привыкли мыслить версионником, потому что SVN — это версионник. Но в TFS это не так.
                                                  0
                                                  Так я об этом и писал!
                                                  Я привык идти от кода, поэтому начинию с истории (лога) кода и дальше добираюсь (если надо) до WI.
                                                  В TFS это не так, т.е. (на мой взгляд) TFS менее заточен для программиста (код), чем другие (например SVN).
                                                    0
                                                    То, что вы описываете — потребность не программиста, а менеджера. Программисту нужно знать текущее состояние кода и причины, которые к нему привели. Т.е., annotate.
                                                      0
                                                      я начинаю от общего к частностям: вперва сколько ревизий для этого дефекта, где были изменения, какие были изменения.

                                                      А annoate я использую когда надо быстро найти, кто написал этот фрагмент кода, и в рамках какой деятельности.
                                                        0
                                                        я начинаю от общего к частностям: вперва сколько ревизий для этого дефекта, где были изменения, какие были изменения.

                                                        И зачем это нужно программисту?

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

                                                          И зачем это нужно программисту?


                                                          У меня есть такие примеры:
                                                          — мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
                                                          — расследования всяких сложных проблем: что то пошло не так (какие то тесты стали падать, перформанс пострадал, интеграция с другой программы барахлит).
                                                            0
                                                            мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)

                                                            Это делается не программистом, а тимлидом (который, конечно, тоже программист, но это другая часть его функций). И правильно это делать через code review.

                                                            расследования всяких сложных проблем

                                                            Это делается не по WI, а по всей истории кода сразу.
                                                              0
                                                              расследования всяких сложных проблем

                                                              Это делается не по WI, а по всей истории кода сразу.


                                                              Так я про это и пишу.
                                                              Например, попадали тесты, открываешь историю, находишь подозрительную ревизию, откатываешь все ревизии этого дефекта, проверяешь этот тест локально. Красота!
                                                              Жалко TFS данного сценария не поддерживает совсем :(.

                                                              и делается это одним из обычных программистов.
                                                                0
                                                                TFS поддерживает этот сценарий на уровне «попадали тесты — код не попал в репозиторий — красота». Если вы по каким-то причинам не делаете gated check-ins (а зря), то «находишь подозрительное изменение, откатываешь это изменение, проверяешь тест локально». Вы же помните, что все изменения должны быть атомарными?
                                                                  0
                                                                  Как пел классик
                                                                  А я живу в реальном мире, Где жизнь весны полна
                                                                  .

                                                                  Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота». А иногда важнее отдать версию, даже с падающим тестом.

                                                                  Вы же помните, что все изменения должны быть атомарными?

                                                                  Помню. Только не знаю где есть такая команда, в которой это работает. Может послать туда резюме, раз TFS не поддерживает реальность? ;)
                                                                    0
                                                                    Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота».

                                                                    Читайте Continuous Delivery.

                                                                    Только не знаю где есть такая команда, в которой это работает.

                                                                    А если у вас изменения не атомарны, то вам надо откатывать не все изменения по WI, а полностью все состояние репозитория на момент до подозрительного изменения, потому что вы не знаете, как последующие работы повлияли на код.
                                                                      0
                                                                      Читайте Continuous Delivery.
                                                                      Можете посоветовать, что то конкретное?
                                                                      Просто тесты (быстрые тесты) мы запускаем конечно же на каждый коммит (чек-ин), но даже этот процесс (очередь, компиляция, выполнение тестов) может занять десятки минут.
                                                                        0
                                                                        Можете посоветовать, что то конкретное?

                                                                        Билд-грид. Железки нынче дешевы сравнительно.
                                                                          0
                                                                          Мы тут уходим в другую сторону.
                                                                          Но даже там не все так просто: просто железку наш айти не купит, а еще нужно место найти, кондиционер и т.д.
                                                                            0
                                                                            Угу, а деньги на TFS и студии при этом есть.
                                                                              0
                                                                              Я деньгами не занимаюсь :(.
                                                                              Может на последние купили и на железо не осталось :)
                                                                                0
                                                                                А это типичная ошибка планирования: не надо покупать софт, который потом не на чем будет запустить.
                                                                                  0
                                                                                  в данном случае более правильно «не надо писать такие тесты, которые потом не на чем будет запустить».
                                                                        0
                                                                        а полностью все состояние репозитория на момент до подозрительного изменения, потому что вы не знаете, как последующие работы повлияли на код.


                                                                        так я так и ищу: откатываю подозрительные дефекты, все ревизии не имеет смысла откатывать: я и так знаю, что тесты не падали.
                                                                          0
                                                                          Еще раз: если изменения атомарны, то можно откатывать каждое изменение отдельно. Если изменения не атомарны, то бесполезно отказывать «изменения в рамках WI», надо откатывать все изменения до стабильной линии.
                                                                            0
                                                                            когда я ищу проблему, нет смысла откатывать до стабильной линии: там то все работает.
                                                                            мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.
                                                                              0
                                                                              мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.

                                                                              Я не вижу в этом контексте разницы между откаткой WI и откаткой конкретного CS — проблему-то порождает изменение. Поэтому, когда вы ищете, что сломало, надо мыслить чейнжсетами, а не задачами.
                                                                                0
                                                                                Конечно, но тяжело откатить ревизию, если это часть починки бага. Обычно требуется откатить все ревезии одного дефекта.
                                                                                  0
                                                                                  Обычно требуется откатить все ревезии одного дефекта.

                                                                                  Объясните, почему.
                                                                                    0
                                                                                    пример из жизни:
                                                                                    — утро (раннее утро)
                                                                                    — в стабильной ветке проблема, которая не дает выпустить билд
                                                                                    — вместо кофе открываю историю
                                                                                    — прохожу последние ревизии
                                                                                    — нахожу кандидата, который создает проблему
                                                                                    — откатываю его, что бы проверить у себя на компьютере
                                                                                    — все равно вижу проблему, потому что эта ревизия завязана на другую ревизию этого же дефекта
                                                                                    — хочу откатить вторую ревизию этого дефекта, что бы только проверить свои подозрения
                                                                                    — между этими двумя ревезиями есть другие ревизии ==> TFS не может откатить две такие ревизии
                                                                                    — дальше идет игра слов, которая не будет интересна в данном контексте
                                                                                      0
                                                                                      А теперь сделайте простой мысленный эксперимент: представьте себе, что на CS, который вы откатываете, завязан CS… из другой задачи. Это, надо сказать, совершенно нормальная ситуация в живой системе. И зачем вам теперь операция «откатить все CS по одному WI»?

                                                                                      И нет, вы не правы, TFS прекрасно позволяет откатить любое количество CS, просто это надо делать по одному CS за раз.
                                                                                        0
                                                                                        И нет, вы не правы, TFS прекрасно позволяет откатить любое количество CS, просто это надо делать по одному CS за раз.


                                                                                        Секундочку.
                                                                                        Я хочу откатить только на локальном компьютере, что бы проверить. Я не хочу делать чек-ин, пока не проверю. Этого TFS не позволяет (в моем реальном случае между подозрительными ревизиями находились нормальные, которые я не хотел откатывать).
                                                                                          0
                                                                                          Берем историю. Выбираем произвольный CS, нажимаем Rollback entire changeset, получаем в workspace компенсирующие изменения. Берем следующий произвольный CS, нажимаем Rollback entire changeset, получаем в workspace компенсирующие изменения. Если компенсирующие изменения конфликтуют — вероятно, получаем разрешение конфликта или окно об ошибке (вот это я проверить уже не могу, лень искать такую комбинацию).

                                                                                          И да, я только что это проверил (VS 2012 Update 4, TFS 2012 Update-не-помню).
                                                                                            0
                                                                                            сорри: небольшая, но важная неточность.

                                                                                            Эти две ревизии содержат, по крайней мере, один общий файл.
                                                                                            В этом случае не могу откатить вторую ревизию с сообщением: TF203015: The item «fileName» has an incompatible pending change.
                                                                                            Проверял на двух ревизиях с одним и тем же файлом.
                                                                                              0
                                                                                              Это то, о чем я говорю, как о конфликте компенсирующих изменений. В этом случае вам нужно конкретный файл откатить на версию до обоих изменений (если для проверки — то через Get Specific Version, если для починки — то через Rollback to a version).
                                                                                                0
                                                                                                Глубоко же закопана возможность «Get Specific Version».
                                                                                                Power Tools не содержит такого пункта меню. А в студии этот пункт находится в Advanced.

                                                                                                Но, во-первых, большое спасибо за совет как обойти ограничение на два Rollback!

                                                                                                Теперь рассмотрим мой конкретный сценарий: первая ревизия содержит X файлов, вторая — Y и Z — общие файлы этих двух ревизий.
                                                                                                Так теперь мне придется ручками «откатывать» все файлы из групп X и Y?
                                                                                                Сложновато и опасно где-нибудь ошибиться.
                                                                                                Или я не так понял?
                                                                                                  0
                                                                                                  Глубоко же закопана возможность «Get Specific Version».
                                                                                                  Power Tools не содержит такого пункта меню. А в студии этот пункт находится в Advanced.

                                                                                                  … или правой кнопкой в истории — Get this version.

                                                                                                  Теперь рассмотрим мой конкретный сценарий: первая ревизия содержит X файлов, вторая — Y и Z — общие файлы этих двух ревизий. Так теперь мне придется ручками «откатывать» все файлы из групп X и Y?

                                                                                                  Нет, вам придется «ручками» откатывать только общие файлы.

                                                                                                  Сложновато и опасно где-нибудь ошибиться.

                                                                                                  «Опасно ошибиться» — это диагностика по cherry-picking, когда вы откатываете много файлов в разных наборах изменений, рискуя получить заведомо неконсистентную систему.
                                                                                                    0
                                                                                                    Согласитесь, что простой реверт в SVN гораздо более просто и безопасно реализует данный сценарий.
                                                                                                    Я понимаю, что хорошо бы не доводить дело до такого сценария, но он случается.
                                                                                                      0
                                                                                                      Простой реверт (svn revert) в SVN откатывает локальное состояние, то же самое, что undo в TFS.
                                                                                                        0
                                                                                                        Я имею ввиду реверт ревизий из истории
                                                                                                          0
                                                                                                          svn merge -r?
                                                                                                          Ничего «более простого и безопасного» в нем нет, вы получаете неявный мерж нескольих измененных файлов в локальной области.
                                                                                                            0
                                                                                                            Это именно то что мне надо. По сравнению с подходом TFS это более понятно и гораздо быстрее.
                                                                                                              0
                                                                                                              Это вам более понятно. Потому что вы привыкли к идеологии SVN, а перестраиваться сложно. А я вот, работая с SVN после TFS, долго и мучительно ругался на неоднозначность разрешения конфликтов.
                                                                                                                0
                                                                                                                Секундочку.
                                                                                                                Я описал проблему и решение этой проблемы в SVN. В TFS эту же проблему можно решить гораздо более сложным способом. Причем тут «привык»? Я уже пол года использую TFS. Уже привык к тому, что можно привыкнуть.
                                                                                                                  0
                                                                                                                  Я не считаю способ, существующий в TFS, более сложным.
                                                                                                                    0
                                                                                                                    Посчитаем количество кликов? ;)
                                                                                                                      0
                                                                                                                      Количество кликов некритично, критична предсказуемость результата. Для меня, по крайней мере.
                                                                                                                        0
                                                                                                                        Ок. Я понял ваше мнение.
                                                                                                                        Кстати, «Будете у нас на Колыме» дайте знать. После таких обсуждений я просто вынужден угостить пивом ;)
                                                                                          0
                                                                                          А теперь сделайте простой мысленный эксперимент: представьте себе, что на CS, который вы откатываете, завязан CS… из другой задачи. Это, надо сказать, совершенно нормальная ситуация в живой системе. И зачем вам теперь операция «откатить все CS по одному WI»?


                                                                                          Мой опыт данного проекта, говорит о том, что довольно редко ревизии одного WI завязаны на ревизии другого. А если это так, то почему бы этим не пользоваться?
                                                                                            0
                                                                                            Ну воспользуйтесь. Как это сделать, я показал.
                                                                    0
                                                                    мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)

                                                                    Это делается не программистом, а тимлидом (который, конечно, тоже программист, но это другая часть его функций). И правильно это делать через code review.


                                                                    Я местный code review еще «не проходил». Так что все впереди. Хотя все равно не понимаю, как это поможет мне реализовать сценарий описанный выше.
                                                    0
                                                    Почему вам не кажется, что лучше выбрать наиболее интересный баг по тому, как его заранее оценили? Или как скажет разработчик? Или по рангу-приоритету?
                                                      0
                                                      Тоже вариант. Но я предпочитаю, прежде всего, работать с существующими данными. А история кода самые релевантные данные для моих целей.
                                  0
                                  Но зачем, если есть Git!?
                                    +1
                                    Позвольте мне не обсуждать причины перехода на TFS в этом посте.

                                    Кроме того, я не понимаю какие преимущества (кроме локальной истории) в GIT по сравнению с SVN. Я часто и честно пытался это понять (включая хабр и подкаст умпутуна).
                                    Можете объяснить мне на пальцах? Буду бесконечно благодарен.
                                      0
                                      «Легкие» ветки, слияние, rebase, bisect, stash, rerere — это как минимум.
                                        0
                                        Я слышал все эти слова.
                                        Но мне бы на пальцах.

                                        В SVN мы работали с бранчами, создавали сколько надо, жили в них сколько надо, возвращали в родную ветки без особых проблем (есть минимальные требования конечно к поддрежки «долгих» веток).
                                        Наверно единственной серьезной проблемой было перенос ветки в главную ветку другой версии.

                                        Так зачем для данного сценария работа GIT?
                                          0
                                          В git-е делать, менять и удалять бранчи легко и приятно. Это и рождает новый, принципиально недостижимый для SVN/CVS/Perforce/whatever workflow, когда в текущей работе может одновременно сосуществовать сотня бранчей, по одному на каждый исправляемый баг, и отдельно — для каждой новой разрабатываемой фичи. И вся логика работы (в том числе и поиск багов) базирована на этом.
                                            0
                                            Именно так мы и работали в SVN.
                                            Именно так мы пытаемся работать в TFS, но из-за сложностей свитча, этот путь не такой легкий и приятный.
                                              0
                                              но из-за сложностей свитча, этот путь не такой легкий и приятный.

                                              Вот я и удивлен переходом на TFS — зачем мучатся вообще!? (особенно, если SVN всем устраивал).
                                                0
                                                к сожалению обсуждения принятий решений выходит за рамки данного поста
                                                  0
                                                  Ну что ж, тогда сожалею, желаю вам пережить этот ужас (TFS)!
                                                    0
                                                    Спасибо! Есть все-таки не только умные и добрые, но и сочувствующие люди на хабре!

                                                    Как говаривал наш бывший главный директор (после отставки и полугодового отпуска в европе) «изменения — это возможность», так что надо этим пользоваться!
                                              0
                                              На каком основании вы сделали такие выводы? Я легко веду ветки в TFS.
                                                0
                                                Как мне видится, проблема в том, сколько времени занимает создать и получить ветку на локальном диске. Если получить ветку у себя на компьютере занимает много (думаю начиная с 10 минут это уже много) времени, то такая система управления версиями не поддерживат «быстрые» ветки.
                                                Например, я знаю проект, ветку которого можно получить за минут 20-25 (в локальной сети фирмы) и за гораздо более другие времена, если скачивать через wi-fi иди удаленно.
                                                Одним из способов решения этой проблемы, является механизм переключения существующей локальной папки с одной ветки на другую. В SVN это называется switch. Если ветки не далеко ушли друг от друга, то свитч займет секунды (минуту — в случае удаленной работы).
                                                Не нашел простого и внятного способа в TFS переключить ветки (stackoverflow предлогает только через командый файл с помощью unmap и map). Этот workaround (unmap & map) не быстрый процесс.
                                                Таким образом можно сказать, что TFS не имеет «больших» «быстрых» веток.

                                                  0
                                                  Таким образом можно сказать, что TFS не имеет «больших» «быстрых» веток.

                                                  Ваше утверждение неверно. Для проекта разумного размера создание новой ветки и ее открытие происходит за время, существенно меньшее 10 минут.
                                                    0
                                                    Какое именно утверждение не верно?
                                                      0
                                                      Что TFS не имеет больших быстрых веток, поскольку (как вы считаете) TFS не позволяет получить новую ветку за время, не превышающее 10 минут.
                                                        0
                                                        Ну да.
                                                        За сколько можно получить ветку размером 300 мегабайт на свой комп, работая удаленно?
                                                          0
                                                          За время, равное скачиванию 300Мб на ваш компьютер по сети (в случае Server workspace, про локальные не знаю).

                                                          (да, я в курсе, что TFS плохо работает в ocassionally connected-сценариях. Это известное ограничение.)
                                                            0
                                                            Ну так это и говорит, что TFS не поддерживает больших быстрых веток.
                                                              0
                                                              Почему же, поддерживает. Ограничение налагает сеть, а не TFS.
                                                                0
                                                                SVN обходит ограничения сети, а TFS — нет
                                                                  0
                                                                  Вопрос, ценой чего.

                                                                  (это как локальные рабочие пространства в TFS, они тоже обходят эти ограничения… но с проблемами)
                                                                    0
                                                                    Согласен, практически любая вещь имеет свою цену.
                                                                    Таким образом у TFS очень дорого иметь большие ветки, а SVN гораздо дешевле.

                                                                      0
                                                                      Неверно. В TFS дорого работать с большими рабочими областями при плохой сети (в общем-то, безотносительно того, ветка это или нет). И, наоборот, если ты сидишь в нормальной сети, то работа с ветками не затруднительна.
                                                                        0
                                                                        Сценарий: сделать новый бранч (размер — 1GB) и получить его на локальном диске
                                                                        Условия: на локальном диске находится стабильная ветка

                                                                        Локальная сеть:
                                                                        SVN — минута с помощью switch
                                                                        TFS — минимум минут 20 для серверного мода (минут 40 для локального)

                                                                        Удаленно:
                                                                        SVN — минуты с помощью switch
                                                                        TFS — ближе к часу для серверного мода + некоторое количество «обрывов» (т.е. ручками придется запускать процесс несколько раз)

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

                                                                          в моем типичном использовании TFS не поддерживает «быструю» работу с ветками.

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

                                                                            Ну да, признаю, на гигабайтных объемах я TFS не тестировал. Но уж простите, я это нормальным сценарием никак назвать не могу.


                                                                            Кроме того я сразу написал "больших" веток.
                                                                            Как мне кажется TFVC пользуются только «большие» компании, которые создают серьезный большой продукт. А какой в таком случае должен быть «средний» размер ветки?

                                                                              0
                                                                              Ничего не знаю про «средний» размер ветки, но я сейчас специально ради теста целиком сбранчил одно из наших магистральных решений. Бранчилось оно 3-4 минуты (естественно, это включая время получения на жесткий диск). Размер… с удивлением узнал, что уже больше 2Gb; из которых, правда, собственно исходников — 65Mb, остальное — метаданные и бинарные зависимости. TFS2012, серверный workspace, гигабитная локальная сеть.

                                                                              3-4 минуты. ЧЯДНТ?

                                                                              (а, поправка, я бранч не чекинил сразу после этого, возможно, вы еще на этом тратите много времени)
                                                                                0
                                                                                (а, поправка, я бранч не чекинил сразу после этого, возможно, вы еще на этом тратите много времени)


                                                                                не совсем понял, что имеется ввиду?

                                                                                3-4 минуты. ЧЯДНТ?

                                                                                Это хороший вопрос. Может общее время зависит не только от размера, сети, но и других факторов (удаленность от сервера? скорость локального диска? нагрузка на TFS сервер? и т.п.).
                                                                                Попробую перемерять и поэкспериментировать.

                                                                                В любом случае, switch позволяет игнорировать всякие проблемы (сеть, удаленность и т.п.) для получения «большой» ветки, а TFS требует «хороших» условий.
                                                                                  0
                                                                                  не совсем понял, что имеется ввиду?

                                                                                  Ну, я создавал бранч второго класса, с проставленной галкой «Create local working copies for the new branch». В этом случае создается бранч, который потом нуждается в чекине (в отличие от создания бранча первого класса, когда тот создается на сервере, чекина не требует, зато требует последующего Get latest).
                                                                                    0
                                                                                    В каких сценариях используется такой бранч?
                                                                                      0
                                                                                      Мы используем во всех, когда не можем использовать бранчи первого класса (а их нельзя использовать, когда бранчи вложены).
                                                                                0
                                                                                Вот вам поучительные цифры от MS (которые да, сами сидят на TFS). Обратите внимание, что типичный разработчик никогда не держит у себя бранча целиком («a full branch has about 5M files, and a typical dev workspace 250K files», приблизительно 1/20).
                                                                                  0
                                                                                  Я не понял "250K files" — это имеется ввиду 250 тысяч файлов? Если да, то интересно сколько это в гигабайтах?
                                                                                    0
                                                                                    Да, это 250 тысяч файлов. Конкретики по физическим размерам бранчей я там не нашел.
                                                                                      0
                                                                                      ну так 250 тысяч файлов легко может занять несколько гигабайт
                                                                                        0
                                                                                        Легко может. Но у DevDiv точно другая политика бранчинга, нежели в git community.

                                      Only users with full accounts can post comments. Log in, please.