Привет!

Здесь ты найдешь материалы для обучения по направлению Jira Administration.

Если появились вопросы, пиши в Slack в канал #jira. Надеемся, ты справишься и станешь частью команды.

Успехов в обучении!

Jira – what it is and why it matters?

Jira – это инструмент управления проектами, который помогает оптимизировать работу команды. Такую формулировку вы найдете сразу, загуглив термин Jira.

По факту это цифровое отображение ваших бизнес процессов и задач внутри вашей компании/команды. С его помощью можно легко отслеживать, анализировать и структурировать весь жизненный цикл активностей вашей компании.
Такой формулировки вам будет достаточно для любого интервью.

Cloud / Server – main differences

При решении использовать Jira как продукт внутри компании, вы столкнетесь с тем, что существует несколько разных видов Jira как ПО. Два основных используемых – это Jira Server и Jira Cloud. Есть также Jira Data Center.
Мы опустим этот вид, он практически не используется сейчас компаниями в РФ и практические идентичен Server версии.
Вы можете посмотреть основные отличия Server версии и Cloud по ссылке

От себя отмечу следующие пункты: 

	Server	Cloud
Хранение данных	На локальных серверах, расположенных непосредственно в ЦОД компании	На облачных мощностях, расположенных в ЦОД Atlassian (Австралия)
Доступ к Базе данных	Полный доступ	Отсутствует прямой доступ. Все запросы делаются с помощью API
Backup	Необходимо самому настроить автоматическое резервное копирование	Копирование происходит автоматически и хранится в облаке 30 дней. Вы также можете дополнительно выполнять offline копирование вручную

Отличий много. Я бы сказал, что это на первый взгляд это совершенно разные продукты.
Из минусов Cloud версии я бы отметил отсутствие прямого доступа к Базе данных, которое ограничивает наши возможности в написании скриптов API эндпоинтами, а также отсутствие Script Runner Behaviours (на момент написания статьи Atlassian активно помогала в интеграции данной фичи в Cloud продукт)
В гайде мы будем рассматривать именно Cloud версию.

Agile. What you need to know.

В управлении проектами в наше время есть два основных подхода – Waterfall и Agile.

Как видно на картинке, Agile – это итеративный метод управления проектами (цикличный).
Данная методология получила большую популярность в  IT благодаря своим преимуществам, и Jira поможет вам внедрить и использовать все ее сильные стороны.

Тут можно ознакомиться с основными инструментами Agile в Jira.

Два основных направления Agile – это Scrum и Kanban (вы могли видеть эти непонятные термины чуть ли ни в каждой вакансии).

Обязательно прочтите данную прекрасную статью о том что это и с чем едят.

По факту в компаниях чаще для разработки используют Scrum подход с их двухнедельными спринтами, а для операционных процессов и разных ops отделов чаще используют Kanban.

Скоро вы поймете, зачем нам это нужно)

Перед тем как мы начнем, предлагаю создать тестовой инстанс c нашей Cloud Jira (он бесплатный для команд до 10 человек).

Именно там мы будем создавать свои первые проекты и тренироваться внедрять инструменты.

Я рекомендую всегда при внедрении нового проекта в продакшн сначала реализовать его в нашей тестовой Jira. Там же можно провести показ для основных стейкхолдеров (заказчиков). И удостоверившись, что все работает корректно, переносить изменения в нашу “рабочую” Jira.

Задание:

• Переходим сюда и выполняем шаги указанные в гайде

General instruments

Теперь перейдем непосредственно к основным сущностям Jira.

Your first Project

При администрировании Jira все начинается с понимания вами бизнес процессов компании. Помните нашу формулировку что такое Jira?

Если говорить о сущностях внутри Jira, все начинается с проекта.
Проект – логическое объединение в рамках одного или нескольких бизнес-процессов. Обычно проект отражает структуру внутри какого-то конкретного отдела / департамента.
В обычной IT компании проекты могут быть разделены на следующие:

Если у нас в компании разработка ведется по нескольким векторам (например, мобильная разработка / backend / frontend – можно вместо проекта DEV сделать сразу 3 проекта по этим векторам.

При создании проекта Jira предлагает вам использовать один из готовых шаблонов (например, Scrum и Kanban)
А также вы можете выбрать team-managed проекта или company-managed (подробнее тут)

Задание:

• Создайте в тестовой среде несколько проектов. DEV сделайте скрам проектом, OPS – канбан проектом. В чем их различия?
• В каждом проекте создайте по несколько задач с разными названиями и описанием.
• В 2х задачах в каждом проекте добавьте комментарии со словом test, а в 2х со словом production. Несколько задач оставьте без комментариев.

JQL

Основной инструмент для поиска информации в Jira – JQL (Jira Query Language). Похоже на SQL на минималках.
Тут вы найдете достаточную информацию по данной теме. Внимательно с ней ознакомьтесь.
Если вы знакомы с базовым программированием вам будет не сложно. Логические операторы AND OR, круглые скобки, операторы сравнения – все присутствует в этом прекрасном и понятном языке.
На основании этих запросов мы будем формировать Доски, создавая фильтры, дашборды и еще много всего интересного.

Задание:

• Создайте запрос и найдите все issues подпадающие под него.
• Запрос должен отобразить только задачи в проекте DEV, содержащие комментарий со словом test или production.
• Задачи без комментариев не должны быть отображены.

Issue Types
Типы задач – сущность которая позволяет нам разделять вектора бизнес процессов внутри одного проекта.
Эта может быть например по классике:

• Epic
• Story
• Task

Для проекта “Рекрутинг” могут быть:

• Вакансия
• Карточка “Кандидата”

Для проекта “Закупка” могут быть:

• Плановая закупка
• Внеплановая
• Групповая закупка

Все что нужно, чтобы отобразить бизнес процесс.

Вы можете определить одни и те же Типы задач для нескольких проектов. Или конкретный проект может содержать уникальные для себя типы задач.

Типы задач могут быть дочерними (по дефолту это тип задач – Subtasks, могут быть универсальными). Можно поменять данную структуру в Issue type hierarchy

Структура

Виды задач (issue types) объединяются в  Схемы по типам задач (Issue Type Schemes)

Задание:

• Создайте схемы по типам задач для проектов OPS и DEV.
• Оба проекта должны содержать только типы задач: Epic и Task.
• Также добавьте тип задачи “Закупка” для проекта OPS.

Fields

Все поля условно делятся на три категории:

1. System fields  (системные поля. Вы не можете добавлять новые поля сюда. С этими полями мы можем работать следующим образом – скрывать для всего проекта / делать обязательными / меня контекст поля)
2. Custom fields (мы будем активно использовать данный функционал, внимательно ознакомьтесь с статьей)
3. Scripted fields (с помощью различных аддонов мы можем добавлять поля содержащие код на Groovy под капотом. Мы будем рассматривать только скриптовые поля реализованные плагином Script Runner)
   Пример: необходимо сделать поле считающее сумму значений нескольких сумм в задаче (например, общая стоимость закупок)

Задание:

• Добавьте два custom поля в задачи OPS. Поля должны принимать только числа.
• Пусть поле 1 отражает стоимость одной единицы оборудования. 
• Пусть поле 2 отражает кол-во единиц товара.
• Добавьте Scripted field считающее общую стоимость всего оборудования (поле1 х поле2).

Screens

Экраны (screens)  это странички, отражающие поля задач нам в тот или иной момент. 

Есть три вида экранов:

1. Экран создания задачи (когда мы создаем задачу мы видим именно экран создания задачи)
2. Экран просмотра (когда мы просто открыли любую задачу, отображается именно экран просмотра задачи)
3. Экран редактирования (нажав кнопку Редактировать или даже изменяя одно поле у нас сразу подключается этот экран. Если мы убираем поле с этого экрана – редактировать его уже будет невозможно)

Структура

Экраны объединяются в схемы экранов (screen schemes).
Схемы экранов объединяются в  Схемы по типам задач (Issue Type Screen Scheme)

Что это значит?

У нас есть разные типы задач (см. выше).
Например, в проекте Ops у нас есть Task, Epic и есть Закупка.
Логично, что поля должны отличаться в каждом типе задачи. 

1. создаем  Схему по типам задач – “OPS issue type screen scheme”
2. создаем Схемы экранов  – “Ops-task-screen-scheme / Ops-epic-screen-scheme / Ops-purchase-screen-scheme”
3. создаем Экраны “Ops-create-task-screen / Ops-edit-task-screen / Ops-view-task-screen”
   Аналогично создаем экраны для двух типов задач.
4. Теперь задача связать эти сущности.
   1. “OPS issue type screen scheme” будет содержать в себе:
      1. для задач типа Task у нас используется “Ops-task-screen-scheme”
      2. для задач типа Epic у нас используется “Ops-task-screen-scheme”
      3. для задач типа Закупка у нас используется “Ops-purchase-screen-scheme”
   2. “Ops-task-screen-scheme” будет содержать в себе:
      1. Для создания задач типа task у нас используется  “Ops-create-task-screen“
      2. Для просмотра задач типа task у нас используется  “Ops-view-task-screen“
      3. Для редактирования задач типа task у нас используется  “Ops-edit-task-screen“
      4. По аналогии для Epic и Purchases.

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

Задание:

• Реализуйте схемы для ОПС проекта, как описано в главе.
• Поля из задания главы Fields должны быть отображены только в задачах типа закупки – проекта OPS
• Поле 1 и поле 2 из задания главы Fields не должны быть доступны при просмотре и редактировании, только при создании.

Workflows

Схема отображения бизнес процесса. Ознакомьтесь с этой статьей .

Можно использовать один воркфлоу для нескольких типов задач в разных проектах.

Условно Workflows делятся на:

1. Statuses (статусы)
2. Transactions (транзакции – процесс перехода из одного статуса на другой. Кнопка с переводом задачи из одного статуса в другой будет называться именем транзакции между этими статусами)

Вы можете соединять статусы транзакциями в одну/обе стороны.

Внутри статусов и транзакций существуют доп. настройки.
Для статусов это: 

• Переход в статус из любой транзакции (all to);
• Сделать статус требующим подтверждения (approver step);
• Status properties (продвинутый уровень – в основном используется для запрета полного редактирования задачи только на определенном статусе или определенными пользователями (project roles). Подробнее тут.

Для транзакций это:

• Отобразить транзакцию на клиентском портале (для проектов Service Management – об этом позже);
• Properties (аналогично с статусами – редко используется);
• Triggers (продвинутый уровень – редко используется);
• Conditions (условие выполнения перехода. Если условие не выполнено, пользователи не увидят даже кнопки для перевода задачи из одного в статуса другой. По факту данное ограничение даже не начинает транзакцию);
• Validators (валидация определенных параметров заявки при выполнении заявки. Пользователи видят кнопку перехода, но если условие не выполнено – вы увидите ошибку с кастомным текстом);
• Post functions (дополнительный действия, выполняющиеся во время выполнения транзакции).

Часто на практике используются именно  Conditions / Validators / Postfunctions. Очень часто в них встраиваются скрипты именно из Script Runner (об этом позже). С их помощью можно сделать практически что угодно с вашим бизнес процессом. 

Подробно про все эти сущности можно почитать с примерами тут.

Структура

Workflow schemes описывают в каких проектах какой тип задач использует какой Workflow.

Задание:

• Создайте отдельные схемы для ваших проектов  OPS  и DEV.
• Сделайте по одному и тому же Workflow для задач типа Epic и Task в обоих проектах OPS и DEV.
• Добавьте такие нужные доп. настройки для Workflow OPS проекта типа Task, которые:
  • Не позволят создавать задачу без внесенных данных о кол-ве единиц закпуаемого оборудования и стоимости одной единицы;
  • Проверять информацию и при введенных значениях = 0 выводит ошибку;
  • Подсказка: реализовать необходимо, используя Conditions и Validators

Users Management

То, как мы организовываем работу с пользователями в Jira.

Product access

Эта сущность определяет верхнеуровневый доступ к тем или иным продуктам Atlassian (в большинстве случаев, это доступы к Jira Software/Jira Service Management/Confluence).

!Помните, что за доп. доступы может взиматься доп. плата. Возможно, не всем сотрудникам вашей компании нужен доступ к Jira Service Management/Confluence.

Groups

Группы пользователей. В крупных компаниях, при заведении сотрудника, его определяют в какую-то из LDAP групп, подвязывая все его доступы к доступам этой группы. Этим обычно занимаются OPS.

Мы начнем, конечно, с простого. Когда мы вручную добавляем нового сотрудника, высылая ему приглашение в нашу Jira и вручную добавляя его в нужные нам группы.

Хорошо заранее понимать, где будет работать сотрудник и какова его роль.

Мы должны четко понимать структуру компании, разделив ее на проекты и группы пользователей.

Добавляем сотрудника в нужную группу.

Project Roles

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

Задание:

• Создайте несколько ненастоящих пользователей через подставные email или иным способом.
• Создайте 2 группы пользователей (разработчики/опсы).
• Создайте проектную роль (сотрудник).
• Для каждого проекта привяжите к проектной роли соответствующую группу.
• Распределите пользователей по соответствующим группам.

Permissions

Схемы прав доступа. Они позволяют верхнеуровнево ограничивать, к какому функционалу и у каких групп/проектных ролей/конкретных пользователей и т.д. есть доступ.


Good practice будет:
– Объединить логически проекты в группы по типам доступов;
– Составить для каждой группы свою Permission scheme. Применить ко всем проектам, относящиеся к ним схемы;

– Не ссылаться на конкретных сотрудников внутри схемы;

– Ссылаться на проектные роли для выдачи доступов (таким образом, создав проектную роль Staff и привязав доступы к ней, у нас одна Permission схема сможет распространяться на два разных проекта, но в одном проекте Staff будет = группе разработчиков, а в другом – например, опсов.

Задание:

• Проверьте какие бывают доступы, изучите каждый, что они делают.
• Создайте отдельную Permission scheme – Company’s common permission scheme.
• Привяжите уровни доступа к двум проектным ролям (сотрудники/тим лид).
• Примените схему к обоим проектам (Dev и Ops).
• Настройте проектную роль в каждом проекте, чтобы она отображала группу пользователей (разработчиков/опсов).
• Как вы организовали доступы тимлидов?
• Проверьте, что все доступы у нужных пользователей из прошлой главы работают.

Notifications

Уведомления. Мы уведомляем внешних/внутренних пользователей о тех или иных событиях и обновлениях.

Есть различные каналы для уведомлений. Как стандартные, так и с помощью иных инструментов.

Лично я вижу в стандартных уведомления главный минус – отсутствие гибкости. Со временем вы должны научиться по бизнес требованию сами определять какой именно вид уведомления нужно применять.

Советую следовать одному правилу: если что-то можно реализовать “просто”, то не нужно усложнять)

Emails

Стандартные уведомления через почту. 

Настраивается непосредственно отдельно для каждого проекта и распространяется на стандартные триггеры типа: Issue created/Issue updated/Issue Commented/Issue Assigned и другие.

Сложность:  низкая

Slack integration

Интеграция со слак.  Осуществляется через стандартное приложение и настраивается также отдельно для каждого проекта.

Выделяется отдельный воркспейс и канал для уведомлений.
Из минусов – нельзя настроить уведомления в личные сообщения.

Сложность:  низкая

Automations

Встроенный плагин Automations также умеет отправлять уведомления. Как на почту, так и в слак.

Настраиваются как глобально, так и для отдельного проекта (помните, что при использовании глобальных/мульти проектных автоматизаций расходуется usage (лимит) и нужно будет покупать ПРО версию).

Триггеры общие как и в других автоматизациях данного плагина.
Удобно настраивать кастомизацию с помощью smart values.

Сложность:  средняя

Post Functions

Экзотика.

Пост функции, которые мы рассматривали выше, тоже умеют отправлять уведомления.

Низкая кастомизация и нужно копировать код по много раз для каждой транзакции. Рекомендую только когда вы точно знаете, почему выбираете именно этот метод

Сложность:  средняя

API scripts

Продвинутый инструмент для уведомлений.

Максимально гибкий способ, может быть реализован как внутренним инструментом (Scriptrunner listener/post function), так и внешним (внешние скрипты, low-code инструменты).

В основе данного подхода лежит написание скриптов с использованием пост запросов, отправляющих уведомления по нужному нам каналу.

Пока что вам рано использовать данный метод, но со временем это станет одним из ваших любимых инструментов.

Сложность:  высокая

Задание:

• Для обоих проектов настройте уведомления reporter через email при его смене.
• Настройте интеграцию с продовым/тестовым Slack. Создайте отдельные каналы (DEV notifications/OPS notifications) и настройте туда уведомления, когда создаются новые.
• Используя Automations реализуйте автоматизацию отправляющую email уведомления для reporter о том, что прилинкованная “дочерняя” задача перешла в статус Done/Closed.

Automations

Автоматизации наших процессов с помощью встроенного и (в lite версии) бесплатного инструмента. Удобный инструмент с низким порогом входа. Мы уже познакомились с частью его функционала в предыдущей главе.

При этом функционал lite версии может компенсировать 80% наших запросов.

Я рекомендую подробно ознакомиться с документацией, ведь в жизни начинающего Jira администратора, автоматизации с помощью этого инструмента будут встречаться очень часто.

Simple Automation review

Автоматизации делятся на глобальные (мультипроектные) и автоматизации для конкретного проекта. Про отличие уже разбирали в предыдущей главе.

Каждая автоматизация условно делится на 3 составляющих:
– триггер (событие при котором срабатывает автоматизация);

– условия (опционально) – условия когда то или иное действие (цепочка действий) будет выполняться;

– действие (непосредственно что выполнится в случае если триггер сработает).

Задание:

• Реализуйте следующую автоматизацию:
  • При создании задачи в проекте Dev типа Epic автоматически создать три задачи с названиями 1, 2, 3 вложенными в Epic.
  • Reporter должен автоматически становиться репортером Epica
  • Задачи должны создаваться с описанием аналогичным описанию Epicа
  • *задача со звездочкой – у задачи номер 2 должно создаться две subtask с названием 2а и 2b и полями reporter / описанием таким же как у Epic
    (подсказка – используйте smart values).

Scriptrunner

В главах выше мы уже сталкивались не раз с ссылками на те или иные инструменты этого плагина.

Почти все вакансии на Jira администратора требуют знания этого плагина, и это неспроста.

Функционал плагина делится условно на две составляющих: готовые инструменты, доступные через интерфейс скриптраннера и скрипты, которые мы пишем сами.

К готовым инструментам относятся такие сущности, как listeners/script variables/fragments и т.д. (подробнее тут).

Вы можете самостоятельно изучить их функционал.

Основным инструментом, который мы рассмотрим в этой главе является именно console и написание скриптов.

В основе написания скриптов у нас лежит язык программирования Groovy и написание API-запросов.

В консоле есть изначально несколько примеров, на основании которых вы можете изучить как это работает.

Я рекомендую тестировать все ваши скрипты в консоли тестовой Jira и только потом переносить их на продакшн рабочего инстанса (в рабочую Jira).

Также если вы намерены серьезно разобраться в направлении, которым занимаетесь, вам не обойтись без базовых знаний ООП (тут подойдет любой язык, но выгоднее будет взять за основу Java) и понимания основных инструментов в программировании. Без них вы не сможете писать чистый и эффективный код.

Задание:

• Установите Scriptrunner приложение в своей тестовой среде (это бесплатно, если у вас <= 10 пользователей).
• Пользуясь документацией, реализуйте сначала в консоли, а затем вставьте в post function, следующий скрипт:
  • Добавьте статус Review для типа эпик в проекте OPS перед финальным статусом;
  • При переходе в этот статус необходимо сменить приоритет эпика на высокий и исполнителя на любого другого конкретного пользователя (имитация reviewer).
  • *задача со звездочкой
    • необходимо в этом же скрипте менять приоритет по аналогии для всех вложенных в эпик задач, независимо от их количества.
    • Отправлять скриптом уведомление reviewer в слак и почту о том, что эпик перешел в данный статус и ожидает его ревью
• Подсказка. 
  • Во время работы с console рекомендую первое время построчно выполнять код, проверяя работоспособность каждой строки;
  • При реализации в консоли вы можете не воспроизводить сам триггер (факт транзакции issue), а воспроизводить только побочные действия (при нажатии кнопки run менять приоритет конкретного эпика и вложенных в него задач).
    
    
    

Друзья, вы ознакомились с вводным курсом в Jira администрирование. Дальше вам рекомендуется углубляться глубже в каждую из вышеупомянутых тем и реализовывать все более сложные скрипты. Удачи!