Release Management in Polarion ALM

Posts: 2
Joined: Wed Jan 03, 2018 8:53 am

Release Management in Polarion ALM

Postby bkraus » Wed Jan 03, 2018 10:45 am


my company is using Polarion ALM 17 for managing the development process of an embedded SW project.
We are now facing the challenge to manage different releases of the SW and have not yet found a feasible way to do so. I think we are missing some essential functionality of Polarion here.

Our (simplified) setup is as follows:
We use three different levels for requirement engineering:
- Customer Requirements
- System Requirements
- Software Requirements
System and Software Requirements are linked to one (or more) requirements in the level directly above via "satisfies" relationships. It is possible that one Customer Requirement is satisfied by several System Requirements, and it is also possible that one System Requirement "satisifes" (is relevant) to more than one Customer Requirement.

Of course not all Customer Reuirments will be implemented in the initial software release. Accordingly we are planing several software releases , say 1.0 and 1.1. This is the part where we get lost. We cannot yet see an easy way to handle this in Polarion.

The main problem is that at a given point of time the Customer Requirements are finalised and approved for 1.0. Then the System Requirements for 1.0 can be finished, reviewed, approved, then in turn the SW Requirements. But in the meantime work on the Customer Requirements for 1.1 has already begun.

As we understand it, baselines are not really usefull here because they are always applied to the whole project? So if we draw a baseline after SW requirements for 1.0 are finalised, we will not have the state of the Customer Requirements that were valid at the time work on the System Requirements started for 1.0, but the current state that may (and will) contain changes or additions that are valid for 1.1 only. Generating different baselines, say "rel1.0_cusreq", "rel1.0_sysreq" is no help either, because this gives us no consistent state either.

Time points, on the other hand, do not seem to be very useful. If we are not mistaken, the concept of time points does not contain any automatic verification. The time points on all levels (for every single work item) must be set manually? We had something similar in mind to what is described here:


Alternatively, time points would be a very useful means of tracking individual releases if there was some automatic way to ensure consistency. I.e., if one System Requirement is linked to a Customer Requirement, there should be some way to ensure that the time point for the derived requirement cannot be later than the time point for the parent work item. Planing should be done on the top level only, in this case on the Customer Requirements. Linked work items implementing/satisfying this top level requirement should inherit the time point from the parent. I know this can be done on the creation of a derived WI, but this is not enough if one System Requirement satisfies several Customer Requirements with different time points. The only way to ensure consistency seems to be a manual check when linking the requirements. This method does not promise to be very reliable, especially if rescheduling of top level features occurs during the project (a thing not totally unheard of).

So may basic question is: What are we missing? I simply cannot believe that this problem is not addressed by Polarion.

Thanks in adavance for any helpful comments!

Posts: 75
Joined: Tue Sep 12, 2017 1:02 pm

Re: Release Management in Polarion ALM

Postby Jürgen » Thu Jan 04, 2018 10:04 am

We basically have the same problem, with even more versions developed in parallel. And it is even worse, because we do not have three documents (or document levels), but up to ten document levels, all in different states.

You are right regarding the use of baselines and also regarding the use of time points. You only can have a view for one point in time, but what you really would like to have is the Customer Requirements from July, traced with the System Requirements from October, traced with the Software Requirements from December.

Polarion offers a branch concept for this. By creating a branch for a document, you can develop it in two directions from a common start point. Or, in your case, one is continued, the other one stays as it is. A branch document is kind of a copy of the original document, but the work items are not really copied, they are referenced. So if you do not change anything, the branch document shows exactly the same content as the original one.

In your case you would probably want to create a branch document, freeze all references in there and declare this as the "release 1.0 document". Then you continue to work in the original one for 1.1. When all documents are done for 1.0, you could for example create a trace table from the frozen 1.0 branch to the system requirements.

Explaining the whole concept here would be too much, but the help should give you a good idea how this works.

Posts: 2
Joined: Wed Jan 03, 2018 8:53 am

Re: Release Management in Polarion ALM

Postby bkraus » Fri Jan 05, 2018 9:20 am


thanks a lot for your answer!

In order to solve the problems mentioned for our - simplified - project setup, we came up with two ideas:

1. Building a script that corrects the time points for every work item, starting at the top level and working its way down through all link relations to the lowest level. The script should then be run every night (or weekend). I am not sure if this is in any way possible.

2. The other idea would be the use of - you named it - branches for individual releases. You said that we may want to create a branch document. Doesn't the branch concept suffer from the same limitations as baselines? I.e., don't branches also affect the complete project? In our first sketch of a possible branching concept we would essentially only work on the Customer Requirements in the "trunk". As soon as these are frozen, we would then create a branch for a specific release and work our way down in this branch then.
But this approach would require extensive merging of work items. Say, if we finished System Requirements for Release 1.0 (in the respective branch), most of these System Requirements will also have to go into the branch for Release 1.1 then. So we would have to merge the System Requirements in the trunk first, and then from there to the second release branch. I think baselining and branching are essentially the underlying features of SVN, and I always was very sceptical regarding the concept of automatic merging that comes along with it. While you could at least somehow control the process or review the results for source code, this will surely not be possible for work items of Polarion.

Posts: 75
Joined: Tue Sep 12, 2017 1:02 pm

Re: Release Management in Polarion ALM

Postby Jürgen » Wed Jan 10, 2018 8:20 am

I have no opinion for your first point, so I directly go to point two.

The important information here is: Polarion does not use SVN branches.

Although they call it a "branch", technically a branch document is nothing else but a second document (in the trunk).

You could create a branch document manually, by copying all the "non-workitem" stuff into a new document and then insert references to all work items into the new document. This is more or less what the branch button does, when you branch the head revision. When you enter a specific branch revision, Polarion automatically freezes all references to that revision.

So now you have a second document with all references. You can now decide, if the original document is regarded as your 1.0 release and the branch document is the 1.1, or vice versa. We typically regard the branch document as the "freeze of the current revision", so in our case it would be the 1.0 document.

When you work in two document versions in parallel (1.0 and 1.1) then it is obviously not possible to bring them together afterwards without doing some kind of "merge" (not in the meaning of a SVN merge, but rather as "bring the changes together somehow").

The good thing with the branch document is, that is has references to the original items. If an original item changes, then the reference will display the same content, if it is not frozen. If it is frozen, then you could later decide to change the freeze revision, so your changes will become visible with the revision change. That way you have more control over the changes.

Changing a work item in the branch document is more difficult, because you cannot simply change the reference. Depending on your change, you could
- "overwrite" the reference to create a new work item, then change it
- add another work item or some plain text to describe the change, without changing the reference

Both possibilities will probably result in some manual effort when you later "merge" the documents. But typically this can be handled.

Really difficult is to change the same work item in both documents, i.e. changing the original one AND overwriting the reference, with different content. This can lead to problems during the merge. (If you are writing source code with SVN: this would be the same as changing the same code lines on different branches and then merge the code.)

If Polarion talks about "merging" documents (or branches), then this is technically not a SVN merge. It is "combine the two documents".

You should probably try this once with a dummy document to see what happens there.

Return to “Polarion Application Lifecycle Management (ALM)”

Who is online

Users browsing this forum: No registered users and 9 guests