У новому GitLab 8.11 стільки всього цікавого, що ми насилу стримуємо себе в рамках конструктивного оповідання!
Отже, в новій версії з'явилися:
Налаштовуючи Jira зіткнувся з тим, що не можу дати доступ користувачеві системи до окремого Issue в конкретному проекті.
На сьогоднішній день Atlassian JIRA є одним з найвідоміших і популярних баг-трекерів. Крім того, в усьому світі цілий ряд компаній використовують JIRA не тільки в якості баг-трекера, але і як систему управління проектами. JIRA досить універсальна. щоб вирішувати велику кількість здавалося б, не пов'язаних одна з одною завдань, і вона досить просто розширюється за рахунок розробки додаткових плагінів.
Поширена проблема менеджера проектів - визначити, від кого залежить подальше виконання завдання. Часто завдання призначається на розробника, та так і залишається "висіти" на ньому аж до релізу. Однак розробник відповідає тільки за частину виконання. QA - тестує, DevOps - включає в реліз, продакт-менеджер - оцінює готову роботу (в кожній організації цей ланцюжок своя). Завдання подорожує від статусу до статусу (In Progress, Done, Tested, Shipped, Closed і т.п.), але виконавцем значиться все той же розробник.
Ми шукали варіанти з хостингом у творця софта, щоб не возитися з інсталяцією у себе (тому, наприклад, тут немає Redmine в чистому вигляді).
Мені була важлива інтеграція з Google calendar і github.
Також хотілося чогось більшого ніж Bug tracking - ще і управління Фічер, вимогами і т.д.
Прошу вибачення за багато термінів англійською.
Картинки по кліку відкриваються в повний розмір
Справжній IT-шник завжди любить зварити «кашу з сокири». А якщо цією кашею ще і виходить смачно нагодувати колег, то виходить взагалі чудово.
За службовим обов'язком мені постійно доводиться стикатися з різними інсталяціями bug і issue-трекерів (далі просто баг-трекерів) і серед них траплялося досить багато нестандартних рішень. Щось мені доводилося розгортати самому, щось я «підглянув» у клієнтів, але поділитися спостереженнями було б корисно.