How to automate documentation tasks and create a public Change Log

[Theresa Klunk]

Currently our company has a very manual process for release notes and they’re just created on-demand for certain customers and issues that were relevant to them. We don't have formal sprints or release versions and are constantly updating our product and would like to be able to automatically capture these updates in a Change Log that customers can visit online or subscribe to.

Here is my brainstorm for this, keeping in mind that we are migrating to continuous integration / continuous deployment at some stage (CI/CD) 

1. All ENG tickets need documentation where the experience for users will be affected (Should we create a checkbox/flag for this)?
2. When closing ENG ticket where the experience for users will be affected, developer fills out ‘developer notes’ field
3. Once developer notes are filled that triggers DOC tasks:
1. Populate release notes fields - Public Summary and Public Description
2. Create Knowledge Base article
3. Create blog post and potentially a newsletter or EDM
4. Release to PROD should not be allowed until:
1. QA is complete
2. DOC tasks are finished
5. Information that is populated in the Public Summary and Public Description field should be made available via a Change Log page on our website or Help Centre.

I would love to hear how this is possible with Jira and how others have implemented this.

Thanks!

Theresa

[Ben Poulson]

Keep in mind that this isn't something I've ever set up, I just think it's an interesting idea. I'm also assuming you have scriptrunner installed.

Point by point:

1. All ENG tickets need documentation where the experience for users will be affected (Should we create a checkbox/flag for this)?
   
   This is easy enough- just a checkbox or radio button custom field
   
   
2. When closing ENG ticket where the experience for users will be affected, developer fills out ‘developer notes’ field
   
   Probably just a quick scripted validator on the Close transition. Something like "if usersAffectedField = true and developersNotesField = null then throw an error else continue with transition"
   
   
3. Once developer notes are filled that triggers DOC tasks:
   These would all be scriptrunner post functions
1. Populate release notes fields - Public Summary and Public Description
   
   Easy enough with a script post function. Just grab the text in those two fields, format it, and put it in the release notes field.
   
   
2. Create Knowledge Base article
   
   (Assuming you use Confluence for your knowledge base)
   This Scriptrunner documentation page has an example of how to trigger the Confluence REST API from within jira (assuming your jira and confluence instances are linked). Looks like it actually wouldn't be as difficult as I assumed.
   
   
3. Create blog post and potentially a newsletter or EDM
   
   Not sure what EDM stands for. Not sure about creating a blog post- should be possible similar to above if you can use a REST API.
   
   
4. Release to PROD should not be allowed until:
1. QA is complete
2. DOC tasks are finished
   
   Also tricky. Maybe don't let anyone manually release versions? You could set up a escalation service to run every 24 hours that looks at all the tickets in the unreleased versions for that project, and releases a version if every ticket within it meets the criteria?
   
   
5. Information that is populated in the Public Summary and Public Description field should be made available via a Change Log page on our website or Help Centre.
   
   Maybe a change log Confluence page that it adds to? Could also add to your website if it has a REST API or something.