company_banner

Как внедрить 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 является лидером во многих сегментах:


Продукты компании 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. Предложенное решение представляет собой одно из возможных решений и хорошо подходит для корпоративного окружения

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

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

Комментарии 24

    +1

    А можно я задам вопрос: а как с внедрённым confluence/jira жить? Ну просто до невозможности глючные редакторы, сжирающие нажатия кнопок, что-то постоянно ломающие в вёрстке самым идиотским образом...


    Сколько в своей жизни атласиана видел, столько плевался. У вас QA есть? Если есть, куда он смотрит?

      0
      У нас Atlassian уже лет 5 как внедрен. Более 5 тысяч активных пользователей. Да, Jira тормознутая чуток, и не самая последняя версия, но работает.

      ИМХО мало написали насчет QUAL/PROD окружения. У нас все изменения проходят через QUAL прежде чем попасть в PROD.
        0
        Atlassian совсем не идеален. И многое работает не так как хотелось бы, но я бы не был так категоричен — даже наоборот, у продуктов Atlassian простой, интуитивно понятный интерфейс, очень подходит для большинства пользователей. И сила Atlassian не в редакторе, а в функционале и логике заложенной в продукты.

        Про QA, боюсь не понял вопроса. У системы практически нет никаких интеграций, автоматизированные средства для тестирования Jira не используются.
          0
          Интересно как именно вы переносите конфигурации между тестовыми средами и продуктивом. Плагин этот я знаю, но очень интересны практики, какие проблемы были, как решали, с чем смирились.
            0
            alexkuzko Реальность такая, что все изменения у нас в РСХБ, для Jira мы носим вручную( — по релизам, с ручным тестированием. Возлагаем надежды на плагин Configuration Manager for Jira, планируем начать его использовать в ближайшие два месяца.
            (в статье не совсем корректно написано)
          0
          В нашей компании значительный глюков UI у нас не наблюдается — в Chrome-е и Internet Explorer-е, по-моему всё нормально… Вообще, с точки зрения UI это, однозначно, наиболее богатая Система. По производительности, да иногда хромает… IMHO
            0

            Попробуйте вставить выделение трёх ячеек в другую ячейку. Или написать (в визуальном режиме) в jira что-то с {{ }}. И попытаться нажать после этого enter/пробел. очень смешно, правда, бесит.

              0

              Возможно, это было в каких-то старых версиях. В 8-ке у нас такого нет

          0
          $250000 + собственная команда, фактически работающая на Atlassiam. Это разумно?
            0
            Если посчитать стоимость лицензий в современном мире, когда один пользователь обходится в десятки долларов в месяц, то для тысячи пользователей суммы будут таких масштабов, да. Комментатор выше про пять тысяч написал…
              0
              Не хочется защищать Atlassian с их непродуманной ценовой политикой и слабой бизнес-моделью для корпоративных клиентов. Но для корпоративного клиента, решения Atlassian в данном сегменте практически не имеют конкурентов, альтернатив я не знаю.
              И для банка с 2000 активных пользователей в системе, такая стоимость не является большой.
                0
                Понятно.
                  0
                  Можно полюбопыствовать, какие конкретно возможности решений Atlasssian ставят их вне конкуренции? В Вашем списке особенностей, очевидно, не все являются таковыми, например:

                  Решения Atlassian основываются на веб-сервере Java Tomcat. ПО Apache Tomcat идёт в составе ПО Atlassian, как часть инсталляции, изменить версию Apache Tomcat, установленного в составе ПО Atlassian, нельзя,


                  Это, наверное, скорее «недостаток», чем «полезная особенность/функция»?
                    0
                    Можно полюбопыствовать, какие конкретно возможности решений Atlasssian ставят их вне конкуренции?

                    Хороший вопрос. Надеюсь сейчас не начнётся холивар. Но вот где ещё можно быстро организовать проектную работу и по классической водопадной модели, и по Scrum,
                    и масштабируемый Scrum. И чтобы всё было настраиваемо, и чтобы со всеми корпоративными функциями.

                    Это, наверное, скорее «недостаток», чем «полезная особенность/функция»?

                    А я и не писал, что это «полезно». Это просто особенность, в использовании Apache Tomcat есть и плюсы, и минусы. Здесь указываю использование Apache Tomcat для понимания, что из себя представляют продукты Atlassian.
                      0
                      Благодарю, примерно понятно.

                      и чтобы со всеми корпоративными функциями.


                      Можно пару-тройку перечислить? :)
                        0
                        Так вот прямо во введении к статье:
                        1. Масштабируемое
                        2. Отказоустойчивое
                        3. Поддерживаемое
                        4. Установка Self-managed (On-premise)
                        5. Возможность независимой разработки и тестирования
                      +1
                      Товарищ Gartner, делая исследование, не мог ошибиться! Просто так не помещают Системы в лидеры и по «Ability to execute» и по «Visionary» для класса Global Application Lifecycle Management.

                      Мне как тоже участнику внедрение JIRA в корпорации нравится, что:
                      1. есть очень полный REST API — это очень важно для возможности интеграции с другими корпоративными Системами
                      2. открытая схема базы данных, она может легко ставиться и на Oracle, и на MS SQL, и на Postgre. Легко работает под Linux.
                      3. Можно писать собственные плагины, фактически бесконечно расширяя и автоматизируя функциональность.
                      4. Доступность компетенции. Огромная база знаний. Почти не было кейсов, чтобы кто-то еще не задал твой вопрос по JIRA-е на сайте форума Atlassian. Плюс огромный функционал расширения — мы используем Database Values для интеграции JIRA с HP Service Manager-ом для построения справочника АС (автоматизируемых систем). Golden source АС у нас ведётся в HP SM (ИТ-сервисы) и инетгрируется с кастомной таблицей, из которой данные тянутся в справочник JIRA через плагин Database Values
                      5. Широкая ролевая модель и хороший баланс гранулярности прав/трудоёмкости организации ролевой модели
                      6. Быстрая learning curve. Это очень важно для успешного внедрения в крупной корпорации. Везде подсказки, контекстный поиск, богатая встроенная SQL-подобная подсистема отчётности, много диаграмм из коробки

                  0

                  Хотел скинуть линк знакомому директору, но терминология в статье не расчитана на человека не из IT сферы. Простому смертному неведомы понятия о ваших скрамах и канбанах, кроме того ему без разницы на чём хостится сервер JIRA, tomcat это или IIS. Непонятно на кого расчитана статья.

                    0
                    AdvanTiSS, а я как раз думаю любой директор поймёт о чём речь. Статья не требует специальных знаний в ИТ.
                    А то что упоминается Tomcat, так это не сильно отягощает статью — все такие фразы легко пропускаются, не обязательно понимать о чём речь.

                    Простому смертному неведомы понятия о ваших скрамах и канбанах
                    Вот если директор не интересуется методологиями проектов, ни по водопадной модели, ни по гибким методологиям, то действительно статья ему эта вряд ли пригодится. В данной статье мы не рассматриваем «таск менеджеры».

                    Непонятно на кого расчитана статья.
                    Так написал во вступлении к статье: «Статья будет полезна администраторам, владельцам продукта, руководителям проектов, архитекторам, всем кто планирует внедрение систем на основе ПО Atlassian.»
                      0
                      Тут было такое дело. Директор хотел все знать о состоянии разработок, но не знал, как поступиться.
                      Так я ему просто дал доступ в Джиру и настроил доску, на которой он мог видеть все открытые задачи и последние обновления. Он погрузился туда надолго и вопросы «а что вы делаете сейчас» стали появляться гораздо реже.
                      0
                      -
                        0
                        Смешанное чувство от статьи. Да, подход серьёзный, вроде всё красиво… Но задним фоном в голове сидит ветка на banki.ru, где народ постоянно плачет по поводу глюков финансовых расчётов в РСХБ. И становится странно — так всё вроде качественно в сопровождении разработки, а выхлоп — совсем другого качества.
                          0
                          РСХБ меняется. Не всё происходит мгновенно. В большой организации это не месяца, а годы.
                          0
                          Внёс замечания в статью по замечаниям от Atlassian User Group Moscow:
                          • исправлена ошибка в информации по версии Tomcat.
                          • пояснено позиционирование системы в нашем Банке (РСХБ).
                          • добавлено пояснение что любые плагины можно заменить собственной разработкой.

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

                          Самое читаемое