How do you apply baseline in confluence/jira?

[KentGran]

Hopefully I am not the only one struggling with this issue regarding baselines. What I'm trying to achieve is just a versioned document that links to a set of versioned JIRA issues. Doesn't sound to hard to achieve but how do you lock those issues from being edited so that a certain baseline always reflect a certain version of the issues it holds links to?

Detailed description of the problem.

On day one I create this Confluence page that contains requirement specifications using the "Product Requirements Blueprint"-approach described in the Atlassian documentation. This page holds a table pointing out several product requirement documents which in turn contains several links to JIRA issues where the requirements are described in detail.

Obviously on day one they are all in synch with what we want since this version of the document, version 1, contains the specified requirements as of right now. Then at some later point in time someone discover that one or more of the requirements need to be updated, which is rather common, and they would have to update the requirements issues in JIRA. This is where the problem is. If we change those requirements issues then they are not the same as the ones we added at day one which makes the baseline useless.

As far as I know Confluence has only got individual versioning of pages. Unfortunately that doesn't solve this problem since it points to other documents (through the "Page Properties Report-macro") which in turn contains links to the requirements in JIRA.

The real question is:

How can you achieve a proper baseline handling in JIRA/Confluence whereby the top page, containing the Page Properties Report macro, points at a specific version of the requirements documents which in turn hold specific versions of the requirements issues in JIRA?

Hope this problem description makes sense.

[KentGran]

@Tom Gelhausen, nope, not really. We have come up with a slightly modified approach whereby we export  issues on a certain date into a "baseline-PDF" so we know exactly what a certain set of reqs looked like at a certain point in time. That PDF is then attached to the Confluence page shown as a list of baselines.Baselines.png

[Ege Su İnan]

Hi Kent Granström , @Alexey Rjeutski [Polontech]

As OBSS we developed a solution for " Baseline ". You can create baselines of your documents based on a date and time. The created baseline set allows you to easily access document versions of that time.

Here is the link to download Baseline for Confluence . You can also read the documentation of the product.

Thank you for your interest!

[Martin Böhme]

He was asking for a solution for Jira...

[Virginia Lober]

Hi guys,

I have the same problem as Kent written in 2014, four!!! years ago. I also have to baseline JIRA but current I didn't find a possibility. For Confluence current there exists the baseline plug-in, what we are still using.

Best regards

Virginia

[Larry Wilson]

R4J allows Baselines for Issues, if all you want is the Baseline.

It captures the settings of all the Issue Fields in the Issues you set up...

I just started playing with an Adaptavist tool; Project Configurator, that allows exporting a full Project and all its Configurations to xml (allowing import to a any other JIRA Instance) ...

Seems like it might be a candidate for Baselines that can be stored under GIT, in case of Custom field , Workflow/ Workflow Scheme changes or Issue Type/Issue Type scheme changes ... but if you have made changes of that nature OR plugins that affect Transitions, your project may require a completely new JIRA Instance to return to the "Baseline",...

sigh, ...

[Larry Wilson]

I am trying to maintain Baselines for JIRA Issues (a Traceability Matrix), Code Base, and Knowledge Base (many spaces in Confluence), for each Product Release...

Bitbucket/GIT is used for the Code base, so no issues there, beyond the normal configuration management trials of combining components from multiple repository(s) into a single Product Release and Branch Model ...

R4J, Portfolio, and Structure each seem to have varying degrees of Baselines covered but no branching?

The Plug-in mentioned above for Confluence may be a start, but branching and then merging becomes an issue, as well as the links and attachments.

I had hoped someone had an add-on for Confluence that could trigger make use of GIT for page store,... or there might be some way to apply containers for Confluence Instance and to be able to use a separate container version as the "Branch" ...

I currently use a backup and restore model with pgbarman (postgress db) and file system backup that could be used to freeze the Instance in time similar to the Container method but it would require separate licenses to then restart the "Branch" ,...

eh, just thinking out loud ,...

[KentGran]

Good thinking man. I thought this would be a piece-of-cake to sort out. Just adding a version to each issue making it possible to point out a certain version of an issue. It would probably be part of a primary key in the database where it would be TEST-1, VER--XYZ. Then in the external macro, just specify what ever issuekey and version of that issue you want and the problem would be solved making it possible to accuratelly setup a proper baseline.

The version number would of course change every time you edit an issue but since the filtering in the macro points to a certain version of an issue, it would not change the result.

Regards  

[Larry Wilson]

Yes, I think, just like Confluence, we can identify the issues with Versions, but those nasty branches for sustaining are the problem ... and possible merges to current development...

Issues and Documents, along with their links and attachments ...

Far more complex than Source Code Baselines and Branch Models,...

Perhaps a Container approach, but the licensing, and the merges are the bear, ...

I did a model similar to this using ClearCase and a Web Interface back in the 90's ...

It allowed "Management" to work on word documents that were maintained in ClearCase but were presented on Web Pages based on a ClearCase Configuration file.

I was able to pull a different version by simply associating the ClearCase Configuration into the Web Page Properties ... and I was able to read the Word docs for presentation, similar to the Confluence Pages. Triggers on save allowed for auto updating the sources in ClearCase ... perhaps it's possible a trigger in Confluence and a few web hooks might provide the means to auto read/save xml pages/attachments from/to GIT ... same could probably be done in JIRA for Issues ... spaces would need to be restorable with NEW unique ids ... dynamic ...

another day ...

[KentGran]

I think you're taking on a far more complex issue than what I want to achieve. Perhaps my issue is just one of the steps in yours whereby JIRA issues can be uniquely identified  by issuekey, and a new field, issueversion. 

[Larry Wilson]

Agreed, being a developer (and a QA Engineer) I tend to wanting to assure sustainable processes and products ... hence the ability to branch and merge ...

And, most definitely, what you are looking for is an important stage in getting the full process in place ...

I just see that a lot of work goes into manually trying to manage the sustaining end ... and it usually is the point that you want to be most automated to allow quick fixes to happen on legacy releases and not be lost on current processes ... so I try to be sure it is not forgotten in discussions like this, ...

[Tom Gelhausen]

Kent Granström, have you found a solution to your problem after all? Could you solve it within JIRA or did you switch to a different tool? I need to do the same thing.

BRGDS/TOM.

[KentGran]

Nope. No solution

[Ege Su İnan]

Hi Kent Granström,

Yes this plug-in works only Confluence, but its a step to start, thank you for your interest.

Kind Regards,

[KentGran]

Hi @Ege Su İnan

Thanks for the suggested plugin. It is definatelly a step in the direction I want but it doesn't solve the problem with non-versioned JIRA issue. It will work for Confluence documents but if these documents have links to JIRA issues, in our case an issuetype "Requirement", then that requirement can change without the document being changed...

[KentGran]

Perhaps a business case then... Can't be that hard to implement this if no other solution is around.

It's just a case of picking the right versions of some issue specified in a certain baseline but I guess the main problem is that JIRA issues aren't versioned(?) and therefore we can not differenciate between what ever an issue looked like at a certain point in time compared to some other point in time...

[KentGran]

First of all, thanks for your reply.

Unfortunately it doesn't solve my problem. I was hoping that someone would have struggled with this and found a genuine solution to the problem

[Alexey_Rjeutski__Polontech_]

we had the experience with similar (but not exactly your) problem and prepared the technical task according to request of one of our customer - for plugin creation. But we've not implemented it due to cancelation as there is too much hours of development

[Alexey_Rjeutski__Polontech_]

There is no common solution for such kind of use case. As a workaround I would advice you to use only links to proper version in confluence, and use versioned link when you connect it to jira ticket. That will give you possibility to see baseline, but will require a set of accuracy from you.

[KentGran]

First of all, thanks for your reply.

Unfortunately it doesn't solve my problem. I was hoping that someone would have struggled with this and found a genuine solution to the problem.

[Alexey_Rjeutski__Polontech_]

Please think about plugin development / ordering. We had the similar request, but client cancelled as there are a lot of hours of development to implement such kind of use case.