Привет!
Здесь ты найдешь материалы для обучения по направлению Jira Administration.
Если появились вопросы, пиши в Slack в канал #jira. Надеемся, ты справишься и станешь частью команды.
Успехов в обучении!
Jira – это инструмент управления проектами, который помогает оптимизировать работу команды. Такую формулировку вы найдете сразу, загуглив термин Jira.
По факту это цифровое отображение ваших бизнес процессов и задач внутри вашей компании/команды. С его помощью можно легко отслеживать, анализировать и структурировать весь жизненный цикл активностей вашей компании.
Такой формулировки вам будет достаточно для любого интервью.
При решении использовать 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 версию.
В управлении проектами в наше время есть два основных подхода – Waterfall и Agile.
Как видно на картинке, Agile – это итеративный метод управления проектами (цикличный).
Данная методология получила большую популярность в IT благодаря своим преимуществам, и Jira поможет вам внедрить и использовать все ее сильные стороны.
Тут можно ознакомиться с основными инструментами Agile в Jira.
Два основных направления Agile – это Scrum и Kanban (вы могли видеть эти непонятные термины чуть ли ни в каждой вакансии).
Обязательно прочтите данную прекрасную статью о том что это и с чем едят.
По факту в компаниях чаще для разработки используют Scrum подход с их двухнедельными спринтами, а для операционных процессов и разных ops отделов чаще используют Kanban.
Скоро вы поймете, зачем нам это нужно)
Перед тем как мы начнем, предлагаю создать тестовой инстанс c нашей Cloud Jira (он бесплатный для команд до 10 человек).
Именно там мы будем создавать свои первые проекты и тренироваться внедрять инструменты.
Я рекомендую всегда при внедрении нового проекта в продакшн сначала реализовать его в нашей тестовой Jira. Там же можно провести показ для основных стейкхолдеров (заказчиков). И удостоверившись, что все работает корректно, переносить изменения в нашу “рабочую” Jira.
Задание:
Теперь перейдем непосредственно к основным сущностям Jira.
При администрировании Jira все начинается с понимания вами бизнес процессов компании. Помните нашу формулировку что такое Jira?
Если говорить о сущностях внутри Jira, все начинается с проекта.
Проект – логическое объединение в рамках одного или нескольких бизнес-процессов. Обычно проект отражает структуру внутри какого-то конкретного отдела / департамента.
В обычной IT компании проекты могут быть разделены на следующие:
Если у нас в компании разработка ведется по нескольким векторам (например, мобильная разработка / backend / frontend – можно вместо проекта DEV сделать сразу 3 проекта по этим векторам.
При создании проекта Jira предлагает вам использовать один из готовых шаблонов (например, Scrum и Kanban)
А также вы можете выбрать team-managed проекта или company-managed (подробнее тут)
Задание:
Основной инструмент для поиска информации в Jira – JQL (Jira Query Language). Похоже на SQL на минималках.
Тут вы найдете достаточную информацию по данной теме. Внимательно с ней ознакомьтесь.
Если вы знакомы с базовым программированием вам будет не сложно. Логические операторы AND OR, круглые скобки, операторы сравнения – все присутствует в этом прекрасном и понятном языке.
На основании этих запросов мы будем формировать Доски, создавая фильтры, дашборды и еще много всего интересного.
Задание:
Issue Types
Типы задач – сущность которая позволяет нам разделять вектора бизнес процессов внутри одного проекта.
Эта может быть например по классике:
Для проекта “Рекрутинг” могут быть:
Для проекта “Закупка” могут быть:
Все что нужно, чтобы отобразить бизнес процесс.
Вы можете определить одни и те же Типы задач для нескольких проектов. Или конкретный проект может содержать уникальные для себя типы задач.
Типы задач могут быть дочерними (по дефолту это тип задач – Subtasks, могут быть универсальными). Можно поменять данную структуру в Issue type hierarchy
Виды задач (issue types) объединяются в Схемы по типам задач (Issue Type Schemes)
Задание:
Все поля условно делятся на три категории:
Задание:
Экраны (screens) это странички, отражающие поля задач нам в тот или иной момент.
Есть три вида экранов:
Экраны объединяются в схемы экранов (screen schemes).
Схемы экранов объединяются в Схемы по типам задач (Issue Type Screen Scheme)
Что это значит?
У нас есть разные типы задач (см. выше).
Например, в проекте Ops у нас есть Task, Epic и есть Закупка.
Логично, что поля должны отличаться в каждом типе задачи.
❗️Крайне рекомендую использовать именно такие правила именования, чтобы потом не путаться во всем многообразии сущностей.
Задание:
Схема отображения бизнес процесса. Ознакомьтесь с этой статьей .
Можно использовать один воркфлоу для нескольких типов задач в разных проектах.
Условно Workflows делятся на:
Вы можете соединять статусы транзакциями в одну/обе стороны.
Внутри статусов и транзакций существуют доп. настройки.
Для статусов это:
Для транзакций это:
Часто на практике используются именно Conditions / Validators / Postfunctions. Очень часто в них встраиваются скрипты именно из Script Runner (об этом позже). С их помощью можно сделать практически что угодно с вашим бизнес процессом.
Подробно про все эти сущности можно почитать с примерами тут.
Workflow schemes описывают в каких проектах какой тип задач использует какой Workflow.
Задание:
То, как мы организовываем работу с пользователями в Jira.
Эта сущность определяет верхнеуровневый доступ к тем или иным продуктам Atlassian (в большинстве случаев, это доступы к Jira Software/Jira Service Management/Confluence).
!Помните, что за доп. доступы может взиматься доп. плата. Возможно, не всем сотрудникам вашей компании нужен доступ к Jira Service Management/Confluence.
Группы пользователей. В крупных компаниях, при заведении сотрудника, его определяют в какую-то из LDAP групп, подвязывая все его доступы к доступам этой группы. Этим обычно занимаются OPS.
Мы начнем, конечно, с простого. Когда мы вручную добавляем нового сотрудника, высылая ему приглашение в нашу Jira и вручную добавляя его в нужные нам группы.
Хорошо заранее понимать, где будет работать сотрудник и какова его роль.
Мы должны четко понимать структуру компании, разделив ее на проекты и группы пользователей.
Добавляем сотрудника в нужную группу.
Задание:
Схемы прав доступа. Они позволяют верхнеуровнево ограничивать, к какому функционалу и у каких групп/проектных ролей/конкретных пользователей и т.д. есть доступ.
Good practice будет:
– Объединить логически проекты в группы по типам доступов;
– Составить для каждой группы свою Permission scheme. Применить ко всем проектам, относящиеся к ним схемы;
– Не ссылаться на конкретных сотрудников внутри схемы;
– Ссылаться на проектные роли для выдачи доступов (таким образом, создав проектную роль Staff и привязав доступы к ней, у нас одна Permission схема сможет распространяться на два разных проекта, но в одном проекте Staff будет = группе разработчиков, а в другом – например, опсов.
Задание:
Уведомления. Мы уведомляем внешних/внутренних пользователей о тех или иных событиях и обновлениях.
Есть различные каналы для уведомлений. Как стандартные, так и с помощью иных инструментов.
Лично я вижу в стандартных уведомления главный минус – отсутствие гибкости. Со временем вы должны научиться по бизнес требованию сами определять какой именно вид уведомления нужно применять.
Советую следовать одному правилу: если что-то можно реализовать “просто”, то не нужно усложнять)
Стандартные уведомления через почту.
Настраивается непосредственно отдельно для каждого проекта и распространяется на стандартные триггеры типа: Issue created/Issue updated/Issue Commented/Issue Assigned и другие.
Сложность: низкая
Интеграция со слак. Осуществляется через стандартное приложение и настраивается также отдельно для каждого проекта.
Выделяется отдельный воркспейс и канал для уведомлений.
Из минусов – нельзя настроить уведомления в личные сообщения.
Сложность: низкая
Встроенный плагин Automations также умеет отправлять уведомления. Как на почту, так и в слак.
Настраиваются как глобально, так и для отдельного проекта (помните, что при использовании глобальных/мульти проектных автоматизаций расходуется usage (лимит) и нужно будет покупать ПРО версию).
Триггеры общие как и в других автоматизациях данного плагина.
Удобно настраивать кастомизацию с помощью smart values.
Сложность: средняя
Post Functions
Экзотика.
Пост функции, которые мы рассматривали выше, тоже умеют отправлять уведомления.
Низкая кастомизация и нужно копировать код по много раз для каждой транзакции. Рекомендую только когда вы точно знаете, почему выбираете именно этот метод
Сложность: средняя
API scripts
Продвинутый инструмент для уведомлений.
Максимально гибкий способ, может быть реализован как внутренним инструментом (Scriptrunner listener/post function), так и внешним (внешние скрипты, low-code инструменты).
В основе данного подхода лежит написание скриптов с использованием пост запросов, отправляющих уведомления по нужному нам каналу.
Пока что вам рано использовать данный метод, но со временем это станет одним из ваших любимых инструментов.
Сложность: высокая
Задание:
Автоматизации наших процессов с помощью встроенного и (в lite версии) бесплатного инструмента. Удобный инструмент с низким порогом входа. Мы уже познакомились с частью его функционала в предыдущей главе.
При этом функционал lite версии может компенсировать 80% наших запросов.
Я рекомендую подробно ознакомиться с документацией, ведь в жизни начинающего Jira администратора, автоматизации с помощью этого инструмента будут встречаться очень часто.
Автоматизации делятся на глобальные (мультипроектные) и автоматизации для конкретного проекта. Про отличие уже разбирали в предыдущей главе.
Каждая автоматизация условно делится на 3 составляющих:
– триггер (событие при котором срабатывает автоматизация);
– условия (опционально) – условия когда то или иное действие (цепочка действий) будет выполняться;
– действие (непосредственно что выполнится в случае если триггер сработает).
Задание:
В главах выше мы уже сталкивались не раз с ссылками на те или иные инструменты этого плагина.
Почти все вакансии на Jira администратора требуют знания этого плагина, и это неспроста.
Функционал плагина делится условно на две составляющих: готовые инструменты, доступные через интерфейс скриптраннера и скрипты, которые мы пишем сами.
К готовым инструментам относятся такие сущности, как listeners/script variables/fragments и т.д. (подробнее тут).
Вы можете самостоятельно изучить их функционал.
Основным инструментом, который мы рассмотрим в этой главе является именно console и написание скриптов.
В основе написания скриптов у нас лежит язык программирования Groovy и написание API-запросов.
В консоле есть изначально несколько примеров, на основании которых вы можете изучить как это работает.
Я рекомендую тестировать все ваши скрипты в консоли тестовой Jira и только потом переносить их на продакшн рабочего инстанса (в рабочую Jira).
Также если вы намерены серьезно разобраться в направлении, которым занимаетесь, вам не обойтись без базовых знаний ООП (тут подойдет любой язык, но выгоднее будет взять за основу Java) и понимания основных инструментов в программировании. Без них вы не сможете писать чистый и эффективный код.
Задание:
Друзья, вы ознакомились с вводным курсом в Jira администрирование. Дальше вам рекомендуется углубляться глубже в каждую из вышеупомянутых тем и реализовывать все более сложные скрипты. Удачи!
Спасибо, что прочитал материалы. Если чувствуешь, что готов к финальному заданию, переходи по ссылке. Там тебя ждет файл с финальным тестом.
Напомним, мы не контролировали твое обучение, и как быстро ты сделаешь задание — нам тоже не важно. Делай в своем темпе и пиши, как будет готово.
Никакого спама, только анонсы новых статей
ИП Гришанин Кирилл Олегович
ИНН 774313842609
Б. Новодмитровская ул., 36, стр. 12, вход 6,
Москва, Россия, 127015
Ahad Ha'am 54,Tel Aviv-Yafo,Израиль