AlexanderSokolov в 10:56, 26 июля 2018

2018-07-26T10:56:51Z

BenderBot: 1 версия

2010-01-18T13:10:44Z

1 версия

VitaliyFilippov: Изменение синтаксиса конфиденциальных данных для репликации

2010-01-15T19:04:37Z

Изменение синтаксиса конфиденциальных данных для репликации

BenderBot: 1 версия

2009-10-26T01:00:29Z

1 версия

StasFomin: «Jira» переименована в «JIRA»

2009-10-25T20:13:56Z

«Jira» переименована в «JIRA»

Новая страница

Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это ''Issue Tracking system'' — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.

== Чем оперирует ==

Система выполняет учет типизированных запросов/задач с определённым набором полей. Можно описывать новые типы запросов (''Custom Issues''), помимо встроенных. Начальный набор типов запросов такой:

;Bug: Проблема мешающая функционированию продукта
;Improvement: Улучшение — не новый функционал, а улучшение старого
;New Feature: Заказ на новый функционал продукта
;Task: Задание (дело, задача) которое должно быть выполнено

Группируются запросы/задания в первую очередь по «Проектам» (аналог «Продуктов» Bugzilla), затем по компонентам. Есть дополнительный уровень группировки — «Проекты» могут делится по «Категориям».

Атрибутика запроса/задания:
;Информация: Аналог «Bugzilla» «Summary»
;Тип запроса:

:* Bug,
:* New Feature,
:* Task,
:* Improvement
;Уровень доступа:
;Приоритет: Аналог «Bugzilla» «Severity» (<tt>Blocker, Critical, Major, Minor, Trivial</tt>)

;Срок исполнения: Аналог «Bugzilla» «Deadline»
;Компоненты: В отличие от «Bugzilla», здесь задание может относится сразу к нескольким компонентам
;Версии, в которых найдена проблема: Аналог «Bugzilla» «version»
;Закрыт в версии(-ях): Аналог «Bugzilla» «Target milestones»
;Назначен: Аналог «Assignee»
;Автор: Аналог «Reporter»
;Окружение: Аналог «Bugzilla» «OS»+«Platforms», но ненормализованное описание — чистый текст
;Отслеживание сроков: Аналог «Bugzilla» «Time estimated»
;Вложение: Аналог «Bugzilla» «Attachements»

Эти атрибуты обязательно существуют в каждом запросе/задании, но есть понятие раскладки полей («Layout Schemes»), и в этих раскладках некоторые поля можно делать обязательными или необязательными, прятать и т. п. Каждую раскладку можно связать индивидуально с типом запроса и/или проектом. Можно описывать дополнительные атрибуты (''Custom fields''), которые отдельны для каждого типа запроса, и также управлять их использованием через раскладки полей. Каждый запрос/задание имеет «Статус», аналог состояния в Bugzilla («State»).

Начальный набор состояний-статусов (его можно изменять) приведен ниже:

;Open: аналог «NEW»
;In Progress: аналог «ASSIGNED»
;Resolved: аналог «Resolved»
;Reopened: аналог «Reopened»
;Closed: аналог «Closed»

Набор результатов обработки запросов/заданий, или как они названы в русском интерфейсе — резолюций, — также аналогичен багзилльному. Этот набор тоже можно изменять. Начальный набор — следующий:

;Fixed:
;Won’t Fix:
;Duplicate:
;Incomplete:
;Недостаточно информации:
;Cannot Reproduce: «Works for me»

== Схема жизненного цикла (workflow) ==

В отличие от багзильного, схему обработки запросов (''workflow scheme'') можно настраивать, то есть создавать альтернативные графы перехода состояний (+можно заводить дополнительные состояния), и заставлять задания в проектах подчиняться этой схеме. Новый схемы обработки привязываются к проектам и к типам запросов для отдельных проектов.

== Пользователи ==

Учетные записи пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы, то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление приложенных файлов и создание комментариев для менеджеров из других проектов).

== Безопасность ==
Умеет создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.

== Оповещение ==

Как узнают пользователи о том, что их сообщение было отредактировано, или о том, что им адресовано новое сообщение. По аналогии со «схемами безопасности» каждому проекту может быть создана «схема оповещения», в которой указывается на какое событие как должна реагировать система оповещения, которая рассылает почтовые сообщения.

В отличие от [[Bugzilla]], где схема оповещения («email settings») — настраивается каждым пользователем для себя индивидуально, здесь схемы оповещения глобальные.

Атрибута «CC:» здесь нет, но каждый пользователь вправе подписаться на оповещения по любому делу, либо вписать кого-то еще. Правда, я ([[Участник:StasFomin|Стас Фомин]]), не нашел, как узнать, кто еще подписан на данное задание.

== Плюсы и минусы относительно Bugzilla ==

=== Плюсы ===

* Возможность заведения своих workflow-схем. Это можно реализовать в bugzilla (поменяв один файл шаблонов), но эти изменения надо будет уже аккуратно синхронизировать с следующими версиями.
* Настройка видимости полей и дополнительные атрибуты, то есть по сути настройка атрибутики дела — в Bugzille это решаемо только изменением кода.
* Всякие красивости (много иллюстрирующих иконок, заготовки для просмотра статистки по отфильтрованым багам и т. д.).

* Есть русифицированный интерфейс
* Комментарии по заданиям можно делить по типу — комментарий или worklog, и регулировать уровень видимости по каждому комментарию.
* Зависимости между заданиями можно делать разных типов.
* Есть также иерархия подзаданий, то есть под каждым заданием, можно создать одноуровневое дерево из ПодЗаданий (SubTask).
* Есть гибкая настройка схем оповещения: схема определяет, кто получает оповещения на каждое из имеющихся событий, задавая пользователя, группу, или метаадреса (как например: текущий исполнитель, руководитель проекта и т.д). Кроме того, можно оформлять подписки на результат определенного фильтра (аналог поискового запроса в [[Bugzilla]]).
* Возможно задание произвольного количества типов связей между запросами/заданиями. Зависимости и дублирование — лишь частные случаи (типы) связей.
* Возможна интеграция с [[CVS]]. При ведение комментариев на commit определенным образом (теги) — возможен просмотр от запроса (аналога бага) списка файлов в cvs, измененных для его выполнения.

=== Минусы ===

* Нет отображения графов зависимостей в виде диаграммы: зависимости отображаются в виде списка с отступами.
* Нет ключевых слов и соответствующей функциональности, но это легко добавляется пользовательским полем.
* Нет флагов и соответствующей функциональности.
* Убогий интерфейс (POST-запрос при открытии формы создания бага, куча никому не нужных pop-ups, длинная простыня атрибутов для поиска на пустом экране).

== Юмор о JIRA ==
* http://twittch.com/25/

[[Категория:Программирование]]
{{replicate-from-custiswiki-to-lib}}

@@ Строка 1: / Строка 1: @@
 Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это ''Issue Tracking system'' — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.
@@ Строка 93: / Строка 96: @@
 * Нет флагов и соответствующей функциональности.
 * Убогий интерфейс (POST-запрос при открытии формы создания бага, куча никому не нужных pop-ups, длинная простыня атрибутов для поиска на пустом экране).
 == Юмор о JIRA ==

← Предыдущая	Версия 13:10, 18 января 2010
(нет различий)

← Предыдущая	Версия 19:04, 15 января 2010
(нет различий)

← Предыдущая	Версия 01:00, 26 октября 2009
(нет различий)

JIRA - История изменений

AlexanderSokolov в 10:56, 26 июля 2018

BenderBot: 1 версия

VitaliyFilippov: Изменение синтаксиса конфиденциальных данных для репликации

BenderBot: 1 версия

StasFomin: «Jira» переименована в «JIRA»