Link bug/ticket numbers in version history to details on the issue

On our radar
When the version history for a release is posted, there are bug or ticket numbers, but no way of learning the details of the issue. It takes us some time (a total of about 10 hours) to upgrade all of our servers, so the more information we have about what problems are fixed in a release, the easier it is for us to make the decision to upgrade or not upgrade. The one-line problem description often does not contain enough information to make that decision.


Created on 29 Jul 2013
Comments (1)
I don't if this is what you mean but I think I have a similar need and I have developed a solution but it needs some more integrations with servicestudio and LifeTime.

We have a ticket system for change management, where the backlogs gets posted and after aproved it follows the workflow until it's ready to be handled by the Developers.
In our case we have a continuos delivery mode, so we deploy often and most of the time there are several developers working on diferente change requests.

I felt the need to know exactlly what espaces/applications to deploy according to the tickts that are aproved to be placed in Production.

I can connect the change requests with the Outsystems eSpaces but this is done outside of service studio. The developers, before initiating the development, associates the request with the eSpaces that will be changed. After this I know exactly what espaces/applications need to be deployed to place a change request in the Quality/Production Enviroment.

It would be great if this association could be done inside servicestudio so that I could even know the esapce version number associated with request.

The way I see this working is, the developer would download the espace inside Service Studio and he would be asked to select a change request number associated with that download.

Of course this some more orchestration would be needed with external ticketing (webservices, API, ...)

António Braz