V našem týmu se věnujeme mnoho let konfiguraci Jira instancí a vývoji aplikací pro Jira Server. Naším společným cílem je spokojený zákazník. Pokud zákazník potřebuje v Jira něco nadstandardního, je možné, že nenajdeme již vyrobenou alternativu. V tomto případě vyrábíme různá menší i větší rozšíření do Jira instancí tak, aby řešení bylo šité na míru a podporovalo business zákazníka.

V minulém roce jsme se také rozhodli pro větší zaměření se na vývoj produktů pro Atlassian Marketplace. K našim letitým a stahovaným add-onům pro Confluence (EasyMind, Confbox) jsme hledali téma, které by bylo zajímavé implementovat pro Jira.
S takovým tématem přišel kolega Martin na našem prvním firemním hackathonu, kde s dalšími kolegy implementovali aplikaci pro synchronizaci zapsané práce z Toggl, nástroje pro time-tracking, do Jira. Tento add-on synchronizuje záznamy z Toggl, které musí mít minimální požadovaný tvar (obsahovat klíč Jira issue v názvu), do Jira jako worklog. Add-on TogglSync je od začátku května dostupný na marketplace.
Protože jsme se chtěli profesně rozvinout a blížil se další MoroHackathon, řekli jsme si, že po několika letech vyhýbání se, by bylo pěkné zkusit naimplementovat TogglSync tentokrát pro Cloud. Od doby, kdy jsme se zúčastnili AtlasCamp 2016, vznikl v naší firmě tutorial na tvorbu add-onů pro Jira Cloud, ale nic reálného jsme se naprogramovat nepokusili…až doteď :)

Architektura Server vs Cloud

Pro začátek je nutné uvědomit si rozdíl v tom, jak funguje Jira Server a Jira Cloud včetně add-onů, chcete-li aplikací. Cloud od Atlassianu není jen způsob provozování Jira, ale jedná se o službu, pro kterou Atlassian zajišťuje infrastrukturu a servis. Není tedy možné jednoduše upravovat konfigurace serveru, dělat změny na file systému nebo v databázi = nejedná se o Jira Server běžící v cloudu.

Server

V Jira Server máme aplikační server, na kterém je nainstalovaná Jira Core. Tento server využívá pro data databázi, která může být instalována buď na stejném fyzickém serveru nebo kdekoliv jinde. Pokud nainstalujeme do Jira novou aplikaci, instaluje se v rámci aplikačního serveru s Jira a standardně používá databázi, kterou používá Jira (nestandardně se dá samozřejmě připojit i k jiným databázím). V add-onu je tedy definováno, které položky Jiry mají být rozšířeny a jakým způsobem, add-on pak používá Java API z Jira Core nebo některé další aplikace k tomu, aby vykonával to, co má.

Add-ony pro Jira implementujeme jako OSGi moduly. Na našich projektech používáme Javu pro backend a React nebo Vue.js pro frontend.

Cloud

Atlassian měl donedávna cloud na své vlastní infrastruktuře. V průběhu několika let postupně zmigroval na AWS. Instance Jira pro jednotlivé zákazníky tedy běží v cloudu a naše aplikace se na stránkách zobrazují pomocí IFRAMů, ale jinak běží aplikace samostatně jako webová aplikace kdekoliv, kde je možné k ní přistupovat z internetu.

Konkrétně to funguje tak, že máme dán JSON deskriptor naší aplikace, ve kterém je popsáno, jakým způsobem bude aplikace Jiru rozšiřovat, jaké operace se mají stát během životního cyklu aplikace apod. Deskriptor dále popisuje, odkud se bude brát obsah pro aplikaci. Shrnuto podtrženo…

1. máme instanci Jira v cloudu
2. máme webovou aplikaci běžící na vlastním serveru, v AWS nebo kdekoliv jinde v prostředí internetu
3. tato aplikace je popsána JSON souborem, kterému říkáme deskriptor
4. deskriptor nainstalujeme do cloudové instance Jira
5. Jira na základě deskriptoru rozšiřuje své chování
   1. přidání elementů na stránky ve formě iframů
   2. implementace postfunkcí
   3. implementace issue fildů
   4. implementace conditions
   5. …
6. uživatel se přihlásí do Jira a zobrazí si stránku
7. Jira zjistí, zda je daná stránka customizovaná nějakou aplikací a jejím deskriptorem
8. pokud ano, podle deskriptoru se na definované místo pokusí dotáhnout obsah z běžící webové aplikace

Rozdíly v implementaci pro server a cloud

Data

Práce s daty je jedním z hlavních rozdílů při vývoji pro server a cloud, který vychází z rozdílů architektur. Zatímco v aplikaci pro Jira Server je možné použít Jira API (Active Objects) a vydefinovat si „jednoduše“ vlastní databázové objekty, které v rámci aplikace můžeme spravovat, v cloudu tuto možnost nemáme. Na druhou stranu je zde docela dobrá možnost použít tzv. entity properties. Jedná se o data, která můžeme uložit v rámci běžných Jira objektů, kterými jsou issue, user, project, comment atd. Pokud potřebujeme ukládat jiná data, nic nám nebrání rozjet si vlastní databázi a pomocí webové aplikace tato data prezentovat v Jira. S tím, jak běží aplikace nad jednou databází pro více instancí, je důležité nějakým způsobem oddělit data pro tyto instance, protože nechceme, abychom jednomu zákazníkovi zobrazili data jiného zákazníka.

Kvalita Atlassian dokumentace

Když jsem před několika lety začínal s vývojem plug-inů pro Jira/Confluence Server, největším problémem byla kvalita Atlassian dokumentace. Pokud si chtěl člověk vyzkoušet nějakou problematiku, mohl si být na 70 % (pocitově) jistý, že to podle dokumentace nebude fungovat na první dobrou a bude muset hledat v dalších zdrojích, jak problém vyřešit. Ne jinak je tomu u dokumentace pro vývoj v Cloudovém prostředí. Osobně jsem při vývoji první tři hodiny hledal způsob, jak v rámci deskriptoru přidat tlačítko na místo, kam jsem potřeboval a po jeho kliknutí zobrazovat dialog. Pomocí dokumentace jsem to nevyřešil a musel jsem ho dát na jiné, více „zdokumentované“ místo.

Bohužel je s tímto faktem nutné při vývoji počítat. Jakmile se člověk dostane do problematiky a dokumentaci potřebuje jen velmi zřídka, tolik ho tento problém nepálí.

Technologický stack

Zatímco pro server je nutné provádět implementaci tak, aby bylo možné vytvořit výsledný JAR nebo OBR balíček jako OSGi bundle, při vývoji pro cloud má člověk podstatně větší možnosti, jakou technologii si zvolí. V rámci vývoje TogglSync pro Cloud jsme použili SpringBoot a React na frontendu. Atlassian má předpřipřavenou implementaci SpringBootu s některými featurami, které usnadňují vývoj (více zde). Podobné implementace existují pro Node.JS framework Express, Play framework apod. V zásadě je ale jedno, jakou technologii pro vývoj webové aplikace člověk zvolí.

Vývojové prostředí

Při vývoji pro serverovou Jiru máme lokální vývojové prostředí nastaveno tak, že máme Jiru puštěnou lokálně a pomocí QuickReload pluginu nasazujeme aplikace přímo do lokálně běžící instance Jira. Jak jsem vysvětlil výše, do cloudové Jira pouze nahráváme deskriptor naší aplikace. Před vývojem je nutné zaregistrovat si testovací instanci Jira pro vývoj, poté klasicky rozběhnout lokální prostředí pro vývoj webové aplikace a tuto aplikaci zpřístupnit tak, aby k ní bylo možné přistupovat z instance Jira. K tomuto používáme aplikaci ngrok. Popis kompletní konfigurace vývojového prostředí je možné nalézt také v Atlassian dokumentaci.

Závěr

V rámci hackathonu se nám přes prvotní problémy v získávání informací podařilo dokončit TogglSync pro Cloud ve spustitelné, ne však prezentovatelné a udržovatelné podobě , což se od hackathonu přesně očekává. Tím, že si člověk může vybrat, jakým způsobem bude webovou aplikaci vyvíjet, jedná se o ideální oblast, při které je možné si vyzkoušet nové postupy a nové technologie. Každopádně, pokud vás zajímá vývoj aplikací pro Atlassian produkty, doporučuji si alespoň na několika příkladech osahat i implementaci aplikací pro Cloud. Třeba vás to posune na vaší profesní cestě zase o kousek dál. A pokud ne, alespoň si vyzkoušíte něco nového, a to je vždycky dobře .