The platform might aggregate all top-level elements which were modified, since the last publish and generate a comprehensive text, which would be added on publish and be presented in Service Center. Aditionally, the developer might add a comment, during the publish, to be appended at the end of deployment.

For example:
Added Screen Action to Web Screen CustomerList
Modified User Action Customer_ImportDetails
 

Kinda curious about why Outsystems haven't added this option. It is a must in any version control system.

Yes it would be great if we can enter check-in comments when publish. It can be optional but atleast the developers have a means to write comments on why there were changes and indicate the story number for the changes

This would be useful.

@alexander merged the idea

We would definitely need something like this.

I am also missing ability to OPTIONALLY comment version on publish time. (Sometimes would be nice to have that possibility also after publish.) Then you don't need to guess-open-publish multiple versions to find the correct version.

É uma observação considerável!

É uma observação considerável!

É uma observação considerável!

It is a considerable observation.

This is a good idea. I miss this option too.

Good to have, any comment from Outsystems about his?

It would be good to have an easily exposed or visible audit of who changed an action (and or page and or entity) and how.  

Some rough ideas:

Ideally implement a generic global to-do list to control what work gets done by a team, this allow the developer to link the to-do/job to a development change in the action.  

Allow the developers/project managers to group to-dos into sprints/versions and allocate them to developers. Audit the changes as we code.  

Show these change audits in the actions they were created in, show them aggregated to the eSpaces they were coded in, and also allow them to be viewed from the to-do list, so you can see what changes affected an action from a number of different angles.  

Create an aggregate of undocumented changes for the current sprint/release.  This would include the developer making the changes and when.

So in the development platform to-do list I would see:

To-do: Project X sprint 99.99.99 assigned to DevXXXXXX: #9999 Investigate and fix the bug returning the aggregate of users logging in more than once, which is miscounting the numbers.

At the top right of the action flow there would be a history icon that opens a panel showing the changes with the most recent change at the top.

In the history panel you can add a change comment to the current sprint.  You might make one comment, but publish a number of times.  Changes I think should aggregate to the latest change note you made. Some thought needs to be done around where a break is made.  For simplicity, work done in the same day I'd assume is the same task.

+ [your name appears automatically] [currDate()] [ToDo#] Type a comment.

If a change is made but not annotated then you will see:

+ [your name appears automatically] [currDate()] Added n actions, changed n actions, deleted n actions.
  

For brevity these messages are aggregated into a day's work for each developer who "touches" the code.

This audit would allow release notes to be created, filtered for detail.  For the management level you might only show the to-do and unallocated changes.  However to get finer detail on all changes for a sprint would be great.  Undocumented changes would be very useful for audit - in the case of mitigating the risk of fraud or tracking down competency issues.

Some automated notes/audits are better than none.

Unfortunately I am seeing more and more audit questions around tracking what developers are doing.  Having some reliable audit of the changes made would be a great thing to just give them!

Simple to use and unobtrusive is perhaps the best starting point.

Hi Richard,

I think you should make a new idea for that. I like the idea but that's too big for this idea.

Cannot state enough how useful this would be to allow proper version control and allow you to go back to specific versions!!

Very surprised that it has not been realized even after 9 years since the first post.

I'd like to know why this idea is not adopted.

It's about time to implement this idea, I would say. As Tiago stated above, it is important for the developer to state WHY he made the changes (see: Commit Message Guidelines, How To Write a Git Commit Message)

In addition, if the team is using an issue tracking system, there should be a reference in the check-in comment to the issue the developer is working on. This reference could be just plain text or, better yet, a link to the issue.

As other have mentioned, adding a comment section while publishing your changes should be the number 1 priority. Adding an optional text field for developer comments while publishing your codes may not seem like a ´cool´feature but it is something very very practical and plain useful.  Please prioritize this feature.

IMHO at least having the possibility to Add a comment to each Publish and then a way to view and search these comments would be a good starting point.

good idea!!!

Quite a long post, but still with many interested folks :D 

In my latest projects I've been successfully working with a new approach to application commits: everytime a developer ends his work the involved applications get tagged with the respective project issue number and a brief description. This is not left to the deployment stage but instead everytime work is completed on an assigned task. What we are just missing now is linking Lifetime Application Version Tag feature with a Developer's Service Studio 1CP, optionally. This idea is fully detailed in https://www.outsystems.com/ideas/8213/integrate-auto-tagging-of-application-versions-including-description-from-service - check it out!

Lifetime and tagging at the application level - very bad idea. Tagging must be at espace level before publish. 

Pedro -

You're tagging work for Feature A, meanwhile a developer doing bug fixes is halfway done and their work is getting tagged for release as well. It isn't *just* that this needs to happen on a per-module basis as Sergey points out, not per-application, it's that people need to keep their work out of the release stream until it's ready for release. This is not something I would recommend.

J.Ja

Justin, 

what you described is classic development using git branches.

Unfortunately, this approach doesn't work in outsystems. No feature branches.

We have a common app with 15 espace. Including one module with about 4000 entities. This app is used by about 50 other apps and 60 developers who are developing new functionality in these apps. Tagging at the application level causes chaos. And deploy on the production environment for applications just turns into hell.

Sergey -

Yes, that kind of branching is desperately needed for larger factories as well.

I'm actually working on an app now that basically rides on top of publishes and when someone publishes asks them to provide details and optionally tie to a Jira ticket.

J.Ja

Hi Justin, Sergei, thanks for replying. I do see some limitations with my suggested approach for larger factories, but at the same time, I also see some extreme cases being described here that perhaps beg other solutions. Read along, please.

Regarding the scenario Justin described, it's precisely because we should not just tag an Application Version when we go for deployment, but every time a developer ends his assigned task, that I recommend my above approach: this already improves traceability of business requirements down to the code, to a reasonable degree. The kind of Applications I'm talking about here use the OutSystems typical composition (i.e. aggregating code modules into a Core Services app, or end-user modules into End-User Layer app, etc.) - this helps avoiding a high number of developers on the same app.

I also totally agree with Justin that it would be beneficial to have such "commit-messages" visible at a module's level, but until we don't have that possibility, maybe the suggested approach already brings some advantages, if the straightforward one is harder to implement.

Also, the suggested approach (of using Lifetime Application Version Tags to trace development of business requirements) does not intend to tackle branching at all: this should be avoided, if possible, in OutSystems [since the product does not support it, as Sergei well mentioned above], or tackled with other means: e.g. feature flagging/toggling, if branching cannot indeed be avoided. This approach only solely attempts to resolve the traceability matter (e.g. where was this JIRA# developed in the application version history/single trunk?)

Sergei, regarding your scenario, any sane reason why you have to deal with a module with 4,000 entities? Could those be broken down by some feasible means (e.g. functionally)? This would certainly help to keep track of different development tracks (branches, if you will) in the application... perhaps this would be a good discussion to have in another (community forum) thread, though. 

Pedro -

Tagging also makes "delete old versions" find many less items that can be deleted, *also* a problem.

Yes, feature flagging is the only option right now. It's something I *personally* don't mind. The overwhelming majority of OS users and potential customers reject it as an option. Regardless of what my feelings are on the subject, it's not what people want. This has been a high-demand change for a long time now.

Right now I am working on a component that enables *proper* comments and labeling and tying things to Jira as well, though I am waiting to see if the check in comment system will be addressed soon and how it is addressed if it is.

J.Ja

Justin, thanks for replying once again: I was not aware that tagging also makes "delete old versions" find many less items that can be deleted... sorry, but isn't this related to Solution versioning? I find that odd to occur, honestly, since application tagging occurs at a different system data model (or at least different entities e.g. Application, Application_Module) than the ones bound to "delete old versions" feature in Service Center (i.e. Espace_Version and Solution_Version).

Looking forward to get to know that component, myself often struggling with JIRA and business requirement traceability, too. Let me know if I can help!

Pedro -

Yesterday I was deleting old versions in an environment, it told me there were 6000+ versions that couldn't be deleted because they were tagged, and there are only 3 or 4 solutions and each one only had 2 - 3 versions. Lifetime uses Solutions under the hood. So I think what's happening is Lifetime is marking things so that you can't delete the Modules.

The whole system is really in bad shape. With the 100 GB limit in cloud DEV environments and no bytewise comparison on the versions of of modules thanks to encryption & compression... most active environments can't keep more than a few weeks of versions and at the same time removing them is a hassle.

It needs a rework from top to bottom. :(

J.Ja

Hi Pedro.
>>Sergei, regarding your scenario, any sane reason why you have to deal with a module with 4,000 entities? Could those be broken down by some feasible means (e.g. functionally)? This would certainly help to keep track of different development tracks (branches, if you will) in the application... perhaps this would be a good discussion to have in another (community forum) thread, though. 

Historically, this module was the first to be developed by the first team. Then there were more than one teams. Now there are 25 of them. More than half of them use Entity, which is in this General large module. The list of consumed dependencies of this module is close to 200. For example, you can't make 25 tables with clients. There must be one table. This is how the 4000 entity runs in the module. We wanted to redo it and divide it into modules, but it turned out that the list of dependencies and table usage is so large, and the tables are so interconnected, that it is impossible for each team to develop its own functionality without stopping.

For example, there can be up to 10,000 places where a single shared table can be used in a single module. Multiply by an average of 15 teams that use the table, and we get the inability to redo the code.

Every code change (refactoring) must be tested, so in addition to the developer's work, there is a lot of work for testers.

Hi Justin James, sorry for the delay in getting back to this thread, but I had to double-check your described scenario of Lifetime tagging affecting removal of old module versions - I was not at all expecting this behavior, sorry! The good news is that there is already a solution for that (just hope you and other fellow community members have compatible platform versions) - OutSystems Support replied me the following:

...is it really true that LifeTime Application Tagging affects deleting old versions?

The answer is yes. Let me elaborate a bit more on this topic since deleting old eSpace versions can be affected by mainly by:

1. Solutions- If you do have old solutions that reference old eSpace versions then, those specific eSpace versions are bond to those existing solutions, and, due to that, you won't be able to delete the eSpace versions. In order to delete them, first, you will need to delete the Solutions that contain them.
   
2. LifeTime tags- Tags in LifeTime, can be blocking some versions from being deleted just like the Solutions do. Since the LifeTime Release Feb.2019 version it's possible to delete application versions (LifeTime tags) using the new method of LifeTime API v2.

   DELETE 
   /applications/{ApplicationKey}/versions/{VersionKey}/

   Using this API method you can delete selected tagged versions, so you can then retry the deletion process. In order for you to have more context about this API please consider the following article here, 
   • Don't forget to follow the guidelines presented in REST API Authentication to authenticate your API requests. As already stated once you implement some logic to release the Tagged Versions it should be possible to Delete the versions of the modules bond to those tags.

Pedro -

No worries! But Service Studio most definitely does not use that API (because it skips tons of versions to delete), and I suspect DB Cleaner and DB Cleaner on Steroids don't do it either, don't have time to dig through the code right now... but the big point is that the system-provided tools for killing old versions is basically broken by tagging. And with only 100 GB in OS PaaS non-PROD... it usually takes a team on a project 1 - 3 months to fill the non-PROD DB.

J.Ja

Hi!

I would like to add some more information from my experience regarding deleting old versions of espaces.

There are many things that can prevent an old version of an espace from being deleted successfully (undeleted entities, undeleted timers, undeleted site properties, etc) but two main reasons are:

1) Versions of solutions;

2) Tags of applications.

Regarding solutions, to be more precise, you do not need to delete the solutions, you need to delete the versions of the solutions.

In particular there is one system solution "OSMonthlySnapshot" that at the first day month of each month gets a new version created, so you will most likely need to delete old versions of this solution to be able to delete old versions of espaces.

Regarding applications, and assuming that you have LifeTime installed on its own separate environment, you do not need to use LifeTime API to delete application tags in LifeTime; you just need to delete the application tag from the environment that you want to delete the old versions of espaces, normally the Development environment. I have found that LifeTime keeps its own tags of applications in its own metamodel.

To delete application tags in the environment you can simply use DBCleaner, menu Applications.

Take the example below for the application "Silk UI Web" where in LifeTime it still exists all all tags, but in the Development environment the tags 3.3.0 and 3.3.2 have been deleted.

--Tiago Bernardo

This feature becomes particularly relevant when we think of Requirement to Software traceability. Adding something like "US #XX [feature name]" to a publish message can be extremely usefull when trying to figure out where and when some US was implemented.

Totally agree, Also it will be nice to show what changed from the previous version.

Totally agree, Also it will be nice to show what changed from the previous version.

It would be very useful to distinguish versions, when we are trying to open a different version and have to do a trial and error until we get the desired version.

Great idea.

Thanks Daniel!
I hope this will be implemented soon. 

I am amazed at how long this idea has been out there and how many upvotes it has received and it is still not implemented. I've come into an existing project which has been worked on by many people around the world, and the lack of comments in publishing makes it extremely difficult to find when and why certain elements were changed. There is also no ability to add comments on screen elements, which is also deeply disappointing and frustrating.

Version control comments that can be linked to your ALM system too - Very handy.  Currently Jira is out ALM system of choice.

It would be nice to have the possibility to add comments during a check-in. Currently, I use adding a description by tagging a version in Lifetime. Sometimes changes must be made to multiple modules. 

It's a good idea.

Additionally, we could use this information when generating lifetime tags (timeline). And analyzing these values would make it easier and more effective to fill in the description at the time of the tag.

Sorry, I haven't seen it in my search, but it is very good.

By the way, I will leave here the mockup menu sample I made for my idea submission.

Amazing, after 12 years, almost 8000 visualizations, 160 comments and nearly 600 likes keep "on the radar" status. !!!!

Any update on this 12 year old idea yet? 

This idea is the result of the merger of various ideas, including one version of mine. To be honest, I don't really need this anymore. I submitted the idea before LifeTime existed and back then it was much harder to keep track of changes. With LifeTime it is possible to add a comment when tagging an application. With this you can include the issue number when tagging a new version of applications, keeping a clear overview of what was done in a version.

Hi,

Other traditional Version Control Systems allows this feature and is widely used in perforce and Git.

Nice Idea !

It would definitely be very helpful to be able to index a note when publishing a module (optionally, of course), specially when there multiple developers publishing different versions. 

For example, there are some technical debt issues that do require some testing when they are "fixed", and to be able to know which version contains which fixes, would be of utmost importance if something goes wrong. Same applies for the maintenance aspect of an application that's already deployed and being used on a daily basis!

{The Need} As a developer I want to be able to add my comments each time I publish a change to my app. 
{The How} Display a popup window with description box (max 2000char in length) at the time I click on the green 1 Publish button in Service Studio. 
[The Value] So when I need to recover to any of the previous versions I can see a description for each Publish/App Release that was made in the past. [Where] In OutSystems Service Studio > Click on Module > Open Other Version > In the 'Open Other Version Popup Window' add new column between the 'By' and the 'Published' columns. Name the new column 'Release Notes'

Any update about it ?

Nice Idea, will be more helpful in-order to track the changes.

Does anybody have a manual process or workaround they are using to track the change against a development ticket number?

OutSystems needs to implement this feature. But in the meantime how do people handle this?

Hi Adrian, please refer to my earlier post in https://www.outsystems.com/ideas/70/check-in-comments/#IdeaComment31168 happy to discuss further in private if you need more details.

Hi,

It is possible to implement this, we did it recently and are trying it out.

High over how we implemented this:

1. Developer says he/she starts on ticket xxx
2. We register every module version of that developer on ticket xxx
3. Developer says he/she completed ticket xxx

This way you tie each module version to a ticket.

It allows multiple developers to work on a ticket, still you can track the work per developer per ticket.

We build this as a lifetime plugin.

Regards,

Daniel

@Daniel Kuhlmann

Question 1:
On step "2. We register every module version of that developer on ticket xxx", so  does this then mean you have some kind of process running in the background monitoring new versions of modules published by the developers and then making an automatic comment, or something of that sort, to the ticket in whichever system the ticket exists (Jira, or whatever)?

Question 2:
Theoretically, a developer should only be actively working on a single ticket at a certain moment in time, but what happens if the developer is working on more than one ticket?
Is this prevented to happen in step "1. Developer says he/she starts on ticket xxx"?

Question 3:
And, does this mean that that system, a plugin in LifeTime as you mentioned, then needs to be in sync with the ticketing system (like Jira) to know what tickets exist in the system, correct?

This seems to be a good solution for the direction "Ticket system -> Modules versions".
But what about the other direction "Module version -> Ticket system"? This is what normally is of more interest when doing deployments:
   For these versions of a module that I want to deploy, I want to understand what are the tickets that are included in those changes.

--Tiago Bernardo

1. Yes, it filters the module versions and connects them to the developer.

2. Unless he has 2 hands on 2 keyboards, a developer can only work on 1 ticket at the time. Start/Stop, Start/Stop is how to track 1CP to a specific ticket.

3. We have this as a preliminary version, no integration with ticket system, it is on the backlog, to connect to the correct ticketing system.