How the Valiantys development team uses add-ons to create add-ons (Part 1)


Posted by
Brice GESTAS

March 30, 2017

In a nutshell, nFeed is a JIRA add-on which allows you to create custom fields which can be populated with values from any datasource (SQL database, REST APIs, LDAP or even JIRA itself). Its highly configurable selection options and aesthetically pleasing display makes it one of Valianty’s best seller items.

Yet did you know that nFeed actually feeds itself?

Our development team regularly uses our add-ons for their own productivity…meaning that our add-ons are used to improve our add-ons. A bit of a circular idea, but we believe in practising what you preach! This article is the first half of a two-part series showcasing our top use cases of Valiantys add-ons.

Avoid an infestation of bug tickets in your JIRA

When there is a bug in our add-ons that needs to be addressed, it is counterproductive if several developers create JIRA tickets on the same issue. Therefore when a team member starts to create a ticket for a bug and types in the summary, nFeed prevents the duplication of previously created tickets by displaying a list of titles of tickets which have similar words. They can then compare if the description resembles a similar issue. nFeed allows our team to quickly see what tickets already exist in JIRA, streamlining productivity.

nfeed similar issues

Merging business and the IT worlds: aligning the fix version and the release date

Our clients will sometimes ask if a bug was resolved or when a new feature will be released. Responding with ‘version 6.8.20’ doesn’t mean much to someone’s business needs when what they really want is a calendar date and a timeline. Unfortunately in JIRA, the fix version does not natively connect to the actual release date. However, each fix version of a user story has a start and an end date, so nFeed takes the end date for the version and automatically add that as the release date on the JIRA ticket.

nFeed1 Screen Shot 2017-03-22 at 14

nFeed comes to the rescue so we can quickly have an answer as to when work was completed, rather than creating an awkward silence as we fumble through our calendars for when our fix versions were released.

Keeps track of who did what for the testing phase

In typical agile form, our team uses JIRA’s sprint boards to manage the process of developing the add-ons with the following columns: To Do, In Development, Testing, Review, and Done. Here, we leverage the power of nFeed during the testing phase. As with most development teams, we conduct a code review which is a systematic examination of the code in order to ensure no errors were overlooked in the initial coding and the code is clean. The code review requires the developer to make a pull request, or in other words to pull out the code that needs to be reviewed from the repository (which is hosted on Bitbucket) of the developer to that of the tester so they can communicate easily for changes that might need to be made.

nFeed allows the natural progression of the workflow to assist with the pull request for the code review. When a developer moves the issue into the ‘Testing’ column, nFeed triggers the creation of a new field to show the developer that transitioned the issue, allowing for the tester’s follow-up questions to be directed to the right person.


 

This is far from a comprehensive list of all the use cases of our add-ons at Valiantys, we also utilise Exocet too! Keep your eyes peeled for part two of our use cases for Exocet. Until then,  click on the button below to try nFeed for yourself!