Как внедрить Atlassian Jira + Confluence в корпорации. Технические вопросы

Планируете внедрение ПО Atlassian (Jira, Confluence)? Не хотите допустить жестоких ошибок в проектировании, которые потом придётся решать в последний момент?


Тогда вам сюда — рассматриваем внедрение Atlassian Jira + Confluence в корпорации с учётом различных технических аспектов.
Здравствуйте, я являюсь руководителем центра компетенции по продуктам Atlassian в РСХБ (Россельхозбанк) и отвечаю за развитие Системы управления жизненным циклом (СУЖЦ) построенной на программных продуктах Jira и Confluence.

В этой статье опишу технические аспекты построения СУЖЦ. Статья будет полезна всем, кто планирует к внедрению или занимается развитием систем построенных на ПО Atlassian в корпоративном окружении. Статья не требует специальных знаний и рассчитана на начальный уровень знакомства с продуктами компании Atlassian. Статья будет полезна администраторам, владельцам продукта, руководителям проектов, архитекторам, всем кто планирует внедрение систем на основе ПО Atlassian.

Введение

В статье будут рассмотрены технические вопросы внедрения Системы управления жизненным циклом (СУЖЦ) в корпоративном окружении. Давайте вначале определим, что же это значит.

А что значит корпоративное решение?

Это значит решение:

1. Масштабируемое. В случае роста нагрузки, существует техническая возможность нарастить мощность системы. Разделяют горизонтальное и вертикальное масштабирование — при вертикальном масштабировании наращивается мощность серверов, при горизонтальном масштабировании увеличивается количество серверов для работы системы.
2. Отказоустойчивое. Система останется доступной при выходе из строя одного элемента. В общем случае для корпоративных систем не требуется отказоустойчивости, но мы будем рассматривать именно такое решение. У нас в системе планируется несколько сотен конкурентных пользователей и простои будут очень критичны.
3. Поддерживаемое. Решение должно находиться на поддержке у вендора. ПО без поддержки должно замещаться собственными разработками или другим ПО с поддержкой.
4. Установка Self-managed (On-premise). Self-managed — это возможность устанавливать ПО не в облаке, а на собственных серверах. Если быть точнее, то это все варианты установки не SaaS. В этой статье мы будем рассматривать варианты установки только Self-managed.
5. Возможность независимой разработки и тестирования. Для организации предсказуемых изменений в системе, требуются отдельные система для разработки (изменений в самой системе), система тестирования (Staging) и продуктивная система для работы пользователей.
6. Другое. Поддерживает различные сценарии аутентификации, поддерживает аудит логи, имеет настраиваемую ролевую модель и т.д.

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

А что такое Система управление жизненным циклом (СУЖЦ)?

Если коротко, то в нашем случае это Atlassian Jira и Atlassian Confluence — система предоставляющая инструментарий для организации коллективной работы. Система не «навязывает» правила организации работы, а предоставляет разнообразный инструментарий для работы, это и Scrum, и Kanban-доски, и водопадная модель, и масштабируемый Scrum и т.д.
Название СУЖЦ не является отраслевым термином или общеупотребительным понятием, это просто название системы в нашем Банке. СУЖЦ для нас не является системой баг-трэккинга, не является системой Управления инцидентами и системой Управления изменениями.
В системе конечно же присутствует функционал и для баг-трэккинга, и для регистрации инцидентов, и для управления изменениями. И для тех или иных задач этот функционал используется. Но нельзя сказать, что все баги или все инциденты или все изменения регистрируется в нашей системе. В каждом конкретном случае своя специфика. Если какое-то подразделение использует Jira и ведёт там изменение, то для данного изменения, данная команда может решить вести там все баги, все изменения, все инциденты. Но это локальное решение одной отдельной команды, для одной конкретной задачи.

Что в себя включает внедрение?

Внедрение решения состоит из множества технических и организационных вопросов:

• Выделение технических мощностей.
• Закупка ПО.
• Создание команды по внедрению решения.
• Установка и конфигурация решения.
• Разработка архитектуры решения. Ролевой модели.
• Разработка эксплуатационной документации, включая инструкции, регламенты, технический проект, положения и т.д.
• Изменение процессов компании.
• Создание команды поддержки. Разработка SLA.
• Обучение пользователей.
• Другое.

В данной статье мы рассмотрим технические аспекты внедрения, без деталей по организационной составляющей.

Особенности Atlassian

Компания Atlassian является лидером во многих сегментах:

• Gartner Magic Quadrant for Enterprise Agile Planning Tools
  (Лидерство обусловлено удачным приобретением AgileCraft со своим облачным решением)
  
• Global Application Lifecycle Management Tools Market Share
  
  

Продукты компании Atlassian обладают всеми необходимыми корпоративными функциями. Я отмечу следующие особенности:

1. Решения Atlassian основываются на веб-сервере Java Tomcat. ПО Apache Tomcat идёт в составе ПО Atlassian, как часть инсталляции, изменить маджор-версию Apache Tomcat, установленного в составе ПО Atlassian, нельзя. Изменить минорную версию можно, такое действие может требоваться, если версия устарела и содержит уязвимости — после этого обновления Atlassian не будет поддерживать решение. Единственная возможность не потерять поддержки, это ждать обновления от Atlassian, с более новой версией Apache Tomcat. Сейчас, например, в актуальных версиях Jira идёт Apache Tomcat 8.5.42, а в Confluence идёт Apache Tomcat 9.0.33 (как видим, маджорные версии Tomcat в разных продуктах различные).
   (Спасибо Max Max из Atlassian User Group Moscow, за замечание про версии Tomcat.)
2. Удобный интерфейс, реализованы лучшие практики доступные на рынке для данного класса ПО.
3. Полностью настраиваемое решение. С доработками можно реализовать любое изменение базового функционала для пользователя.
4. Развитая экосистема. Есть несколько сотен партнёров: https://partnerdirectory.atlassian.com, в том числе 16 партнёров в России. Именно через партнёров в России можно купить ПО Atlassian, плагины, пройти обучение. Именно партнёры разрабатывают и поддерживают большинство плагинов.
5. Магазин приложений (плагины): https://marketplace.atlassian.com. Плагины значительно расширяют функционал ПО Atlassian. Базовый функционал ПО Atlassian достаточно скромный, практически для любых задач возникает необходимость установки дополнительных плагинов бесплатно или за дополнительные деньги. Поэтому затраты на ПО могут оказаться значительно выше, чем это оценивалось первоначально.
   На текущий момент в магазине опубликовано несколько тысяч плагинов, почти тысяча из них протестирована и валидирована по программе Data Center approved apps. Такие плагины могут считаться стабильными и подходящими для использования в нагруженных системах.
   Советую щепетильно подойти к вопросу планирования плагинов, это сильно влияет на стоимость решения, многие из плагинов могут привести к нестабильности системы и производитель плагина не оказывать поддержки для решения проблемы.
6. Обучение и сертификации: https://www.atlassian.com/university
7. Поддерживаются механизмы SSO, SAML 2.0.
8. Поддержка масштабируемости и отказоустойчивости есть только в редакциях Data Center. Такая редакция впервые появилась в 2014 году (Jira 6.3). Функциональность редакций Data Center всё время расширяется и дорабатывается (например, возможность single node installation появилась только в 2020 году). Подход к плагинам для редакций Data Center, сильно изменился в 2018 с введением Data Center approved apps.
9. Стоимость поддержки. Стоимость поддержки от вендора, практически равна полной стоимости лицензий ПО. Пример расчёта стоимости лицензий приведён ниже.
10. Отсутствие Long Term релизов. Есть так называемые Enterprise версии, но они, так же как и все остальные версии, поддерживаются 2 года. С тем отличием, что для Enterprise версий выпускаются только исправления, без добавления нового функционала.
11. Расширенные варианты поддержки (за дополнительные деньги). https://www.atlassian.com/enterprise/support-services
12. Поддерживается несколько вариантов СУБД. ПО Atlassian поставляется с бесплатной СУБД H2, данная СУБД не рекомендуется для продуктивного использования. Для продуктивного использования поддерживаются следующие СУБД: Amazon Aurora (Data Center only) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Есть ограничения по поддерживаемым версиям и часто поддерживаются только старые версии, но для каждой СУБД есть версия, с поддержкой вендора:
    Jira supported platforms,
    Confluence supported platforms.

Техническая архитектура

Пояснения к схеме:

• На схеме приведена реализация в нашем Банке, данная конфигурация приводится, как пример и не является рекомендованной.
• nginx предоставляет функционал reverse-proxy и для Jira, и для Confluence.
• Отказоустойчивость СУБД реализовывается средствами СУБД.
• Перенос изменений между средами производится с использованием плагина Configuration Manager for Jira.
• AppSrv на схеме — это собственный сервер приложений для отчётности, не использует ПО Atlassian.
• БД EasyBI создана для построения кубов и отчётности с использованием плагина eazyBI Reports and Charts for Jira.
• Сервис Confluence Synchrony (компонента, позволяющая производить одновременное редактирование документов) не выделен в отдельную инсталляцию и запускается совместно с Confluence, на том же сервере.

Лицензирование

Вопросы лицензирования Atlassian заслуживают отдельной статьи, тут упомяну только общие принципы.
Главные вопросы с которыми мы встретились — это вопросы лицензирования редакций Data Center. Особенности лицензирования для редакций Server и Data Center:

1. Лицензия для редакции Server бессрочная и покупатель может использовать ПО даже после истечения лицензии. Но после истечения лицензии покупатель лишается права получать поддержку по продукту и обновлять ПО на актуальные версии.
2. Лицензирование производится по количеству пользователей в системе 'JIRA Users' global permission. При этом не важно, пользуются они системой или нет — даже если пользователи не заходили в систему ни разу, все пользователи будут учтены для лицензии. В случае превышения количества лицензированных пользователей, решением будет удалить полномочие 'JIRA Users' у части пользователей.
3. Лицензия на Data Center фактически является подпиской. Требуется ежегодная оплата лицензии. При истечении срока, работа с системой будет заблокирована.
4. Стоимость лицензий может изменяться с течением времени. Как показывает практика, в большую сторону и, возможно, существенно. Поэтому если у вас в этом году лицензии стоят одну сумму, то на следующий год стоимость лицензий может вырасти.
5. Лицензирование производится по пользователям по tier (например, уровень 1001-2000 пользователей). Есть возможность перейти на более высокий tier, с доплатой.
6. При превышении количества лицензируемых пользователей, новые пользователи будут создаваться без права входить в систему ('JIRA Users' global permission).
7. Плагины можно лицензировать только на то же количество пользователей, что и основное ПО.
8. Лицензировать требуется только продуктивные инсталляции, для остальных можно получить Developer license: https://confluence.atlassian.com/jirakb/get-a-developer-license-for-jira-server-744526918.html.
9. Для покупки сопровождения, требуется покупка Renew Software maintenance — стоимость равняется приблизительно 50% от стоимости первоначального ПО. Такая возможность не доступна для Data Center и не распространяется на плагины — для их поддержки придётся платить полную стоимость ежегодно.
   Таким образом, годовая поддержка ПО стоит более 50% от полной стоимости ПО в случае редакции Server и 100% в случае редакции Data Center — это значительно больше, чем у большинства других вендоров. На мой взгляд это значительная минус бизнес-модели Atlassian.

Особенности перехода с редакции Server на Data Center:

1. Переход с редакции Server на Data Center платный. Стоимость можно найти тут https://www.atlassian.com/licensing/data-center.
2. При переходе с редакции Server на Data Center платить за смену редакции у плагинов не требуется — плагины для редакции Server будут функционировать. Но продлевать лицензии для плагинов уже нужно будет обязательно для редакции Data Center.
3. Вы можете использовать плагины, для которых нет версии для использования с редакциями Data Center. При этом, конечно, такие плагины могут работать некорректно и лучше заранее предусмотреть альтернативу таким плагинам.
4. Переход на редакцию Data Center осуществляется установкой новой лицензии. При этом лицензия для редакции Server по-прежнему остаётся доступной.
5. Нет никаких функциональных различий между редакциями Data Center и Server для пользователей, все различия только в функциях для администрирования и технических возможностях инсталляции.
6. Стоимость ПО и плагинов различается для редакций Server и Data Center. Разница в стоимости часто составляет менее 5% (не принципиально). Пример расчёта стоимости приведён ниже.

Функциональный объём внедрения

Базовая поставка ПО Atlassian включает огромное количество возможностей, но зачастую возможностей, предоставляемых системой сильно не хватает. Иногда даже простейшие функции недоступны в базовой поставке, поэтому без плагинов не обойтись практически при любом внедрении. При этом важно понимать, Jira — это платформа, здесь можно запрограммировать любой функционал и плагины — это платная реализация дополнительного функционала. Для системы Jira мы используем следующие плагины (картинка кликабельна):


Для системы Confluence мы используем следующие плагины (картинка кликабельна):


Комментарии к таблицам с плагинами:

• Все цены приведены из расчёта 2000 пользователей;
• Приведены цены на основе цен указанных https://marketplace.atlassian.com, реальная стоимость (со скидками) получается ниже;
• Как видим, итоговая сумма практически не отличается для редакций Data Center и Server;
• Для использования отобраны плагины только с поддержкой редакции Data Center. Остальные плагины мы исключили из планов, для стабильности системы.

Функционал кратко описан в столбце Комментарий. Дополнительные плагины расширили функционал системы:

• Добавлено несколько визуальных инструментов;
• Улучшены интеграционные механизмы;
• Добавлен инструментарий для проектов по водопадной модели;
• Добавлен инструментарий для масштабируемого Scrum, для организации работы больших проектных команд;
• Добавлен функционал для ведения учёта времени;
• Добавлен инструментарий для автоматизации операций и конфигурирования решения;
• Добавлен функционал для упрощения и автоматизации администрирования решения.

Дополнительно мы используем плагин собственной разработки.
На рабочие места пользователей планируем установить Atlassian Companion app. Данное приложение позволяет редактировать файлы во внешних приложениях (MS Office) и возвращать их обратно в Confluence (check-in).
Приложение для рабочих мест пользователей (толстый клиент) ALM Works Jira Client https://marketplace.atlassian.com/apps/7070 решили не использовать из-за плохой поддержки вендором и отрицательных отзывов.
Для интеграции с MS Project у нас используется самописное приложение, которое позволяет обновлять статусы Issue в MS Project из Jira и наоборот. В будущем, для тех же целей, планируем использовать платный плагин Ceptah Bridge — JIRA MS Project Plugin, который устанавливается, как надстройка на MS Project.
Интеграция с внешними приложениями реализовывается через Application Links. При этом, для приложений Atlassian интеграции преднастроены и работают сразу после настройки, например, можно вывести на страницу в Confluence информацию об Issues в Jira.
Для доступа к серверам Jira и Confluence используется REST API: https://developer.atlassian.com/server/jira/platform/rest-apis.
SOAP и XML-RPC API deprecated и недоступны в новых версиях для использования.

Заключение

Итак, мы рассмотрели технические особенности внедрения системы на основе продуктов Atlassian. Предложенное решение представляет собой одно из возможных решений и хорошо подходит для корпоративного окружения

Предложенное решение — масштабируемое, отказоустойчивое, сдержит три среды для организации разработки и тестирования, содержит все необходимые элементы для совместной работы в системе и предоставляет широкий спектр инструментов для управления проектами.

С радостью отвечу на вопросы в комментариях.