Обучающие материалы для стажеров на Jira Administration

Привет!
Здесь ты найдешь материалы для обучения по направлению 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 компании проекты могут быть разделены на следующие:
- OPS project
- DEV project
- FIN project
- HR project
Если у нас в компании разработка ведется по нескольким векторам (например, мобильная разработка / 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
Все поля условно делятся на три категории:
- System fields (системные поля. Вы не можете добавлять новые поля сюда. С этими полями мы можем работать следующим образом – скрывать для всего проекта / делать обязательными / меня контекст поля)
- Custom fields (мы будем активно использовать данный функционал, внимательно ознакомьтесь с статьей)
- Scripted fields (с помощью различных аддонов мы можем добавлять поля содержащие код на Groovy под капотом. Мы будем рассматривать только скриптовые поля реализованные плагином Script Runner)
Пример: необходимо сделать поле считающее сумму значений нескольких сумм в задаче (например, общая стоимость закупок)
Задание:
- Добавьте два custom поля в задачи OPS. Поля должны принимать только числа.
- Пусть поле 1 отражает стоимость одной единицы оборудования.
- Пусть поле 2 отражает кол-во единиц товара.
- Добавьте Scripted field считающее общую стоимость всего оборудования (поле1 х поле2).
Screens
Экраны (screens) это странички, отражающие поля задач нам в тот или иной момент.
Есть три вида экранов:
- Экран создания задачи (когда мы создаем задачу мы видим именно экран создания задачи)
- Экран просмотра (когда мы просто открыли любую задачу, отображается именно экран просмотра задачи)
- Экран редактирования (нажав кнопку Редактировать или даже изменяя одно поле у нас сразу подключается этот экран. Если мы убираем поле с этого экрана – редактировать его уже будет невозможно)
Структура
Экраны объединяются в схемы экранов (screen schemes).
Схемы экранов объединяются в Схемы по типам задач (Issue Type Screen Scheme)
Что это значит?
У нас есть разные типы задач (см. выше).
Например, в проекте Ops у нас есть Task, Epic и есть Закупка.
Логично, что поля должны отличаться в каждом типе задачи.
- создаем Схему по типам задач – “OPS issue type screen scheme”
- создаем Схемы экранов – “Ops-task-screen-scheme / Ops-epic-screen-scheme / Ops-purchase-screen-scheme”
- создаем Экраны “Ops-create-task-screen / Ops-edit-task-screen / Ops-view-task-screen”
Аналогично создаем экраны для двух типов задач. - Теперь задача связать эти сущности.
- “OPS issue type screen scheme” будет содержать в себе:
- для задач типа Task у нас используется “Ops-task-screen-scheme”
- для задач типа Epic у нас используется “Ops-task-screen-scheme”
- для задач типа Закупка у нас используется “Ops-purchase-screen-scheme”
- “Ops-task-screen-scheme” будет содержать в себе:
- Для создания задач типа task у нас используется “Ops-create-task-screen“
- Для просмотра задач типа task у нас используется “Ops-view-task-screen“
- Для редактирования задач типа task у нас используется “Ops-edit-task-screen“
- По аналогии для Epic и Purchases.
- “OPS issue type screen scheme” будет содержать в себе:
❗️Крайне рекомендую использовать именно такие правила именования, чтобы потом не путаться во всем многообразии сущностей.
Задание:
- Реализуйте схемы для ОПС проекта, как описано в главе.
- Поля из задания главы Fields должны быть отображены только в задачах типа закупки – проекта OPS
- Поле 1 и поле 2 из задания главы Fields не должны быть доступны при просмотре и редактировании, только при создании.
Workflows
Схема отображения бизнес процесса. Ознакомьтесь с этой статьей .
Можно использовать один воркфлоу для нескольких типов задач в разных проектах.
Условно Workflows делятся на:
- Statuses (статусы)
- 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 администрирование. Дальше вам рекомендуется углубляться глубже в каждую из вышеупомянутых тем и реализовывать все более сложные скрипты. Удачи!
Подпишитесь на блог WB—Tech
Никакого спама, только анонсы новых статей