3
 Followers
10
 Likes

Integrate auto-tagging of application versions including description from Service Studio IDE when/after publishing a module

Lifetime
New

Currently, Lifetime Application Tag Versioning and especially its description - which is essential to allow commenting a user's module publishing (typically with project requirement identifiers, etc.) - are managed completely outside the development lifecycle, far from the developers' eye and frequently used tools (e.g. Service Studio IDE). This breaks the actual development flow, and is quite unproductive, since the team/tech lead frequently needs to validate which requirements have been identified and where in the developer's committed module versions. This situation is also degrading the traceability of business requirements to code (and vice-versa) and early detection of regressions.


Given these issues, I suggest a better way to promote the addition of developers' comments to their published module versions: allow Service Studio to provide an optional decision to auto-tag the application version corresponding to the module being published, with the addition of comments, which will be assigned to that application tag version's description - this same information can later be seen in LifeTime > Applications > (Application) > Version History, offering a full report and traceable relationships between code and project requirements.

 20201003exampleoflifetimeapplicationversionhistory.png
Created on 10 Mar
Comments (4)

Changed the category to Lifetime


One tool doesn't (read: shouldn't) fit all the purposes. In my opinion Lifetime is the correct place where you have complete visibility of the application, its modules, extensions, its dependencies, all the eSpaces. There must be an architectural choice to keep it like that and to be precise I would prefer to have the tagging possibility at the place where I can promote the application, as tagging is the release stream thing.

However, I agree that the commenting option must be there (I believe there was an idea already for it) in the Service studio where developers publish their changes. 

The Check-in comments idea as I indicated.

Thanks Swatantra,


I believe I understand your point: not mixing up different major features in the product. And from the feedback I'm getting in the check-in comments idea, my suggestion seems to bring some disagreements for bigger factories (even though I have suggested strategies to cater for it on that thread). 

I guess my attempt here was to request a minor feature in the product that could cover a major flaw many have been noticing. My other goal with suggesting this approach was actual field experience where, as stated above:

- the team/tech lead frequently needs to validate which requirements have been identified and where in the developer's [many] committed module versions;

- this situation is also degrading the traceability of business requirements to code (and vice-versa) and early detection of regressions;

I do understand that if commit messages are introduced in Service Studio, one could still do the above, but in my opinion it would still entail a lot of digging on too many developer "commits" i.e. publishing of module versions. 

One example I can bring from field experience is how I've used Lifetime Application Version History (shown in idea's attachment) to report developments/corrections to a Business Analyst team, and how they found this useful to track potential regression sources. In a sense, this approach helps closing the loop between the technical and non-technical teams. Hope this helps clarifying the need to bridge this disconnect between OutSystems Service Studio and Lifetime console.

views
214
Followers
3