Hello Everyone,
I recently came up with a useful solution to help deployments move along a bit more seamlessly for my organization. Our team uses the Agile Development application to create and track work for our sprints. We also use Update Sets to build and move our work from lower environments up to Production. It has always been odd to me that there is no link or related list that tie Update Sets to Stories. The below solution is to solve for that.
Considerations: Your deployment process may differ slightly or significantly from how our team does them. Below are the situations I needed to account for:
-
Our development happens in our Dev environment, but the Stories only live in our Production environment. Because of this, I could not just add a reference field to either table as the actual data is in two different instances.
-
We use the Stories Scrum view - List during the deployment process as a way to organize the update sets and sort them by the type of configuration item. This works well for the team so some of this process was built around still using that.
-
Maybe not out of the ordinary, but we can have multiple update sets that are tied to a single story. In the case that we have multiple update sets, we also need to determine which to commit first.
Solution: The solution here is pretty easy to implement -
- On the sys_update_set table I added two fields - A string field called 'Story Number' and an int field called 'Deployment Order'
- On the sys_relationship table, create a new record called 'Update Sets. The 'Applies to table' value will be Story[rm_story] and the 'Queries from table' value will be Update Set[sys_update_set].
The code that creates the relationship:
(function refineQuery(current, parent) { //Get Story number var storyNum = parent.getDisplayValue('number'); //Query Update Set table for matching story number values current.addEncodedQuery('state=complete^u_story_number=' + storyNum + '^ORDERBYu_deployment_order'); })(current, parent);
Form: - The last step is to add this relationship to your Story view - in our case the Scrum view. I chose to add a new Section to the form through the Form Configuration menu option. From there, select your new 'Update Sets' section and move your newly created relationship to 'selected'.
Final Result:
Hopefully this is helpful for others. Let me know if there are any questions or recommendations!
Hi @Adam,
You said in an earlier post the following:
the Story Number will be a field on the Update Set record,
So for some unclear reason, this doesn't seem to work for me. Both fields are created and contain data but the transfer to a higher instance does not include that info.
Even when exporting the update set as XML you don't find the 2 fields in question and their information in the Update Set. Bizarre.
@GMunee @Cdohert @valalves If you are working with remote instances, you won't see your update set in the sys_update_set table on the top instance. Update sets retrieved from lower instances are saved within the sys_remote_update_set table.
So create a relationship to that table and you will be all set 🙂
I was inspired by this but implemented sligthly differently to avoid customizing the OOTB update set table.
We already had a well implemented practice of entering story numbers into update set names following an initials prefix to identify the developer, so introducing a new field would create a possible source of error right from the start, and would require a change of habits for our devs. It would also not be "backwards compatible"; i.e. older update sets would need to be edited or not discovered by this logic.
Instead, I simply created a scripted relationship visible from Stories, i.e. a Related List viewing retrieved update sets where update set name contains story number.
I also created a scripted relationship visible from Release, i.e. a Related List viewing retrieved update sets where update set name contains any story number related to that release.
I purposely used retrieved update sets table, so that it's easy to see update sets related to a story whether they have already been committed to prod or not, and so the update sets would be visible in story/release without any new action needed to be taken. If we have stories that need to be tweaked after first attempt at going into prod, both older and newer update sets will be visible in the story as soon as they are retrieved into production. It's also backwards compatible, meaning when we look up older stories from before these related lists were implemented, as long as naming standard was followed by including story number in update set name, we can see all update sets connected to that story.
I'm now brainstorming how to implement keeping track of application versions for custom apps, so we can track in Stories/Releases which application version is published as a result of the story
