Как да внедрим Atlassian Jira + Confluence в корпорация. Технически въпроси

Планирате ли да внедрите Atlassian софтуер (Jira, Confluence)? Не искате да правите жестоки грешки в дизайна, които след това трябва да бъдат решени в последния момент?

Тогава сте тук - обмисляме внедряването на Atlassian Jira + Confluence в корпорация, като вземаме предвид различни технически аспекти.
Здравейте, аз съм собственик на продукта в RSHB и отговарям за разработването на системата за управление на жизнения цикъл (LCMS), изградена върху софтуерни продукти Atlassian Jira и Confluence.

В тази статия ще опиша техническите аспекти на изграждането на LCMS. Статията ще бъде полезна за всеки, който планира да внедри или развие Atlassian Jira и Confluence в корпоративна среда. Статията не изисква специални познания и е предназначена за начално ниво на запознаване с продуктите на Atlassian. Статията ще бъде полезна за администратори, собственици на продукти, мениджъри на проекти, архитекти и всички, които планират да внедряват системи, базирани на софтуер Atlassian.

въведение

Статията ще обсъди техническите въпроси на внедряването на система за управление на жизнения цикъл (LCMS) в корпоративна среда. Нека първо дефинираме какво означава това.

Какво е корпоративно решение?

Това означава решението:

1. Мащабируем. В случай на увеличаване на натоварването има техническа възможност за увеличаване на капацитета на системата. Отделно хоризонтално и вертикално мащабиране - при вертикално мащабиране се увеличава капацитета на сървърите, при хоризонтално мащабиране се увеличава броят на сървърите за работа на системата.
2. Failsafe. Системата ще остане достъпна, ако един елемент се повреди. По принцип корпоративните системи не изискват устойчивост на грешки, но ние ще разгледаме точно такова решение. Планираме да имаме няколкостотин конкурентни потребители в системата и времето на престой ще бъде много критично.
3. Поддържа се. Решението трябва да се поддържа от доставчика. Неподдържаният софтуер трябва да бъде заменен от собствена разработка или друг поддържан софтуер.
4. Инсталация Самоуправляван (на място). Самостоятелното управление е възможността да инсталирате софтуер не в облака, а на вашите собствени сървъри. За да бъдем по-точни, това са всички опции за инсталиране, които не са SaaS. В тази статия ще разгледаме само опциите за самоуправляваща се инсталация.
5. Възможност за самостоятелно разработване и тестване. За организиране на предвидими промени в системата е необходима отделна система за разработка (промени в самата система), система за тестване (Staging) и продуктивна система за потребителите.
6. Повече. Поддържа различни сценарии за удостоверяване, поддържа журнали за проверка, има персонализиран модел за подражание и т.н.

Това са основните елементи на корпоративните решения и, за съжаление, често се забравят при проектирането на система.

Какво е система за управление на жизнения цикъл (LCMS)?

Накратко в нашия случай това са Atlassian Jira и Atlassian Confluence – система, която предоставя инструменти за организиране на екипна работа. Системата не „налага“ правила за организиране на работата, а предоставя различни инструменти за работа, като Scrum, Kanban дъски, водопаден модел и мащабируем Scrum и др.
Името LCMS не е индустриален термин или общ термин, то е просто името на системата в нашата банка. LCMS за нас не е система за проследяване на грешки, не е система за управление на инциденти и система за управление на промените.

Какво включва внедряването?

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

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

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

Характеристики на Atlassian

Atlassian е лидер в много сегменти:

• Gartner Magic Quadrant for Enterprise Agile Planning Tools
  (Лидерство поради успешното придобиване на AgileCraft с неговото облачно решение)
  
• Глобални инструменти за управление на жизнения цикъл на приложения Пазарен дял

Продуктите на Atlassian имат всички корпоративни функции, от които се нуждаете. Ще отбележа следните характеристики:

1. Решенията на Atlassian са базирани на уеб сървъра Java Tomcat. Софтуерът Apache Tomcat е включен със софтуера Atlassian, като част от инсталацията не можете да промените версията на Apache Tomcat, инсталирана със софтуера Atlassian, дори ако версията е остаряла и съдържа уязвимости. Единствената възможност е да изчакате актуализация от Atlassian с по-нова версия на Apache Tomcat. Сега, например, текущите версии на Jira имат Apache Tomcat 8.5.42, а Confluence има Apache Tomcat 9.0.33.
2. Удобен интерфейс, внедрени са най-добрите практики, налични на пазара за този клас софтуер.
3. Напълно адаптивно решение. С подобрения можете да приложите всяка промяна в основната функционалност за потребителя.
4. Развита екосистема. Има няколкостотин партньори: https://partnerdirectory.atlassian.com, включително 16 партньори в Русия. Чрез партньори в Русия можете да закупите Atlassian софтуер, плъгини и да получите обучение. Партньорите са тези, които разработват и поддържат повечето от плъгините.
5. App Store (плъгини): https://marketplace.atlassian.com. Приставките значително подобряват функционалността на софтуера Atlassian. Основната функционалност на софтуера Atlassian е доста скромна, за почти всяка задача е необходимо да инсталирате допълнителни плъгини безплатно или срещу допълнителни пари. Следователно разходите за софтуер може да са значително по-високи от първоначално изчислените.
   Към днешна дата в магазина са публикувани няколко хиляди плъгини, почти хиляда от тях са тествани и валидирани съгласно програмата за приложения, одобрени от центъра за данни. Такива добавки могат да се считат за стабилни и подходящи за използване в натоварени системи.
   Съветвам ви да подходите внимателно към въпроса за планирането на добавки, това значително влияе върху цената на решението, много от добавките могат да доведат до нестабилност на системата и производителят на добавките не предоставя поддръжка за решаване на проблема.
6. Обучение и сертифициране: https://www.atlassian.com/university
7. Поддържат се SSO, SAML 2.0 механизми.
8. Поддръжката за мащабируемост и толерантност към грешки е налична само в изданията на Data Center. Това издание се появи за първи път през 2014 г. (Jira 6.3). Функционалността на изданията на центъра за данни непрекъснато се разширява и подобрява (например възможността за инсталиране на един възел се появи едва през 2020 г.). Подходът към добавките за изданията на Data Center се промени много през 2018 г. с въвеждането на приложения, одобрени от Data Center.
9. Разходи за поддръжка. Цената на поддръжката от доставчика е почти равна на пълната цена на софтуерните лицензи. По-долу е даден пример за изчисляване на цената на лицензите.
10. Липса на дългосрочни версии. Има т.нар Корпоративни версии, но те, както всички останали версии, се поддържат 2 години. С тази разлика, че за Enterprise версиите излизат само корекции, без добавяне на нова функционалност.
11. Разширени опции за поддръжка (срещу допълнителни пари). https://www.atlassian.com/enterprise/support-services
12. Поддържат се няколко варианта на СУБД. Atlassian идва с безплатна H2 база данни, която не се препоръчва за продуктивна употреба. Следните СУБД се поддържат за продуктивна употреба: Amazon Aurora (само център за данни) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Има ограничения за поддържаните версии и често се поддържат само по-стари версии, но за всяка СУБД има версия с поддръжка от доставчика:
    Платформи, поддържани от Jira,
    Платформи, поддържани от Confluence.

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

Разяснения към схемата:

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

лицензиране

Проблемите с лицензирането на Atlassian заслужават отделна статия, тук ще спомена само общи принципи.
Основните проблеми, които срещнахме, са проблемите с лицензирането на изданията на Data Center. Функции за лицензиране за издания на сървър и център за данни:

1. Лицензът за сървърното издание е постоянен и клиентът може да използва софтуера дори след изтичане на лиценза. Но след изтичане на лиценза, купувачът губи правото да получава поддръжка на продукта и да актуализира софтуера до най-новите версии.
2. Лицензирането се основава на броя на потребителите в глобалната система за разрешения „JIRA Users“. Няма значение дали използват системата или не - дори ако потребителите никога не са влизали в системата, всички потребители ще бъдат взети предвид за лиценза. Ако броят на лицензираните потребители е надвишен, решението е да премахнете разрешението „JIRA Users“ от някои от потребителите.
3. Лицензът за център за данни всъщност е абонамент. Изисква се годишна лицензионна такса. При изтичане на срока работата със системата ще бъде блокирана.
4. Цената на лицензите може да се промени с времето. Както показва практиката, в голяма степен и, може би, значително. Следователно, ако вашите лицензи струват една сума тази година, то следващата година цената на лицензите може да се увеличи.
5. Лицензирането се извършва от потребители по ниво (например ниво 1001-2000 потребители). Възможно е надграждане до по-високо ниво, срещу допълнително заплащане.
6. Ако броят на лицензираните потребители бъде надвишен, ще бъдат създадени нови потребители без право на влизане (глобално разрешение „JIRA Users“).
7. Добавките могат да бъдат лицензирани само за същия брой потребители като основния софтуер.
8. Само продуктивните инсталации трябва да бъдат лицензирани, за останалите можете да получите лиценз за разработчици: https://confluence.atlassian.com/jirakb/get-a-developer-license-for-jira-server-744526918.html.
9. За закупуване на поддръжка се изисква закупуване на поддръжка на Renew Software - цената е приблизително 50% от цената на оригиналния софтуер. Тази функция не е налична за Центъра за данни и не се отнася за плъгини - ще трябва да плащате пълните разходи годишно, за да ги поддържате.
   По този начин годишната софтуерна поддръжка струва повече от 50% от общата цена на софтуера в случая на изданието Server и 100% в случая на изданието Data Center - това е значително повече от повечето други доставчици. Според мен това е съществен недостатък на бизнес модела на Atlassian.

Характеристики на прехода от сървърното издание към центъра за данни:

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

Функционален обхват на изпълнение

Базовият софтуерен пакет Atlassian включва огромен брой функции, но често функциите, предоставени от системата, силно липсват. Понякога дори най-простите функции не са налични в основния пакет, така че добавките са незаменими за почти всяка реализация. За системата Jira използваме следните плъгини (картината може да се кликне):

За системата Confluence използваме следните плъгини (снимката може да се кликне):

Коментари за таблици с добавки:

• Всички цени са базирани на 2000 потребители;
• Цените са базирани на посочените цени https://marketplace.atlassian.com, реалната цена (с отстъпките) е по-ниска;
• Както можете да видите, общата сума е практически еднаква за изданията Data Center и Server;
• За използване бяха избрани само добавки с поддръжка за изданието Data Center. Изключихме останалите плъгини от плановете, за стабилността на системата.

Функционалността е описана накратко в колоната Коментар. Допълнителни плъгини разшириха функционалността на системата:

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

Освен това използваме Приложение Atlassian Companion. Това приложение ви позволява да редактирате файлове във външни приложения (MS Office) и да ги връщате обратно в Confluence (чекиране).
Приложение за потребителски работни станции (дебел клиент) ALM работи Jira клиент https://marketplace.atlassian.com/apps/7070 реши да не използва поради лоша поддръжка от доставчика и отрицателни отзиви.
За интеграция с MS Project ние използваме самостоятелно написано приложение, което ви позволява да актуализирате статусите на проблеми в MS Project от Jira и обратно. В бъдеще за същите цели планираме да използваме платен плъгин Ceptah Bridge - плъгин за JIRA MS Project, който се инсталира като добавка за MS Project.
Интеграция с външни приложения реализирани чрез връзки към приложения. В същото време интеграциите за приложения на Atlassian са предварително конфигурирани и работят веднага след настройката, например можете да показвате информация за проблеми в Jira на страница в Confluence.
REST API се използва за достъп до сървърите Jira и Confluence: https://developer.atlassian.com/server/jira/platform/rest-apis.
SOAP и XML-RPC API са остарели и не са налични в новите версии за използване.

Заключение

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

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

Ще се радвам да отговоря на въпроси в коментарите.

Източник: www.habr.com