Releases, Associations tab, proposal

Monday, August 23, 2021
Avatar

Currently it is not allowed to associate with releases any enities, it is possible only include them using release field. But sometimes more flexibility is needed.

I want to be able to associate with releases any spira entities including tasks (and releases from other projects) from any project (release could be in project A, while task could be from project B).

This will allow me to create projects for the let's say customer-related. Use-case:

  1. I have projects for internal, product-development acitivities. They have own release naming. 
  2. When we deploy a new version to a customer it has it's own naming convension, where other entities (all types incl other releases and independant tasks) may be added with multiple-to multiple relations.

As you already have Associations tab, it won't take long to add what is already developed to a one more entity but it defenitily will be a huge step towards good relationships between Inflectra and their customers.

6 Replies
Monday, August 23, 2021
Avatar
re: ilyapolyakov Monday, August 23, 2021

The same question is vary actual for my company.

Looking forward for the clarifications and further updates.

Monday, August 23, 2021
Avatar
re: dmitriy.a Monday, August 23, 2021

We have a plan to add 'Release' as a new type of custom property, similar to what we have for users.

Monday, August 23, 2021
Avatar
re: inflectra.david Monday, August 23, 2021

David, that is good, but not enough.

What if the same internal release from a core-projects is going to be delivered through several different customer's releases (to be more precise, to different customers, so names of the release could be different)? So, I need to have an option how to make multiple-to-mutliple mapping for any project and any entity.

Example:

  1. We have developed feature "Perfect" in our core project during Sprint 13/component Release 1.2.5.
  2. That will go to customer A in release 1. (for tracking what happens with customer A, we have a dedicated spira project "customer A" with their own releases)
  3. The same component will go to customer B in release 2. (for tracking what happens with customer B, we have a dedicated spira project "customer B" with their own releases)

If we try to solve it via custom fields we need to create amount of custom fields equal to amount of customers, that is crazy.

 

Having ability to associate release/sprint with any entity in any project will solve our problem, moreover it doesn't look difficult as it was already developed by Inflectra to other entities.

Monday, August 23, 2021
Avatar
re: ilyapolyakov Monday, August 23, 2021

Having the ability to associate any artifact to a release would be relatively straightforward. The once concern is that for those artifacts that already have dedicated Releases tabs (e.g. test cases) it would be confusing, since the Associations tab would be for linking, without causing any business rules to take place whereas the main Releases tab is used for calculating things like test coverage, test progress, etc.

Monday, August 23, 2021
Avatar
re: inflectra.david Monday, August 23, 2021

Yep, that is normal. All built-in mechanism:

Releases tab is used for calculating things like test coverage, test progress, etc.

should have the some logic from Inflectra's side as how it is built now. It shouldn't recieve any influence from my associations.

What I will additionally link - it is my responsibility how to interpret it. I do not expect any calculations from Inflectra's side, just create and show that association in the  "Associations tab" for the Release and associated entity.

So, I expect two mechanism:

  • what is currently built in with it's default logic, calculations, etc. using special release-fields (Planned relaese, Relaese, etc.)
  • and that additional linkeage and there it is my responsibility how to use it ( I am going to use it via custome reports).
Monday, August 23, 2021
Avatar
re: ilyapolyakov Monday, August 23, 2021

Probably, we need to consider that proposal wider: to let user assoiciate any Spira entity to any through any project.

For example, to let associations be from tasks in project A to a requirement in project B (currently it is forbidden I don't know why) and etc. All these assoications shouldn't require any calculations or logic from Spira's side, meaning of association should be an user's area of responsibility.

Statistics
  • Started: Monday, August 23, 2021
  • Last Reply: Monday, August 23, 2021
  • Replies: 6
  • Views: 185