Status, Subtask or Checklist: How to Divide Work in Jira?
Jira lets teams work the way they want, but you have to make some decisions. How do you decide if it’s best to add a status, a subtask or a checklist?
We’re pleased to announce that the free version of Issue Checklist for Jira, first launched in February of 2019 has been installed by over 20,000 customers. The app has proven to be a consistent favorite among Jira users, often ranking among the top-rated Jira apps and the top-trending apps, as well as the Atlassian staff picks. We credit the success to the fact that checklists are simple yet powerful tools, but we did run into some challenges along the way:
Issue checklist automatically creates six custom fields (see table), and our original plan was to have them automatically synced. However, after learning that the majority of our users weren’t using this feature we decided to set the “sync” as disabled by default. Some of the fields still stay synced, but the ones that copy checklist content do not. Disabling the syncing lowered the load on our servers, and – more importantly – decreased the number of requests to our customer’s Jira instances. This lowers the volume of requests made to Jira REST endpoints available for apps in any given Jira instance.
Customers had notified us that the app was creating an excessive amount of entries in the issue history tab and disabling the automatic syncing helped reduce that. Beyond that we are waiting for Atlassian to better address how actions made by apps are recorded on the History tab.
Webhook notifications have also been a challenge. We receive webhooks for actions on the issue (created, updated, etc.), but do not respond to webhooks if the customer doesn’t have an active license. We also had to ensure that we were not responding to webhooks we triggered ourselves. This was particularly important as the custom field syncing (when enabled) had the potential to create an infinite loop.
We also needed to ensure that we had the proper infrastructure in place for managing high levels of traffic. In order to avoid latency, we typically use 8 Standard-1x dynos on Heroku, and up to 12 during peak hours when there is a bigger load. This allows us to process 80-100 requests per second. Currently we use about 20GB of disk space for our database on MongoDB, operating one primary node and two secondary nodes.
Knowing that we are storing customers data, we implemented extra securing measures to ensure that there are no breaches. Our developers use 2FA to access their accounts and secure their local environments with encoded drives. Only secure connections and trusted WIFI networks are used.
Redundancy is built into our processes with every code change covered by Pull Request and accepted by at least one other person before it goes to production. All releases are required to be easily reversible either by the Heroku “Revert” or by migration/rollback scripts.
Finally source code is automatically tested on every commit. We create automated tests for all new functionalities and regularly scan dependencies for security vulnerabilities.
We want to thank all of the customers who helped put Issue Checklist for Jira Free over the 20,000 mark. We’re proud of the app’s success and we’ll continue to work to add new features and functionality.