О сервисе

• сбор, обработка и хранение данных, обеспечивающих производственный процесс:
  • функциональная структура;
  • справочник информационных систем;
  • информация о запусках заданий, выполняемых инструментами DevOps;
  • release notes в привязке к дистрибутивам;
  • pull-requests;
  • дефекты;
  • релизы;
  • распоряжения о внедрении;
  • требования (фичи, истории, задачи, CR, дефекты);
• предоставление отчетности по соблюдению обязательных требований к процессу разработки приложений по заданным метрикам:

  Метрика	Описание
  М1	Доля команд, которые ведут бэклог, состоящий из фич или историй, в системе управления требованиями
  М4	Доля фич со стандартной статусной моделью. Статусная модель считается стандартной, если в ее названии указано "APProcess"
  М29	Доля фич, связанных с описанием требований. Фича считается связанной с описанием требований, если у нее есть ссылка на страницу в системе описания требований
  М28	Доля декомпозированных фич. Фича считается декомпозированной, если она связана с историями
  М6	Доля историй, связанных с релизом
  М9	Доля Change Request со стандартной статусной моделью. Статусная модель считается стандартной, если в ее названии указано "APProcess"
  М30	Доля Change Request, связанных с автоматизированной системой
  М10	Доля Change Request, связанных с элементом бэклога смежной команды. Метрика показывает долю CR в статусах "To Do" и "In Progress", связанных с фичей, историей или задачей
  М11	Доля Change Request, содержащих связь с родительским объектом. В качестве родительского объекта для CR должна выступать фича или история
  М14	Доля дефектов ПРОМ, связанных с объектом "Релиз"

• предоставление отчетности по производственному процессу разработки приложений по заданным метрикам:
  • Deployment Frequency - частота успешных установок дистрибутивов в ПРОМ;
  • Change Failure Rate - доля попыток установок дистрибутивов в ПРОМ, требующих исправления. Установка требует исправления в случае, если задача (джоб) выполнена неуспешно и/или указан неуспешный результат внедрения в распоряжении о внедрении;
  • Lead Time - длительность задачи с момента начала работы над задачей до момента успешной установки дистрибутива в ПРОМ.
    Дата установки в ПРОМ определяется следующим образом:
    1. Для каждого дистрибутива, в составе релизов которых задача выходила в ПРОМ, определяется самая ранняя дата установки.
    2. Из полученных дат выбирается самая поздняя.
    Дата начала работы над задачей определяется следующим образом: для задачи, связанных с ней подзадач/задач, а также связанных с ней pull requests выбирается самая ранняя дата перевода в категорию статуса "В работе" или дата вливания PR в мастер ветку;
• многопользовательский режим работы:
  • в функциональной оргструктуре один пользователь может быть привязан только к одному юр. лицу;
  • в ролевой модели для отчетности один пользователь может быть привязан к нескольким юр. лицам. Пользователь может просматривать данные только в рамках тех юр. лиц, к которым он привязан в ролевой модели;
  • в функциональной оргструктуре один пользователь может быть привязан к нескольким проектам, но в рамках одного юридического лица;
  • дистрибутив связывается со всеми командами, с которыми связаны задачи, вошедшие в состав релиза по этому дистрибутиву;
  • связь дистрибутива с юр. лицом осуществляется через маппинг на информационную систему; при этом у одной информационной системы может быть указано только одно ответственное юридическое лицо.

Показатели назначения

• таймаут на формирование HTTP-запроса со стороны клиента после установления соединения (параметр timeout http-request) — 120 секунд;
• таймаут на установление соединения с сервером Gitlab — 10 секунд;
• таймаут на ожидание ответа от сервера Gitlab (параметр timeout server) — 3 минуты;
• максимальное количество соединений (параметр maxconn, определяет максимально возможное количество соединений со стороны Потребителей, суммарный показатель по всем сервисам Works) — не более 50000. Может уменьшаться в зависимости от ресурсов, потребляемых соединениями со стороны Потребителя.