• 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.

    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

  • How to protect your JIRA from viruses, missing files and performance issues

    We have just released v2.0 of the Attachment Checker for JIRA plugin. The 2 key features introduced in this version are

    1. virus scanning of uploaded attachments (JRA-8626)
    2. restricting of attachments with duplicate filenames (JRA-2169)

    While it is already possible to install an anti-virus scanner on the JIRA server, there are some implications:

    • Attachments are deleted unknowingly by the scanner without notifying the author that his file is infected. Other users will be unable to download the file later.
    • As mentioned in https://confluence.atlassian.com/display/JIRAKB/Anti-Virus+in+JIRA, some of the users have reported slowness with JIRA when anti-virus software is installed. This is because of the dramatic increase in disk IO and CPU usage as JIRA creates many temporary files. The Attachment Checker only scans the attachments once when they are just uploaded, thus addressing the security concerns.

    The checking for duplicate filename improvement also helps to alert the user if there is already another attachment with the same filename. This solves the scenarios where a copy of the attachment has been uploaded before or the user forgot to rename the file to include the updated version number. This saves time on identifying the correct attachment to work with.

    Share this post