Особистий досвід: організація 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 доповідей, представлених в ході заходу. Всі презентації та відео виступів будуть додані в таблицю в кінці цього топіка-анонсу.

Автор: Олексій Соловйов
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.