WIXLIB

3. ImplementationAt the beginning we have split Xporter for JIRAServer in modules to understand what could be usedin Cloud version or what needed to be adapted before we can use in our connect add-on.Figure 8: JIRA Cloud Architecture.Xporter for JIRA Cloud must provide all the features available in Xporter for JIRA Server that arepossible to implement in JIRA Cloud version. Forthat to be accomplished, additional logic and components will be needed, like the support infrastructure and the add-on database.2.3. TechnologyDuring Xporter for JIRA Cloud development werefound some technological challenges. These challenges are related to several factors: the differencesbetween the Plugins and Connect Frameworks, thelack of experience in the new development stackand also with the fact that the new architecturehas brought concerns that didn’t exist before. InJIRA Cloud add-ons vendors are responsible forsetting up the platform where the add-on will berunning, must manage all the add-on data andsettings and the java API from Plugins Frameworkisn’t available anymore.Figure 9: Xporter for JIRA components.Given these modules, we quickly conclude thatthe document engine module could be used in thecloud version as an external service. Therefore,major changes were needed in the documentsgeneration module because it was very dependenton other modules, especially in the module responsible for getting data from JIRA ( using the javaAPI from Plugins Framework). Considering theseneeds, a huge refactoring was made so that wecould have a fully independent module responsiblefor generating documents that could be used inboth server and cloud versions thus facilitatingmaintenance and coherence of the add-on on bothplatforms. The remaining modules would haveto be developed from scratch due to considerabledifferences that the new architecture and theConnect framework would bring. For example,now all the add-on data needs to be stored andmanaged outside of JIRA, all add-on screens mustbe previously rendered and then sent to iframespresented to the end user and all the data must beretrieve by the REST API because there’s no morea java API for that.To help in Atlassian Connect Add-ons [17]development, Atlassian provided a framework thatcould be used to help develop new add-ons andis available in several languages. This frameworkhas several functionalities: Serve add-on descriptorand UI, handle add-on installation, persistentstore, handle add-on requests, JWT token handler,crypto library, JSON and HttpClient libs. Ourdevelopment team used the NodeJS version of theframework [18].As stated earlier, the add-on data management must now be made out of JIRA. This requiresthe use of an external database which will be usedand managed by the add-on. The chosen databaseto be used by Xporter for JIRA was MongoDB,an open-source non-relational database developedby MongoDB Inc [19]. The choice of MongoDBas the database was made taking into accountfactors such as: fast development, ease of scale horizontally (providing new levels of availability andscalability), natural mapping to object-orientedprogramming languages (like Javascript, that willbe used in Xporter for JIRA Cloud development)and the massive community behind it [20].As its verified, without the Java API, all dataaccesses are made using calls through REST APIs.This means that a mechanism for authentication has to be used. Atlassian Connect uses atechnology called JWT (JSON Web Token) toauthenticate add-ons and also to ensure requestsintegrity [21, 22]. In order to an add-on be installed4

1. The node modules folder contains all theserver-side dependencies of our project, they’remanage by NPM.it needs to declare itself with a descriptor. Thatdescriptor is a JSON file that tells the Atlassianapplication about the add-on: where it is hosted,which modules it intends to use, and which scopesit will need. The scope is a concept that onlyexists in atlassian cloud instances and the maingoal of it is to improve security by forcing theadd-ons declaring what type of access they needfrom the Atlassian application what will definewhich REST API resources the add-on can use,giving the possibility to atlassian cloud applicationadministrators to accept or decline those accesses.Local development could be done in two ways:using the Atlassian SDK to create a local cloudinstance, running the add-on, tunneling it andinstall it (which works fine but both add-onand cloud instances were running on the samemachine)[23] or by setting up a free 5 users tiercloud instance, enable the development mode inthat instance running the add-on, tunneling itand install it[24]. Once we are using the AtlassianConnect Express framework the tunneling andinstalling steps are accomplish by simply specifyingthe URL, username and password from the JIRAapplication created in a configuration file of ouradd-on, and it will try to install itself in thatinstances.2. The public folder is where are placed theproject client-side dependencies. To managethis dependencies we will use Bower, a dependency manager tool for front-end components.3. The routes folder is where all the files whichdefine behavior related to the addon routesshould be placed.4. The Views folder is where all the templateengine files should be placed. For Xporter forJIRA Cloud we decide to keep the default template engine, handlebars.5. The app.js file is responsible to require somedependencies, create the express application,initialize and configure the components and tostart the server were the application will run.6. The atlassian-connect.json file is the addon descriptor, previously mentioned.7. The config.json file contains the configuration for each run-time environment the pluginruns in.3.1. Technical ImplementationSo, firstly, NodeJS and NPM (Node Package Manager) must be installed, after that, its installedatlas-connect (ACE client tool) and created theproject skeleton using it. In Fig. is shown theproject structure created by atlas-connect.8. The credentials.json file is where are specified the authentication data and URL of targetinstances so that ACE can automatically register the add-on.9. The package.json file holds several relevantmetadata to the project as well as the list ofserver-side dependencies.After understanding all that concepts, Xporterfor JIRA Cloud development has started. Inatlassian-connect.json were defined all the JIRAUI modules that Xporter needed and defined theroutes that will be responsible to handle each one.This routes will receive the Webhooks containinginformation about the JIRA instance and havethe job of rendering the module accordingly. Todo that, the routes firstly verify the license andthe JWT from the request using atlassian-connectexpress middleware (JWT must be authenticatedand authorized), then if they need additional datathey can use the REST APIs to obtain data fromJIRA or query the mongodb database to obtainadd-on related data. After that, they pass therequired context data to a template engine file andfinally that page is rendered and sent back as therequest response.All the views must import the Atlassian Connect JavaScript client library that establishes theFigure 10: Connect Add-ons Structure.5

cross-domain messaging bridge with parent iframesand provides several methods and objects thatcould be used in views without making a trip backto the add-on server. Besides that kind of requests(from JIRA instance to the add-on) they had tobe established new routes to handle requests fromthe iframe back to the add-on. The behaviouris almost the same, except that in this case theJWT does not exists in the request once it doesnot come from the JIRA instance. Luckily, ACEgenerates the JWT as a context variable and placeit in our views (client-side) which the add-on canverify later using the middleware (server-side). Therequests made back to the add-on are needed whena view needs additional data or for example in caseof Xporter for JIRA Cloud, to send requests thatwill trigger an exportation or an upload/downloadof a template.4. Infrastructure Setup & DeploymentDue to the wide range of services (which may beuseful in the future), platform maturity and the interest of our company to have a project runningusing their services, the choice of the platform thatwill hold the infrastructure was, AWS. All the components/resources will be attached to a dedicatedvirtual network in AWS [25]. A virtual privatecloud (VPC) is a virtual network dedicate withinAWS, it is logically isolated from other virtual networks in the AWS cloud and it could also be viewedlike a networking layer for Amazon EC2. The finalXporter for JIRA Cloud Virtual Private Cloud iscomposed by several elements that together guarantee high availability, resources scaling, access restrictions and great performance.4.1. ComponentsVPC Internet Gateway (1): An Internet gateway is a horizontally scaled, redundant, and highlyavailable VPC component that allows communication between instances in the VPC with the Internet. It serves two purposes: Providing a targetin the VPC route tables for Internet-routable traffic, performing network address translation (NAT)for instances that have been assigned public IPaddresses[26].NAT Gateway (1): Used to enable instances ina private subnet to connect to the Internet or otherAWS services, but prevent the Internet from initiating a connection with those instances[27].Elastic Load Balancer (2): Responsible to automatically distribute incoming application traffic,based on application or network level information,across multiple Amazon EC2 instances. It allows toachieve fault tolerance in applications, seamlesslyproviding the required amount of load balancingcapacity needed to route application traffic. TheLoad Balancer also monitors the health of its registered instances and ensures that it routes trafficonly to healthy instances. When the Load Balancerdetects an unhealthy instance, it stops routing traffic to that instance, and then resumes routing trafficto that instance when it detects that the instanceis healthy again. As such, this helps to ensure highperformance and fault-tolerance.[28]Elastic Cloud Compute ( 3): A Web-basedservice that allows business subscribers to run application programs with resizable compute capacityin the cloud. The EC2 can serve as a practicallyunlimited set of virtual machines[29].Availability Zone (2): Amazon cloud computing resources are housed in highly available datacenter facilities. Data center locations are calledregions. Each region contains multiple distinct locations called Availability Zones. Availability Zoneare engineered to be isolated from failures in otherAs stated before, the Document Engine module from Xporter for JIRA Server was re-factoredto be used as a service of Xporter for JIRA Cloud.It is running in a tomcat server and the logic iswritten in java. Besides that, because of timerestrictions and business/logistical reasons fromXpand IT, in the first versions, instead creatingour own MongoDB cluster we’re using MongoDBAtlas (mongodb as a service). The final Xporterfor JIRA Cloud data flow is summarized in Fig. 11.Figure 11: Xporter for JIRA Cloud data flow.After declaring all the intended modules to beextended in the add-on descriptor, defined all theroutes, implemented all the business logic andsolved other required features like: logging, interface inter nationalization (using 118n modulefrom NPM) and metric reports, the first version ofXporter for JIRA Cloud was completed.6

Availability Zones, and to provide inexpensive, lowlatency network connectivity to other zones in thesame region. By launching instances in separateAvailability Zones, applications are protected fromfailure of a single location, as it was done in Xporterfor JIRA Cloud infrastructure [30].Subnet (6): A subnet is a range of IP addressesin VPC. It is possible to launch AWS resources intoa specific subnet. Usually a public subnet is usedfor resources that must be connected to the Internet, and a private subnet for resources that won’tbe connected to the Internet[31].Auto-Scaling Group (2): Auto-Scaling Groupshelps maintaining application availability and allows scaling EC2 capacity up or down automaticallyaccording to conditions you define. They help ensuring that are running the desired number of Amazon EC2 instances as well as automatically increasethe number of Amazon EC2 instances during demand spikes to maintain performance and decreasecapacity during lulls to reduce costs[32].delete instances based on CPU and memory metrics. In the processing stage, additional requestscould be made to the MongoDB database, the Atlassian cloud instance that issued the request or toone of the webengine-private-subnet EC2 instances(Xporter for JIRA Cloud Document Engine). Forthe first two cases, the request response is sentback using the NAT gateway. When a node-privatesubnet EC2 instance makes a request to the Document Engine the request target is an Internal loadbalancer[34]. The DNS name of an internal loadbalancer is publicly resolvable to the private IP addresses of the nodes, therefore, internal load balancers can only route requests from clients withaccess to the VPC for the load balancer. Thisinternal load balancer will then route the requestto the most suitable webengine-private-subnet EC2instance based on CPU, memory and network informations. While processing the request, additional requests could also be made to the MongoDBdatabase, the Atlassian cloud instance that issuedthe request or to the node-private-subnet EC2 instance (as explained before the two first requestThe data flow in the infrastructure architecturemust use the NAT gateway). Webengine-privatecould be detailed in the following steps:subnet EC2 instances have a Security Group thatHandle Incoming Requests: In Xporter forrestricts the inbound requests to only accept TCPJIRA VPC the access to Internet from instancesrequests to port 8080 and SSH requests on port 22is made using the Internet Gateway. The incoming(to access the instances) and as node-private-subnettraffic is handle by an Internet-Facing Classic ElasEC2 instance, are also associated to an Auto Scaltic Load Balancer (the public one)[33]. The DNSing Group that is responsible to start or delete inname of an Internet-facing load balancer is publiclystances based on CPU and memory metrics.resolvable to the public IP addresses of the nodes,therefore, Internet-facing load balancers can route 5. Resultsrequests from clients over the Internet to the most Since cloud add-ons are not running in the samesuitable EC2 instance based on CPU, memory and server as JIRA applications an environment had tonetwork informations. The public ELB needs to be built to run the add-on, that needs to be scalhave Cross-Zone Load Balancing property enabled able (to handle big amount of concurrent requests),in order to distribute traffic to the node-private- secure (will handle sensitive data) and ensure persubnet EC2 instances in any Availability zone. For formance. All add-on data has now to be saved inthat, it also needs to belong to each public subnet its own database, therefore, all the concerns relatedof each availability zone to properly route out the to it, like data backup, data replication and accessesrequests to the Internet Gateway. This public ELB permissions have now to be considered. Since addhas associated a trusted certificate (to decrypt the ons and JIRA applications are now running on separequests from Atlassian instances before route the rated machines, all the data must be accessed usingrequests to the instances), a security group that de- REST APIs instead Java API like in server add-ons,fines that will be only accepted TCP incoming traf- this brings security and performance constrains befic in port 443 (SSL) and a Health Check policy cause data must be transferred over network fromto ensure that all the registered instances are avail- one server to another, what besides taking moreable.time could also be subjected of forging attempts,Requests Processing: After a request is routed that includes the extended UI modules that needsto one of the node-private-subnet EC2 instances to be rendered fast to keep the user attention. In(Xporter for JIRA Cloud NodeJS node) it is pro- view of these concerns, emerge questions such as:cessed by Xporter for JIRA Cloud NodeJS Appli1. In average, how long users need to wait in ordercation. Those instances have a Security Group thatto get their modules loaded (page load timing)?restricts the inbound requests to only accept TCPIs the amount of time acceptable?requests to port 3000 and SSH requests on port 22(to access the instances) and are associated to an2. What happens in case of peak workload condiAuto Scaling Group that is responsible to start ortions caused by simultaneous exportations? is7

the performance affected? How much?3.4.5.6.To ensure that each bug fix or new features wereproperly implemented, are working as expected andHow can new features be validated ? How could did not affect/break any old functionality was usedbe ensured that they don’t break old functional- Testing stages in the Xporter for JIRA projectities?Workflow. That way, in order to be resolved, eachissue had to go through a stage in the WorkflowWhat is the application reaction to continuous where quality team members verified its functionrequests over an extended period of time?ality and ensured that no related feature has beenaffected. As Fig. 13 shows, after opening and startCan Xporter for JIRA features be indepen- progress in a new issue, there are several possibledently testable?paths to the closed state but all the paths thathave passed by the resolved state had to necessarilyHow is the database behaviour under normal passed also by the testing one, ensuring that wayand peak workload conditions in terms of mem- that no issues were resolved without passing by theory, network and Process CPU?QA team.5.1. TestsIn order to test the loading time of the modulesextended by Xporter for JIRA Cloud was used asoftware analytics tool called newrelic[35]. Thistool was used to calculate the time difference between the request being made and the page is fullycharged. In Fig. 12 are presented the average pageload times for each route that handles the JIRAextended modules by Xporter for JIRA Cloud. Asit is possible to verify the worst cases are the webpanel and manage permissions pages. In web panel,it is probably due to the required conditions checksthat needs to be performed and in manage permissions page the problem could be related to complexcode while resolving the permissions for that client.With a worst case of 3.520ms to completely rendera module can be concluded that Xporter for JIRACloud achieved with success the task to present theUI as fast as possible to the end users.Figure 13: Xporter Cloud Project Workflow.To properly test the results related to exportations performance was used Jmeter [36]. WithinJmeter were performed tests that tried to simulatethe following scenarios: Normal/expected scenarioof exportations, Peak workloads of simultaneous exportations and Big amount of exportations requestsover large periods of time.Scenario 1: To try simulate an expected/normalamount of work were made 900 exportations with3 seconds of interval between each request. In thisscenario, in terms of response time to the requests,there was an average of 3.8s with the worst case oftime consuming of 18s to be completed. It was verified a slight increase in CPU utilization in EC2 instances and also in the instance of MongoDB, wherethere was a slight increase in the number of activeconnections.Figure 12: Xporter for JIRA Cloud - Page LoadingTimes.Figure 14: Requests Results - Scenario 18

crease in the network activity and in the number ofactive connections.Figure 18: Requests Results - Scenario 3Figure 15: Node EC2 Metrics - Scenario 1Scenario 2: In order to simulate peak workloadswere made 900 exportations divided in 9 groups ofconcurrent requests. The response time to the requests has had an average of 14.4s with a worstcase of 120s to be complet

Xporter for JIRA was created to provide for JIRA users a way to generate custom reports in several formats, lled with data from JIRA issues. To create this custom reports, users must create templates (Word or Excel les) and write special placeholders that will be replaced by is