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

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

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

В тази статия ще опиша техническите аспекти на изграждането на СУЖЦ. Статията ще бъде полезна за всички, които планират внедряване или се занимават с развитието на Atlassian Jira и Confluence в корпоративна среда. Тя не изисква специални знания и е насочена към начално запознаване с продуктите на компанията 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 и т.н.
Името СУЖЦ не е индустриален термин или общопотребимо понятие, това просто е името на системата в нашата банка. СУЖЦ за нас не е система за проследяване на грешки, не е система за управление на инциденти и не е система за управление на промени.

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

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

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

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

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

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

Продуктите на компанията 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. Магазин за приложения (плъгини): 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 постоянно се разширява и усъвършенства (например, възможността за инсталация на единен възел се появи едва през 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) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Има ограничения по поддържаните версии и често се поддържат само стари версии, но за всяка СУБД има версия, с поддръжка от доставчика:
    Поддържани платформи на Jira,
    Поддържани платформи на Confluence.

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

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

Обяснения към схемата:

  • На схемата е представена реализация в нашата банка, тази конфигурация е примерна и не е препоръчителна.
  • 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'. При това не е важно дали те ползват системата или не — дори ако потребителите никога не са влизали в системата, всички потребители ще бъдат отчетени за лицензията. В случай на надвишаване на броя на лицензираните потребители, решението ще бъде да се отнеме оправомощаването 'JIRA Users' на част от потребителите.
  3. Лицензията за Data Center всъщност е абонамент. Изисква се годишно плащане на лицензията. При изтичане на срока, работата с системата ще бъде блокирана.
  4. Цените на лицензите могат да се променят с времето. Както показва практиката, обикновено в посока на покачване и възможно значително. Следователно, ако тази година лицензите имат определена цена, следващата година цената на лицензите може да се увеличи.
  5. Лицензирането се извършва по потребители по три tiers (например, ниво 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 използваме следните плъгини (статията е кликаема):
Как да внедрим Atlassian Jira + Confluence в корпорации. Технически въпроси

За системата Confluence използваме следните плъгини (статията е кликаема):
Как да внедрим Atlassian 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 при нас се използва самостоятелно приложение, което позволява актуализиране на статусите на Issues в 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 са остарели и не са налични в новите версии за употреба.

Заключение

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

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

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

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

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster