As part of our ongoing series of Ask Jama webinars, covering customer questions and best practices, we recently held a webinar addressing release management options in Jama Connect.

In the webinar, Ryan Moore, a Jama Connect expert and a consultant from our Professional Services team, discusses options for managing releases within Jama Connect. The following concepts were covered:

• Leveraging Jama Connect’s release field
• Re-use and synchronization
• Branching vs. mainline approaches

We heard from our customers afterward that this webinar was informative and insightful, and we wanted to make sure that you didn’t miss out on this great content. Below you can see a transcript of the webinar, and view the full webinar recording.

The Full Demonstration of Release Management Options in Jama Connect

Transcript: Release Management Options in Jama Connect

Thank you all for taking the time out of your busy schedules to join us for the session about change management options in Jama Connect. Before we get started, I’d like to start off by clarifying a few key concepts as they pertain to requirements management, and really how they fit in within the scope of Jama Connect. I’ll also be including some use cases for each of the concepts we walk through today to help provide a bit of a bigger picture. And then we’ll go into a live demonstration within the tool. Through my experience with different organizations and various industries, I find that people tend to use a lot of different terminology and nomenclature that may pertain to any one subject, whether you’re discussing what you consider a specific version, or what’s the difference between a product versus a project, or how you define your user roles. This is no different when you’re approaching the concept of how you define releases. So, it’s important for us to clarify it.

A release to one person may be considered the final distribution of a product, where it’s officially available to the public or active in the field. Software teams, on the other hand, may think of release in terms of code or hardware. Other teams may consider manufacturing distribution in their framing releases. For our considerations today, let’s consider a release a grouping of requirements and corresponding tests that represent a product at a specific point in time. This could be a requirement set that’s specific to a product version, such as version 2.0 or version 3.0, where it could be included as part of a blanket, summer or fall release. So, regardless of what your organization is going to be using for requirements and tests, you could be using stakeholder requirements, market, user requirements, system versus subsystem, functional versus non-functional, design requirements or input requirements, verifications, validations, or calling new test cases. These are the types of artifacts that we’re going to be considering as a part of a release.

RELATED: Streamlining Requirements Reviews: Best Practices for Moderators, Reviewers, and Approvers

Baselines

Now let’s define baselines. Baselines are a very important aspect of Release Management and within Jama Connect as well. They provide clear cut lines in the sand. Baselining within Jama Connect can really be considered the ability to capture a snapshot of any grouping of items that you choose within a project at any given point in time. Let’s elaborate on some of the more common use cases for baselines. Baselines provide the ability to take full snapshots of artifacts. By taking baselines at release milestones, we’re able to make comparisons down the road using Jama Connect’s baseline comparison reports, which are exportable. They also provide detailed information and nuanced changes quickly and easily. Just a couple of clicks of a button, we can pull up these reports. The baseline reports will provide you a full list of any modified, deleted, or added items between baselines. So, it gives you the information that you need to be able to make quick comparisons. You can also use them to compare to the current state of the project. We can use baseline to compare between two baselines, or we can select a baseline that we captured prior and compare it to the current state of the project as well.

Additionally, you can also use Jama Connect’s baselines to actually roll back items, so you can roll back to prior baselines. Since baselines can be captured at the time of release, that also means you’ll have the ability to revert back to prior releases. So, lots of different power and what you can do in leveraging the baselines. As I mentioned, they are also easily exportable if you need it to export out and place into a quality management system (QMS) or another type of document control. And as a final caveat, we want to keep in mind that baselines, they’re static bits of information. They’re not going to be able to be leveraged to fork projects on a different path or branch them, if you will. Today we’ll through the concept of branching via reuse and synchronization during the presentation today.

RELATED: Defining and Implementing Requirements Baselines

Reusing and Synchronization

What is reuse and synchronization? Reuse and synchronization within Jama Connect can be considered as two advanced concepts. They both have very beneficial use cases and unique purposes. For that reason, I’ve included separate definitions. But you can also use them together and the outcome is going to be a lot of time saving and powerful use cases for you. Consider the concepts of reuse. In practice and in defining reuse is really to simply copy items in Jama Connect from one location to another, or it can be within the same project or across separate Jama Connect projects. Synchronization can be considered an additional step on top of reuse that allows you to maintain connections between those copied or reused items. Synchronization really adds an additional layer of monitoring between your artifacts to track differences or changes between them, and also provides you the ability to push and pull information between those synchronized items. Synchronization really leverages the concept of global IDs within Jama Connect. And those are the shared IDs between reused and synchronized artifacts that are going to help you bridge those items and maintain the connection between them.

Let’s walk through a few use cases for reuse and synchronization to help you better frame the use cases here and how it’s applicable and practical in use. Major releases to a large product. These could be small or large modifications to variants or existing product lines that you have. Staged releases of an evolving product is a second use case. And that may be used to leverage over time on a rolling schedule. For example, if you release a beta product, where you’ll be refining towards a final version and working as you go. Recent synchronization allows for version comparisons. As I mentioned before, Jama Connect’s synchronization allows you to generate a comparison view to easily identify differences between synchronized items. Also allows for “maintenance” updates to release projects. And synchronization allows you to separate Jama Connect projects into different maintenance workspaces, if you will, and easily push changes back into one main major release project. It also allows for changes to be “pushed” between releases.

In the same vein, and we’re talking about these projects that we’re leveraging for releases, you can use the synchronization to push changes back and forth between those projects. It allows for change control to the product. So, synchronization pushes, and this is very important, are never automatic. It’s always going to be a manual process, so you have to have ownership of that. What that means is that users always dictate when the changes are being made. Once again, this is a very important aspect to remember when considering using synchronization. You need to develop a regular cadence to determine who and when the changes are going to be pushed and pulled between synchronized artifacts or items. Then lastly, you’re able to use reuse and synchronization to create branches or forks from the original project. If needed, this concept of branching allows you to really work on multiple releases in parallel.

Release Management Options

Let’s talk about releases and in terms of the different types of releases that organizations may be working on as they go through the product development cycle. When we talk in terms of releases, we have two different methodologies that we’ll outline today and their differences. Linear versus parallel releases. We have linear on the left-hand side here and parallels on the right-hand side here. As you can see, linear releases are sequential or one after the other. They’re never going to be worked on simultaneously. Alternatively, parallel releases on the right-hand side, as you might expect by the name, parallel, they’re going to be worked on in tandem or side by side. So, you can be working on multiple releases in tandem.

“How are requirements impacted by these two approaches?” you might be thinking. In linear release management requirement, typically, we’ll have one singular definition at any given time. If I’m working in parallel, however, I may have the same requirement that spanned across two or three different releases. And that definition could easily change depending on the need of that release, or if I’m working in Release V2.0 versus Release 3.0. We might have a different need to alter the definition of that requirement. Since it’s summertime, let’s take a sunscreen for example. If I’m working on sunscreen products, it has different options SPF 15, SPF 30, and SPF 50. And we’re working on these simultaneously because we’re needing to roll them out on a similar timeline, where we have a similar roadmap for them. There may be same requirement in SPF 15 as there is in SPF 50 to include a very specific ingredient that helps block out the sun. But in SPF 15, we may need less of that depending on the strength versus needing more in SPF 50.

Let’s talk about the suggested approaches in Jama Connect for linear versus parallel. For the specific Jama Connect features and how they pertain to each release, Jama Connect’s release field is going to be the suggested method for the linear approach. The reason being is that the release field is going to allow you to make items a part of only one release at a time. So, the release field in Jama Connect doesn’t allow you to tag items in more than one release at a time. From a configuration standpoint, that means that the release field does need to be added to each item type that we’ll be using to label items as part of releases. That can be easily done by accessing your Jama Connect Admin section, navigating to the item types and then going to the fields. And if you don’t already have a release field as part of the item, you can easily add that there. In linear releases, you’re going to be leveraging baselines within one project to capture the state of the artifacts at the time of release.

Parallel releases on the right-hand side, reuse and synchronization really enable you to work simultaneously across multiple projects. And these projects will be release specific projects. Each project will maintain the scope of a unique release. Parallel release approaches. There are a few different variations that you may choose from when using parallel approaches. If you need to work in parallel, you have to roll out multiple releases simultaneously. You have two suggested approaches here, two key concepts that we’ll cover. A branching approach and a mainline approach. The branching approach, which is really aptly named for a visual image of branches stretching out from the base of a tree, requires you to leverage Jama Connect’s project duplication with synchronization. So, we’ll be copying projects. We’ll also be synchronizing the items within the project in the process of creating that project copy. Your various release projects will be branched off of your original release project. So, if we’re looking at our graphic here, our one would be the original release project, the first release, and then we could branch off into other various releases. So, we’ve branched off to R2, and then we have two branches that come off of R2, R2.1 and R3. And you can see that these are copies of R2 labeled here.

The mainline approach, however, dictates that you use one centralized project for the current state of affairs or the most recent release. Projects are created for unique releases and specific elements may be picked and chosen off of the mainline project to be selected for reuse and synchronization into your specific release projects. This method allows you to pick and choose, as I said, which specific elements are impacted by a release and strategically copy them into the appropriate release project. The resulting project off of your main project may be thought of as a unique release-specific workspace. You’ll manage all your release- specific work in the outlier projects and then push changes back into the mainline via synchronization once you’ve finalized your release.

RELATED: How to Avoid Ambiguity and Save Your Requirements

Once again, Jama Connect’s baselines are going to be leveraged once releases are pushed back into the main project to capture release milestones. So, we have our release-specific projects R1, R2, and R3. And we have our mainline project that houses all of the aggregate information. So, we are able to push and pull back and forth between these. Key capabilities in Jama Connect for each release management approach. If we’re looking at linear releases using that release field and also leveraging baselines. So, two main concepts there for the linear, and that’s the one after the other. We’re not working in tandem or in parallel. For parallel, we talked about the branching in the mainline approaches. Branching will really be leveraging the project duplication, reuse and synchronization. Whereas mainline, we’re looking at reuse, synchronization, and baselines.

Now that we’ve walked through all that, let’s hop into the tool itself and give you a quick demonstration of how to use the release field, how to branch projects, and what the mainline approach looks like as well.

To learn more about how to optimize team collaboration for streamlined product development processes, download our new eBook

DOWNLOAD NOW