Мы продолжаем рассказывать о процессах организации разработки в 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.
Комментарии (23)
GlebSemenov
02.12.2016 21:57У того TFS-то нормальный клиент для linux появился?
Razaz
02.12.2016 22:05Вы про TFVC или TFS?
GlebSemenov
05.12.2016 10:13Я про консольный клиент для линукс, но я уже все выяснил из других комментариев. С 2008го года по-прежнему все плохо. Как не умел ветки сливать, видимо, так и не умеет.
sKs
05.12.2016 09:48У нас с TFS только в одном жуткая боль (36+ программистов, 10+ релизов в разработке) — удаление ветки после установки.
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин. Откатить такой Pending Change тоже не получается.
Может быть кто-нибудь сталкивался с такой проблемой?
Сейчас выкачиваем и сносим по 2-3 ветки, но это сильно раздражает…Razaz
05.12.2016 11:28Выше уже отписал. Почему не мигрировать на Git? Нет проблем с ветками, при пул реквестах рабочие ветки можно автоматом удалять.
sKs
05.12.2016 13:39У нас специфика разработки и сборки выстроена жестко под тфс + teamcity. Гит смотрели, но не смогли придумать как на нем организовать процесс по той же схеме.
Концепция процесса в том, что все задачи разрабатываются каждая в своей ветке (отношения dev_i -> задача), каждую задачу можно передвинуть за два клика в другой релиз DEV_j просто сделав reparent к DEV_j.
TeamCity собирает все изменения из DEV_i+ все дочерние ветки, после установки релиза на бой все изменения разносятся по цепочке (задачи релиза -> dev_i -> trunk -> dev i+1..n -> задачи по dev i+1..n), т.е. каждая задача в любой момент времени отличается от продуктива исключительно на правки по задаче.
С Git не смогли понять как быстро двигать задачи из релиза в релиз, не затрагивая всю цепочку, но если подскажешь куда посмотреть за пруфом — с удовольствием сходим и посмотрим.Razaz
05.12.2016 18:02Задачи или фичи?
Задачи/фичи после RTM в той же ветке живут или ветка выносится?
Не очень понял про двигать задачи из релиза в релиз :) Можно поподробнее о вашем процессе и требованиях? Сабмодули вам не подходят?sKs
06.12.2016 09:43Мы сейчас работаем по схеме, которая описана тут в пункте Isolated Development Scenario.
Правда ушли чуть глубже и от каждого релиза (фичи) еще бранчуем все задачи, которые должны в рамках нее встать на бой, чтобы разрабатывать их совсем независимо друг от друга.
В дату установки все задачи вливаются в релиз, релиз вливается в в main и из него разносится во все релизы в разработке, из каждого релиза в разработке — в отбранчеванные от него задачи.
Т.е. каждую задачу можно очень быстро перекинуть от одной фичи к другой, исключив ее из ближайшей установки или наоборот двинуть пораньше. Задачи отдельно на продуктив не встают — только протестированной пачкой и в рамках релиза. Это краеугольный камень в нашем процессе, из за которого не смогли перейти на GIt.
Почитаю про подмодули, там есть над чем подумать. Спасибо.Razaz
06.12.2016 12:03Я бы попробовал сабмодули в таком случае. TFS 2015 их поддерживает:
One TFS Build, Multiple Git Repositories with Submodules
leschenko
12.12.2016 00:37Мне почему-то кажется что вы только что описали какую-то жуткою ересь в плане работы с ветками.
В Git работа с ветками куда более гибкая. Все описанное выше делается запросто.
К тому же не понятно зачем вообще teamcity если есть родной билд сервер.
JonNiBravo
Наша команда постоянно испытывает боль и страдания при работе с TFS, кроме того это поделие сильно тормозит и постоянно что-то отваливается. Связка tfs-git имеет свойство терять коммиты. Фраза «TFS — г#вн#!!» звучит почти на каждой ретроспективе. Никому не посоветую связываться с этим продуктом
Razaz
Зачем вам связка git-tfs при нормальных гитовых репозиториях 0_о? У нас ничего не тормозит и работает стабильно. Возможно развернут криво и зачем-то TFVC используете.
JonNiBravo
Продукт под Linux посему используем git, но репозиторий держим в TFS для всяких релизных процедур и сертификации. К сожалению, отказаться от него(TFS) нельзя, а для пингвина нет нормального TFS клиента контроля версий. Возможно в мире Windows все гладко, но в нашем случае есть определенный геморрой.
leschenko
А какие клиенты нужны? Все необходимое есть в Web. Исходники можно перенести в Git. можно даже в сторонний git сервер. Начиная с TFS 2012 не знаю что такое TFS тормозит. Начиная с 2015 получил еще и шикарные билды.
Razaz
Еще и Nuget фиды, а в 17 и npm завезли.
JonNiBravo
Нужен линуксовый консольный клиент к TFS контролю версий, нативный git репозиторий использовать не модем по ряду причин(централизованные бэкапы, требования по сертификации, etc). Cборочный конвейер пока используем другой.
Razaz
Бэкапы чего? Какие требования по сертификации? Git репо в базе TFS живет.
JonNiBravo
Бэкапы репозитория. IEC 61508, одно из требований — обеспечение трейсабилти между исходным кодом и сущностями трекинговой системы(требованиями, тасками, багами и т.п.)
Razaz
Git так же поддерживает traceability. И лэйблы с билдами и тд. Бэкап репозитория — бэкап базы Project Collection, если хочется руками.
TFS Internals
Razaz
Вообще с 2013 поддерживаются нативные git репозитории + пул реквесты. Смысл жрать кактус непонятен при этом. И у нас с TFS Нормально работают из под MacOS (Java+Android и Swift+iOS).
ptsecurity
Не существует такой системы, которая удовлетворяла бы абсолютно всем требованиям и нравилась бы всем. Это утопия.
Про тормоза могу сказать следующее: у нас в TFS 300+ человек, 80+ проектов и постоянно собираются (релиз + CI) два проекта. Так же ежедневно мы бекапим воркфлоу всех проектов и WI и при этом тормозов не наблюдается.
Тормоза иногда возникают при сильной загруженности инфраструктуры, но они достаточно редки.
Связка tfs-git у нас реализована утилитой git-tf. Да, она весьма интересно пушит в гит результаты, но потерянных коммитов ни разу не было. а что используете вы?
Про «тфс — ****» сказать ничего не могу. Мы им пользуемся и нашим запросам он удовлетворяет, пусть и не полностью, но мы ищем решения.
ShurikEv
У каждого своё мнение. Лично у меня только положительный опыт работы с TFS. Тем более многое из коробки, все модули хорошо интегрированы между собой. Не надо тратить дофига времени, чтобы скрестить бульдога с носорогом.