-
How we migrated from VertygoSLA to Days Elapsed Traffic Light plugin
Why we built Days Elapsed Traffic Light plugin
We have a customer using VertygoSLA plugin to track the SLA for requests in their JIRA, but VertygoSLA was acquired by Atlassian to be embedded with JIRA Service Desk. There were 3 options available:
- To switch to JIRA Service Desk
- To find other suitable SLA plugins
- To build our own SLA plugin
We decided to build our own Days Elapsed Traffic Light plugin due to the following considerations:
- Need to calculate the number of working days. As the business requests can take many days to resolve, displaying 9 days elapsed is less mathematically challenging compared to 72 hours passed
- Ability to flag out issues that is going to exceed the SLA soon. The yellow traffic light is helpful for alerting users
- To be able to retain the SLA information from the old requests
Setting up the Traffic Light custom fields
The setup for the Traffic Light custom fields is pretty simple with a couple of steps
- For every VertygoSLA custom field, we added a corresponding Traffic Light custom field with the same name
- The working calendars have to be added to define the working days and non working days. In order to cater to departments with different calendars, we introduced the concept of country calendars and organisation calendars. This will alleviate the administrators’ tasks of having to update each calendars individually
- The mappings have to be defined to specify the thresholds and conditions for the SLA to be applied
- Post functions are added into the workflows to start and stop the Traffic Light Timers
Migrating the VertygoSLA data
The patching was the most time-consuming part as it was done incrementally over different JIRA projects. We built a patcher module that can select the issues to patch.
- The patching was done during off-peak hours to avoid disruption to the users
- The patcher will read the VertygoSLA information and find out the duration of SLA timer
- Using the number of days elapsed, the traffic light colour is determined
- The information is then populated into the corresponding Traffic Light custom field
- We created dashboards with our Multiple Filters Chart Gadget for the users to verify the results
- After verification, the VertygoSLA custom fields were deleted
Share this post
-
Confluence Page of the Month – Maxwell Render V3 documentation
Nowadays, it is a more frequent occurrence to find technical documentation written in Confluence and some of them had done a great job. Then the idea came: “Why don’t we showcase them on our blog? A well done piece of work deserves recognition and other Confluence users can pick up the good practices too.”
That’s why from this month onwards, we will be starting a Confluence Page of the Month to showcase a Confluence page that we chanced upon and think it is interesting.
The page to start the ball rolling is the Maxwell Render V3 Documentation
3 reasons we like this page:
- By embedding the Vimeo video, the page became much more interesting
- The layout looks neat and organized with the RefinedWiki theme
- It looks easy to navigate through the content from the left side bar
Share this post
-
When do you upgrade Jira Server to Jira Data Center
It is a frequent question – Why should I buy Jira Data Center?
Due to that, we are sharing our experience with Jira Data Center as an Atlassian Solution Partner in this post. Hopefully, we can help to shed some light on it.
What is Jira Data Center
Jira Data Center is a deployment option designed for high availability and performance at scale when hosting Jira Server in your own premise.
This is possible with a cluster of servers to share the workload from incoming requests through the use of a load balancer. To add on, each node is a complete Jira instance with its own index.
Jira Data Center Architecture What are the benefits of using
Jira DC- Performance – Faster performance with it distributes the load across the various nodes
- Increased users – A 2-node Jira DC cluster can support double the load of concurrent users with the same response time as compared to a single Jira Server
- High Availability – With active-active clustering, it guarantees uninterrupted access in event of hardware failure. This is because it will redirect requests to an active node automatically
- Instant scalability – It is possible to add more nodes without any scheduling any downtime
- Disaster Recovery – Option to have another set of hardware on standby
When you should start looking
at Jira DCThe Jira Server should be sufficient for most users until you encounter one of the scenarios below:
- your existing Jira issue count is hitting a million
- you are growing at 20,000 issues per month
- there is a need for high availability (HA) or disaster recovery (DR)
- the CPU usage for your Jira Server is peaking constantly
- more and more users are complaining of slowness
Before upgrading to Jira Data Center
- Can you allocate more resources (e.g. CPU and RAM) to the Jira Server?
- Have you explored performance tuning?
- You may want to check whether virus scanning is slowing down the system. Likewise, you can use our Attachment Checker for Jira app to limit virus scanning to file attachments
- Have you upgraded to the latest version of Java and Jira? Do you know Jira 6.4 is 30% faster than Jira 6.3 on average? Check out 5 Things to Know for Scaling Jira Performance
What are the considerations
Licensing Costs
- Jira Software Data Center is an annual term license. That is to say, you need to renew annually to continue using it
- The pricing is based on user tiers and does not have any limit on the number of servers or CPUs
- There is a discount for upgrading from Jira Software Server to Jira Software Data Center
- If you are only setting up a cold-failover server, you can use a free development license without additional cost
Compatibility
- The apps must be with Data Center compatible
- If you are moving from Jira Cloud to Jira DC, this could be tricky
Cloud Option
Atlassian is also launching Jira Enterprise Cloud which you can find out more from the differences between Free/Standard/Premium/Enterprise for Jira Cloud.
Recommended Strategy
For those who do not need HA setup, we recommend the following strategy
- Start with Jira Software Server
- Do performance tuning to stretch the limit of Jira Software Server
- Conduct benchmarking tests to measure the improvement with Jira Software Data Center
- The number of nodes to allocate depends on the number of concurrent users and the usage pattern. The following chart can be a reference on how increasing the nodes increases the number of requests handled without affecting the time taken
Useful Resources
- High Availability Guide for Jira
- Disaster Recovery Guide for Jira
- Jira Data Center Webinar: High available and performance at scale for your enterprise
- Data Center Migration Essentials: Checklist for Moving to Data Center
- Jira Sizing Guide
- Jira Data Center FAQs
Share this post
-
How teams uses Atlassian suite to get work done
This short video gives a good introduction on how teams use various Atlassian products to get work done
- Confluence – for team content creation and sharing
- JIRA Software – for team planning and project management
- JIRA Service Desk – for team services and support applications
- HipChat – for team messaging and communications
- Bitbucket – for team code sharing and management
Each of them work well individually and can integrate seamlessly with a consistent user experience and richer feature set
Share this post
-
An infographic on the differences across various JIRA products
We have been spent a lot of time explaining to customers the differences between JIRA Core, JIRA Software and JIRA ServiceDesk. Think this infographic summarises them well.
For those who wants to check out the screenshots and links, it is available at https://www.akeles.com/what-are-the-differences-between-jira-software-jira-service-desk-and-jira-core/
Share this post
-
How to Deploy Changes to JIRA in a Day
Background
Recently, we completed a project for a bank. Their original idea was to build a system for tracking but they decide to leverage on JIRA since they were already using it. The requirements can be met by adding a few new JIRA projects and customised plugins.
However, there was a big challenge to quickly deploy changes on an existing JIRA Production system. The changes had to be replicated across 3 separate environments (DEV, QA and PROD). This meant that the users had to wait a longer time to use the new features. Luckily, we discovered the Configuration Manager Plugin. It is a JIRA add-on that enables automated deployment of configurations across JIRA instances.
With this plugin, we managed to replicate the configuration in 1 environment within 1 day instead of a week. We managed to shave 8 days of effort for QA and PROD environments. It eliminated human errors which could not have been avoided if we took the traditional method. There were just too many steps to replicate with zero errors.
We were very impressed and want to share our experience with fellow JIRA users.
How we did it
Due to confidentiality, the steps are listed using the screenshots taken from the plugin author’s page.
- The initial configuration in DEV had to be done manually. We cheated! Using our in-house Project Creator plugin, we created hundreds of custom fields from a MS Excel file
- After the schemes and workflows were set up, we got ready to create a configuration snapshot for export
- The Configuration Manager can only be accessed by a JIRA Admin under the admin console
- Select the Add Snapshot button (or Create Snapshot for newer version)
- We used System Configuration to capture all the configuration so that we can deploy multiple projects at the same time
- After the snapshot was created, we downloaded the xml file by selecting Download from the gear icon on the right side
- The file was copied to the UAT environment to be deployed
- Similarly, the JIRA Admin had to log into the admin console to access the Configuration Manager page
- To play safe, we did an backup of the UAT environment before applying the changes so that in event of error, we can still restore the UAT environment to the previous setup
- Click on the Deploy link on the left sub-menu to access the Deploy Configuration Snapshot page
- Click on the From Snapshot File button to upload the xml configuration file created from DEV
- The snapshot will be added to the list of snapshots available for deployment
- Click on the Deploy link under the Actions
- The list of configuration changes will be listed. The additions are identified by
whereas modifications are identified by 
- We spent more time verifying the changes identified with the changes to ensure they do not affect existing configuration.
- When the changes were confirmed, we proceeded with the automated deployment
- Once completed, the changes could be viewed in the Audit logs
Interested users might want to consult the plugin documentation page at https://botronsoft.atlassian.net/wiki/display/CMJ/Configuration+Manager+Documentation for details.
Feedback for Improvement
We were very glad such a plugin is in existence. However, there are some limitations or possible improvements
- The configuration stored using ActiveObjects had to be replicated manually. This is because there is no easy way to differentiate the configuration settings from the issue values
- The selected role for the Issue Alternative Assignee custom field had to be re-configured after it had been added automatically
Conclusion
We recommend Configuration Manager Plugin to JIRA Administrators who need to implement many changes across multiple JIRA environments frequently. It’s a time-saver!
Share this post
-
5 Things to Know for Scaling JIRA Performance
Atlassian’s Five Secrets of JIRA Performance at Scale webinar shared some useful insights on scaling JIRA performance.
Here is a pictorial summary will be useful for those who missed the video.
1) JIRA 6.4 is 30% faster than JIRA 6.3
2) Custom fields have the most influence on the speed especially on creating issues
3) The number of users does not have much impact on the speed
4) JIRA can support more issues without much degradation in the performance
5) Running JIRA on Java 8 is 13% faster than on Java 6For details, you can check out the video below or the detailed report at https://confluence.atlassian.com/display/ENTERPRISE/Scaling+JIRA
Share this post
-
Getting Git Right 2014
On 22nd September 2014, Atlassian is in Singapore for the 1st time to host Getting Git Right 2014 . Atlassian is well-known for their developer tools such as JIRA, Confluence, etc. The team spent the afternoon in town to talk about how Git together with Stash can help developers work more productively and deliver products faster.
Stash is a Git repository management software to enable users to collaborate on their code better. Revision control and source code management is becoming increasingly essential for development teams big or small. It helps developers to collaborate more efficiently, hence the proliferation of Git adoption for developer teams and increasing interest in products like Stash.
The Atlassian team shared their best practices on development workflows such as how to integrate Git into the system and how to use Git for faster releases. The revision control provides users with records of changes made to projects thereby empowering them in tracking and recovery of source code.
A lucky attendee walked home with our Intel® NUC mini server with Atlassian Git Essentials (JIRA+JIRA Agile+Bamboo+Stash) pre-installed. Our Git Essentials Mini-Server is targeted towards startups and small teams as it is both energy-saving and space-saving.
Share this post
-
Win free copies of the newly published JIRA 6.x Administration Cookbook
Readers would be pleased to know that we have teamed up with Packt Publishing to organize a giveaway of the new JIRA 6.x Administration Cookbook that we have reviewed recently (See Book Review: JIRA 6.x Administration Cookbook).
Three lucky winners stand a chance to win a digital copy of this book each.
How to Enter?
All you need to do is head on over to the book page and look through the product description of the book and drop a line via the comments below this post to let us know what interests you the most about this book. It’s that simple.
The first 3 valid respondents will get an e-copy of the Book.
Deadline
The contest will close on till 17th Sep 2014. Winners will be contacted by email, so be sure to use your real email address when you comment!
Share this post
-
Book Review: JIRA 6.x Administrator Cookbook
I was excited to receive an invitation from Packt Publishing to do a book review on JIRA 6.x Administrator Cookbook.
Being an Atlassian Expert, it can be scary to see such books coming into the market because the tricks of the trade are being wiki-leaked. However, it also means JIRA has matured and is getting increasing adoption.
I think the tagline for the book “Quick answers to common problems” is quite apt. It contains a lot of recipes to questions that we encounter day-to-day. Some of the answers are similar to what we are doing for ourselves or have done for our customers.
The book is well structured with clearly illustrated steps and notes to highlight salient points. The e-book also contains coloured screenshots that makes it easier to see the highlighted text.
Some interesting topics include:
- How to reset the JIRA administrator password
- Using Javascript with custom fields
- Creating custom fields with custom logic
- How to migrate JIRA to another environment
There are also chapters covering:
- JIRA workflows
- JIRA security
- JIRA customizations
- Integration JIRA with other applications
This book has a lot of practical recipes and is useful for those who want to administer their own JIRA instance.
For those who are keen to pick up JIRA add-on development, you can also check out the JIRA 5.x Developer Cookbook
Share this post
Subscription Options:
