Support

Expand all | Collapse all

Handling Requirements for Multiple Release

  • 1.  Handling Requirements for Multiple Release

    Posted 09-11-2017 03:57

    Hi All,

    I need an advice about the best practice of handling the releases of a project, new project vs same project

    Reading from different blogs, as i understand there are two ways to handle the releases in JAMA:


    The problem that the current release of the project is not stable, there are minor modifications, in other words
    we have Project release 1.0.1, the team is working to release 1.0.2 and on the same time to release 1.1.0 with new functionalities.
    So if I duplicate the project now from the current stable release 1.0.1, and start adding the new functionalities for 1.1.0 i will lose the changes made on 1.0.2 (unless i do re-use and synchronise instead of clone)


    What worries me most, if I create a new project in JAMA for the new release, I should use a new project key, since the Project Key in jama is unique, right?

    In this case the imported requirements from previous projects will have different ID's (with the new project key as a prefix), right?

    Is there away to fix this?

    Thanks,
    Sawsan 



    ------------------------------
    Sawsan Abusharkh
    ------------------------------


  • 2.  RE: Handling Requirements for Multiple Release

    Posted 09-11-2017 11:57
    Edited by Chloe Elliott 01-22-2019 13:35
    Hi Sawsan,

    It's been a while since I worked on the webinar, so it's possible that you you saw these scenarios presented in the Ask Jama session about Release Management. If you haven't watched it yet, though, I highly recommend it, as it walks through the approaches with more detail.

    You make some good points here about the approaches and how they can deteriorate based on already-established processes at your organization. As far as your questions go, the answer is 1) yes and 2) no.

    What worries me most, if I create a new project in JAMA for the new release, I should use a new project key, since the Project Key in jama is unique, right?

    In this case the imported requirements from previous projects will have different ID's (with the new project key as a prefix), right?

    The answer to both of these questions is yes. Each project requires a unique ID, so whether you duplicate a project or reuse content into a new project, the Unique ID will be different for the same requirements in the different projects.

    Is there away to fix this?

    No, there is no way to share the same project key, ergo the same Unique ID, in each project. As far as alternatives go, you would have to
    1. Use Reuse & Sync instead of Duplicate and keep the items synced so that they share the same Global ID, and use that for reference instead of the Unique ID.
    2. Create a custom field with a custom ID scheme. This wouldn't be automatic, though, so it would be a pain. But you could have the IDs be more descriptive than the GID is.
    3. Instead of branching your releases into different projects, branch them into different components in the same project.
    4. Use a different method of release management completely. Here's what we've been doing at Jama lately:

    • Create a Release Management Project
    • Create a Release Build Item Type
    • Create an item for 1.0.1, one for 1.0.2, and one for 1.1
    • Relate all artifacts (from a different project) to the release build item in question

    That way you can look at that project and its releases and view relationships to know what's in it. If the functionalities all begin the same with 1.0.1 but diverge for 1.0.2 and 1.1, you would reuse the requirements (but not necessarily sync) within the project itself so that the IDs share the same Project ID and only vary in their final #. You would then be able to change the content of each and relate to the correct build item.


    ------------------------------
    Kristina King
    Jama Software
    ------------------------------



  • 3.  RE: Handling Requirements for Multiple Release

    Posted 09-12-2017 01:03

    thank you very much for the long answer and detailed explanation 

    Actually that probably what we will do, custom branching within the same project to handle the releases.
    But we will use a custom field (Release field) to indicate the release of each new item, rather than the release item type.

    When we are sure of closing (finishing-up) one release (e.g. 1.0.1) we will create a baseline for this release, then if we need to modify the requirement we can simply modify the original item and change the release field for it.




    ------------------------------
    Sawsan Abusharkh
    ------------------------------



  • 4.  RE: Handling Requirements for Multiple Release

    Posted 09-12-2017 08:34
    Sounds like a good plan, Sawsan. It seems like it will be pretty easy to manage baselines that way.

    ------------------------------
    Kristina King
    Jama Software
    ------------------------------