Личный опыт: организация Workflow в трекере TFS



    Мы продолжаем рассказывать о процессах организации разработки в Positive Technologies. Ранее мы коснулись тем создания дистрибутивов продуктов, организации процесса хранения и лицензирования софта и реализации собственной системы Continuous Integration.

    Сегодня речь пойдет о том, как мы используем инструмент Team Foundation Server (TFS) для организации workflow разработки.

    Немного о TFS


    Team Foundation Server состоит из нескольких компонентов.

    Система контроля версий:



    Трекер задач:



    Система непрерывной интеграции:



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

    TFS для трекинга задач и организации Workflow


    Система поддерживает методологии разработки, такие как Kanban, Scrum, CMMI. Кроме того, поддерживаются различные — в том числе кастомные — типы задач: Bug, Task, Feature, User Story и т.п. Также стоит отметить гибкую систему изменения Workflow-задач.

    Базовый Workflow для задачи Bug в TFS выглядит следующим образом:



    Мы видим n статусов — начальный, конечный и переходы между состояниями. Как правило, на базовом workflow мало кто работает — всегда возникает необходимость его расширения.

    Измененный процесс в нашем случае может выглядеть примерно так:



    Расширение Workflow было выполнено путем добавления новых статусов и переименования существующих. Например, были добавлены статусы Rejected — для задач, которые были отклонены по каким-либо причинам, Moved — для задач, перенесенных в другой проект, Pending — для задач, которые были временно приостановлены.

    Переименованные статусы: Approved стал называться In Progress, он значит, что задача была взята в работу, а Commited переименовали в Resolved, означающий, что задача была решена и требуется подтверждение ее выполнения, либо дополнительные работы по ней.

    Аналогичным образом изменяется и внешний вид карточки Bug. В самом начале после создания проекта она выглядит так:



    В базовом виде система предоставляет немного информации — как минимум, отсутствует шаблон для шагов воспроизведения, никаких временных метрик и других необходимых нам полей. Такой дефицит нас не устроил, поэтому внешний вид карточки мы также переработали под свои нужды.



    Мы добавили колонку с полями для тайм-трекинга (Original Estimate, Remaining Work, Completed Work, Daily Work), в шаги воспроизведения был добавлен шаблон для заполнения HTML, а также появилась классификация багов по различным признакам.

    Проблемы и решения


    Несмотря на удобство системы, при работе с Workflow в трекере TFS есть и ряд сложностей:

    • Нет рассчитываемых полей — «навешивание» на полей дополнительной логики трудно реализуется, даже перенос временных метрик из дочерних элементов в родительские не предусмотрен.
    • Нет поля множественного выбора — если в Bug или каком-либо другом work item есть поле клиент, а ошибка встречается у нескольких клиентов, то выбрать их всех нельзя, возможно только одно значение.
    • Неудобный процесс изменения полей и их типов — если в названии поля была допущена ошибка, то исправить ее нельзя, требуется пересоздание поля с переносом всех значений в новое.
    • Нельзя отслеживать изменения и откатывать их — все шаблоны багов и конфигурации TFS хранятся в виде XML, загружаемых в базы. Если допустить ошибку и залить ее в базу, то откатиться на предыдущую версию не удастся. Так что нужно самостоятельно помнить, где и что ты менял.
    • Неудобная система прав для изменения workflow и списков — она устроена таким образом, что если дать пользователю права на изменение списков полей, то он автоматически получит права на изменение списков всего workflow.

    Мириться с этими недостатками нам не хотелось, поэтому пришлось решать возникающие проблемы. Вот что мы сделали:

    • Стали использовать открытый проект TfsAggregator для расчета логики полей — удобный инструмент для расчета time tracking-полей, проброса текстовых значений из одного рабочего элемента в другой и т.д.
    • WitCustomControls для реализации поля комбобокса — еще один открытый проект, Java-Script-плагин, позволяющий создавать поля множественного выбора.
    • Gitlab для хранения и трекинга шаблонов рабочих элементов — помогает отслеживать изменения в конфигурациях и дает возможность откатиться на предыдущую версию в случае ошибки.
    • Изменения в шаблоны рабочих элементов, списков и пр. разрешено вносить только администраторам сервиса TFS — это сделано для снижения риска несанкционированного изменения каких-либо конфигураций, списков и т.д.

    P. S. Рассказ о разработанном нами инструментарии для создания дистрибутивов был представлен в рамках DevOps-митапа, который состоялся осенью в Москве.


    По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.

    Автор: Алексей Соловьев

    P. P. S. Напоминаем, что совсем скоро при поддержке Positive Technologies в Москве пройдет курс по asyncio+aiohttp от Core-разработчика Python Андрея Светлова.

    Мы хотим предложить один бесплатный билет на семинар автору лучшего вопроса для Андрея — вопрос выберет он сам и ответит на него в ходе занятия. Присылайте свои вопросы по адресу: asyncio2016@ptsecurity.com.
    Positive Technologies
    178.82
    Company
    Share post

    Comments 27

      –2
      Наша команда постоянно испытывает боль и страдания при работе с TFS, кроме того это поделие сильно тормозит и постоянно что-то отваливается. Связка tfs-git имеет свойство терять коммиты. Фраза «TFS — г#вн#!!» звучит почти на каждой ретроспективе. Никому не посоветую связываться с этим продуктом
        +1
        Зачем вам связка git-tfs при нормальных гитовых репозиториях 0_о? У нас ничего не тормозит и работает стабильно. Возможно развернут криво и зачем-то TFVC используете.
          0
          Продукт под Linux посему используем git, но репозиторий держим в TFS для всяких релизных процедур и сертификации. К сожалению, отказаться от него(TFS) нельзя, а для пингвина нет нормального TFS клиента контроля версий. Возможно в мире Windows все гладко, но в нашем случае есть определенный геморрой.
            0
            А какие клиенты нужны? Все необходимое есть в Web. Исходники можно перенести в Git. можно даже в сторонний git сервер. Начиная с TFS 2012 не знаю что такое TFS тормозит. Начиная с 2015 получил еще и шикарные билды.
              0
              Еще и Nuget фиды, а в 17 и npm завезли.
                0
                Нужен линуксовый консольный клиент к TFS контролю версий, нативный git репозиторий использовать не модем по ряду причин(централизованные бэкапы, требования по сертификации, etc). Cборочный конвейер пока используем другой.
                  0
                  Бэкапы чего? Какие требования по сертификации? Git репо в базе TFS живет.
                    0
                    Бэкапы репозитория. IEC 61508, одно из требований — обеспечение трейсабилти между исходным кодом и сущностями трекинговой системы(требованиями, тасками, багами и т.п.)
                      0
                      Git так же поддерживает traceability. И лэйблы с билдами и тд. Бэкап репозитория — бэкап базы Project Collection, если хочется руками.
                      TFS Internals
                0
                Вообще с 2013 поддерживаются нативные git репозитории + пул реквесты. Смысл жрать кактус непонятен при этом. И у нас с TFS Нормально работают из под MacOS (Java+Android и Swift+iOS).
              +3
              Не существует такой системы, которая удовлетворяла бы абсолютно всем требованиям и нравилась бы всем. Это утопия.

              Про тормоза могу сказать следующее: у нас в TFS 300+ человек, 80+ проектов и постоянно собираются (релиз + CI) два проекта. Так же ежедневно мы бекапим воркфлоу всех проектов и WI и при этом тормозов не наблюдается.

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

              Связка tfs-git у нас реализована утилитой git-tf. Да, она весьма интересно пушит в гит результаты, но потерянных коммитов ни разу не было. а что используете вы?

              Про «тфс — ****» сказать ничего не могу. Мы им пользуемся и нашим запросам он удовлетворяет, пусть и не полностью, но мы ищем решения.
                +3
                У каждого своё мнение. Лично у меня только положительный опыт работы с TFS. Тем более многое из коробки, все модули хорошо интегрированы между собой. Не надо тратить дофига времени, чтобы скрестить бульдога с носорогом.
                0
                У того TFS-то нормальный клиент для linux появился?
                  0
                  Вы про TFVC или TFS?
                    0
                    Я про консольный клиент для линукс, но я уже все выяснил из других комментариев. С 2008го года по-прежнему все плохо. Как не умел ветки сливать, видимо, так и не умеет.
                      0
                      А почему на Git не мигрируете?
                        0
                        Ой, много чего можно написать. Там, где я с этой проблемой столкнулся, там я давно уже не работаю. Тогда мигрировали с CVS куда-то. Вся контора на винде, и в углу пять юниксоидов. Конечно же, об их удобстве никто не подумал. Точнее, — подумали и проигнорировали. Перешли на TFS. Зато манагеры получили возможность смотреть на красивые отчеты. Как-то так
                  0
                  У нас с TFS только в одном жуткая боль (36+ программистов, 10+ релизов в разработке) — удаление ветки после установки.
                  Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин. Откатить такой Pending Change тоже не получается.
                  Может быть кто-нибудь сталкивался с такой проблемой?
                  Сейчас выкачиваем и сносим по 2-3 ветки, но это сильно раздражает…
                    0
                    Выше уже отписал. Почему не мигрировать на Git? Нет проблем с ветками, при пул реквестах рабочие ветки можно автоматом удалять.
                      0
                      У нас специфика разработки и сборки выстроена жестко под тфс + teamcity. Гит смотрели, но не смогли придумать как на нем организовать процесс по той же схеме.

                      Концепция процесса в том, что все задачи разрабатываются каждая в своей ветке (отношения dev_i -> задача), каждую задачу можно передвинуть за два клика в другой релиз DEV_j просто сделав reparent к DEV_j.
                      TeamCity собирает все изменения из DEV_i+ все дочерние ветки, после установки релиза на бой все изменения разносятся по цепочке (задачи релиза -> dev_i -> trunk -> dev i+1..n -> задачи по dev i+1..n), т.е. каждая задача в любой момент времени отличается от продуктива исключительно на правки по задаче.

                      С Git не смогли понять как быстро двигать задачи из релиза в релиз, не затрагивая всю цепочку, но если подскажешь куда посмотреть за пруфом — с удовольствием сходим и посмотрим.
                        0
                        Задачи или фичи?
                        Задачи/фичи после RTM в той же ветке живут или ветка выносится?

                        Не очень понял про двигать задачи из релиза в релиз :) Можно поподробнее о вашем процессе и требованиях? Сабмодули вам не подходят?
                          0
                          Мы сейчас работаем по схеме, которая описана тут в пункте Isolated Development Scenario.
                          Правда ушли чуть глубже и от каждого релиза (фичи) еще бранчуем все задачи, которые должны в рамках нее встать на бой, чтобы разрабатывать их совсем независимо друг от друга.

                          В дату установки все задачи вливаются в релиз, релиз вливается в в main и из него разносится во все релизы в разработке, из каждого релиза в разработке — в отбранчеванные от него задачи.
                          Т.е. каждую задачу можно очень быстро перекинуть от одной фичи к другой, исключив ее из ближайшей установки или наоборот двинуть пораньше. Задачи отдельно на продуктив не встают — только протестированной пачкой и в рамках релиза. Это краеугольный камень в нашем процессе, из за которого не смогли перейти на GIt.

                          Почитаю про подмодули, там есть над чем подумать. Спасибо.
                            0
                            Я бы попробовал сабмодули в таком случае. TFS 2015 их поддерживает:
                            One TFS Build, Multiple Git Repositories with Submodules
                              0
                              Прочитал что там по ссылке, приведенной вами. Нет никаких проблем не перейти на Git. Бранчевание, это то, что лучше Git пока никто не умеет.

                              С Git вы можете хоть под каждую идею реализации одной таски (в камках фичи (в рамках релиза)) делать ветку. И все это будет без боли. Легко сделали — легко удалили, если не понрацился результат. И не надо засорять прохими реализациями общий репозиторий.
                            0
                            Мне почему-то кажется что вы только что описали какую-то жуткою ересь в плане работы с ветками.

                            В Git работа с ветками куда более гибкая. Все описанное выше делается запросто.
                            К тому же не понятно зачем вообще teamcity если есть родной билд сервер.
                              0
                              Мы работаем по схеме, описанной в рекомендациях микрософта. Сама схема у нас проблем не вызывает, напротив — очень удобно.
                              Единственная проблема, с которой мы сталкиваемся, как уже писалось выше:
                              Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин.

                              Но это не на столько критичная проблема, чтобы ломать выстроенные удобные процессы и резко уходить на Git.
                                0
                                Все что описано в схеме, описанной в рекомендациях microsoft легко ложится на Git.

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