• Confluence Page of the Month – Lawrence Berkeley National Laboratory

    19 February 2016
    Comments are off for this post

    The Confluence Page of the Month for February goes to a Scheduled System Outage announcement from Lawrence Berkeley National Laboratory. 

    Berkeley Lab Scheduled Outage announcement

    4 reasons we like this page:

    1. The author took effort to add the logo of the affected system so that it can be identified easily
    2. Good use of blog to communicate time related announcements to users 
    3. Facilitate navigation by putting latest news and common links on the right sidebars
    4. Integrating with Google Calendar to show upcoming events

    Tip: You can select the image uploaded previously from the Confluence image browser

    Share this post

  • How we migrated from VertygoSLA to Days Elapsed Traffic Light plugin

    16 February 2016
    Comments are off for this post

    Report on the Traffic Light status of issues using 3D Gadgets

    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:

    1. To switch to JIRA Service Desk
    2. To find other suitable SLA plugins
    3. 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

    1. For every VertygoSLA custom field, we added a corresponding Traffic Light custom field with the same name Added Traffic Light custom field
    2. 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
      Defining the calendar
    3. The mappings have to be defined to specify the thresholds and conditions for the SLA to be applied
    4. Post functions are added into the workflows to start and stop the Traffic Light Timers
      post functions to start the 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.

    1. The patching was done during off-peak hours to avoid disruption to the users
    2. The patcher will read the VertygoSLA information and find out the duration of SLA timer
    3. Using the number of days elapsed, the traffic light colour is determined
    4. The information is then populated into the corresponding Traffic Light custom field
    5. We created dashboards with our Multiple Filters Chart Gadget for the users to verify the resultsDifference in SLA Reports
    6. After verification, the VertygoSLA custom fields were deleted

    Share this post

  • Confluence Page of the Month – Maxwell Render V3 documentation

    19 January 2016
    Comments are off for this post

    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

    Maxwell Render V3 Documentation

    3 reasons we like this page:

    1. By embedding the Vimeo video, the page became much more interesting
    2. The layout looks neat and organized with the RefinedWiki theme
    3. 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

    5 January 2016
    Comments are off for this post

    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 Reference Architecture
    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 DC

    The 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

    1. Start with Jira Software Server
    2. Do performance tuning to stretch the limit of Jira Software Server
    3. Conduct benchmarking tests to measure the improvement with Jira Software Data Center
    4. 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
    JIRA Data Center Performance Test

    Useful Resources

    Share this post

  • How teams uses Atlassian suite to get work done

    29 December 2015
    Comments are off for this post

    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

    23 December 2015
    Comments are off for this post

    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.

    JIRA Product Family Infographic

    For those who wants to check out the screenshots and links, it is available at http://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

    30 June 2015
    Comments are off for this post

    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.

    1. 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
    2. After the schemes and workflows were set up, we got ready to create a configuration snapshot for export
    3. The Configuration Manager can only be accessed by a JIRA Admin under the admin console
    4. Select the Add Snapshot button (or Create Snapshot for newer version) 
      view snapshot 
    5. We used System Configuration to capture all the configuration so that we can deploy multiple projects at the same time
      Create a system snapshot
    6. After the snapshot was created, we downloaded the xml file by selecting Download from the gear icon on the right side
    7. The file was copied to the UAT environment to be deployed
    8. Similarly, the JIRA Admin had to log into the admin console to access the Configuration Manager page
    9. 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
    10. Click on the Deploy link on the left sub-menu to access the Deploy Configuration Snapshot page
      deploying the snapshot 
    11. Click on the From Snapshot File button to upload the xml configuration file created from DEV
    12. The snapshot will be added to the list of snapshots available for deployment
    13. Click on the Deploy link under the Actions
    14. The list of configuration changes will be listed. The additions are identified by additionwhereas modifications are identified by modificationAnalyzing the changes
    15. We spent more time verifying the changes identified with the modification changes to ensure they do not affect existing configuration. 
    16. When the changes were confirmed, we proceeded with the automated deployment
    17. Once completed, the changes could be viewed in the Audit logs
      Viewing the changes from the audit log
       

    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

    Response Time - JIRA 6.4 vs JIRA 6.3

    2) Custom fields have the most influence on the speed especially on creating issues

    Custom Fields and Performance

    3) The number of users does not have much impact on the speed

    # of Users on performance

    4) JIRA can support more issues without much degradation in the performance
    # of issues on performance5) Running JIRA on Java 8 is 13% faster than on Java 6

     

    Java 1.8 vs 1.6 response time

    For 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

    6 October 2014
    Comments are off for this post

     Getting Git Right
    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 JIRAConfluence, 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.

    Git makes you happy

    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.

    Who uses Git

    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.

    git log

    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.

    NUC winner

    Share this post

  • Win free copies of the newly published JIRA 6.x Administration Cookbook

    10 September 2014

    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.

    JIRA 6.x Administrator Cookbook

     

    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