Check-in comments

By André Vieira on 10 May 2010
In OutSystems Platform publishing is like comitting your changes to Version Management.
It would be extremely helpful to be able to add comments on the 1 Click Publish process.
This would be even more flexible if one could drill down these comments by changed object (webscreen, webblock, action, webreference action, etc)
J.10 May 2010

Yes.

would be great with linking them with ect.

Joop Stringer11 May 2010
Be careful what you wish ... I was working with Microsoft TFS before and there we needed to add comments to a "check-in". It turned out to be a blank or just something stupid like "checked in".

So make it configurable within an eSpace wether to have comments on check-in
J.11 May 2010
we cannot fix the developer ;)

we wish, but we cannot.

Fernando Sousa11 May 2010

One should be able to add comments after publishing an eSpace, extension or solution. This should be optional.

This comments could have information on the new features, whether or not it was a valid version to rollback to, name of the project in your external sourcecode control application,  etc.
Gonçalo Veiga11 May 2010

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

 



Merged from 'Auto-generated publish description (ex. Added Screen Action to Web Screen CustomerList)' (idea created on 2010-05-11 12:16:53 by Gonçalo Veiga), on 2010-05-28 10:59:34 by Paulo Tavares
J.11 May 2010

almost the same as http://www.outsystems.com/wisdomofthecrowds/IdeaComment_List.aspx?IdeaId=70

only with added auto-generated comments


Merged from 'Auto-generated publish description (ex. Added Screen Action to Web Screen CustomerList)' (idea created on 2010-05-11 12:16:53 by Gonçalo Veiga), on 2010-05-28 10:59:34 by Paulo Tavares
Lúcio Ferrão11 May 2010
I personally prefer automated change logs instead of comments :)
Lennart Kraak14 May 2010

I've already requested this in the forum before, so I totally agree with you. I think it's very handy to enter the issue number for example when publishing an eSpace.
Fernando Sousa14 May 2010

Although automatic comments would be nice, specially for development environments, I think that it is important for users to be able to add their own comments in the production environment.

Imagine you're responsible for deploying eSpaces into production. Automatic comments like "Action CUSTOMER_Create changed" might not give you the details you would like in order to understand what's new in that version; you might want to add that customer's email address is now mandatory and validated using a regular expression, and that a welcome email message will be sent to new customers.
Tiago Bernardo17 May 2010
Automated change logs is not enough. If you know what has been changed but you do not know WHY it has been changed, it is not very helpful.
Jose Venceslau4 Jun 2010
I've asked for this for some time but haven't followed through on implementation.

This would allow a cursory look on the versions of an espace on service center to know what each release was about.

The automatic change log and the custom message are both useful, the first because if gives a nice overview for operations and project management ant the latter for the developers.
João Carvalho29 Jul 2010
There is a long time that in the service center - factory - espace versions i miss a column with very brief info about the published version.
It happens quite often having to download and open the espace to know which version is what, what differences in code were added, it it is a production hot fix...

It would be very usefull to be albe at publish time to enter a small label (even if only 10 characters length) to be able to distinguish later on, in the service center, that version from the others in case of need.

In the studio a simple button like "Add label to this version" would do it.
If would be blank for default  each time the espace would be published, unless the user would explicitly press the label button and fill it.

In the service center there seems to be enough space for a 10 char column that could spare a lot of time looking for versions, specially the old ones.

Tkx!

Merged from '[Service Center] at espace versions tab, add a column (label) with short info about each published version' (idea created on 2010-07-29 10:50:50 by Joao Carlos Carvalho), on 2010-07-30 11:04:42 by Pedro Oliveira
Matthias Preuter30 Jul 2010

Must have!


Merged from '[Service Center] at espace versions tab, add a column (label) with short info about each published version' (idea created on 2010-07-29 10:50:50 by Joao Carlos Carvalho), on 2010-07-30 11:04:42 by Pedro Oliveira
Fernando Sousa30 Jul 2010

Similar to Check-in comments.


Merged from '[Service Center] at espace versions tab, add a column (label) with short info about each published version' (idea created on 2010-07-29 10:50:50 by Joao Carlos Carvalho), on 2010-07-30 11:04:42 by Pedro Oliveira
Hugo Bento20 May 2011
I agree with Joop, be careful to make this comment not required but optional. In TFS the option to comment all chek-ins are nice but stupid where you are obligated to do so.
Diogo Cordeiro27 Aug 2011
This is just a wonderful idea, and very, very useful one mainly if you could integrate this comments in OutDoc...

This is particularly useful when you really have to register those changes, either because you are working on a multi-environment, ,multi-development, highly dynamic team (and want to measure the level of changes in the code, while trying to figure out some way to optimize those changes) or because you are making changes to a crytical system already in production, and want to keep track of what developers really did. (the next step would be to convince the developers to write useful, optional, comments for their changes).

Have you ever had to track all your changes manually (with comments) into an Excel File? 
Well I had, and classify it as dangerously boring, self-depressing, and probably the first step into the abiss (or out of the room) (of course, if there is an alternative and you keep doing it, then you might go on and just pretend you don't enjoy masochism)

This option is very useful and needed in my opinion.

additionals:

- Wrap commands of different espaces together when creating a   Solution.

- Overview of changes by eSpace in ServiceCenter.

- Search functionality to search trough commands. This can be useful when searching for incident number for example.
It would be interesting to be able to write a comment for each new publication.
Today we do this when using the cvs or svn, in each commit we can put the number of issue related to change.
With this we have a traceability for each commit.


Merged from 'It would be interesting to be able to write a comment for each new publication.' (idea created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho), on 2013-04-04 16:09:41 by Gonçalo Borrêga
J.22 Mar 2013
is this not the same as : http://www.outsystems.com/ideas/70/check-in-comments/

Merged from 'It would be interesting to be able to write a comment for each new publication.' (idea created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho), on 2013-04-04 16:09:41 by Gonçalo Borrêga
J.22 Mar 2013
Oh thy edit-button, How I miss thee!!

Since I cannot edit the post, here is another go only with a proper link now: http://www.outsystems.com/ideas/70/check-in-comments/



Merged from 'It would be interesting to be able to write a comment for each new publication.' (idea created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho), on 2013-04-04 16:09:41 by Gonçalo Borrêga
Sami Niemelä7 Aug 2015
This discussion is the closest to what I found when looking for a way to generate *release notes* automatically after deploying a new version. In another set up, I have been used to giving a Jira issue number as the check-in comment and then the build system labels the issues in Jira with the build number. Similar functionality would be very handy, since customers always ask "what has changed".

In short: please add check-in comments and go a step further so that this can be used for generating release notes.
In Service Studio, it would be helpful to allow user to add comments/notes before uploading or publishing the app. This comments field should be stored with the uploaded version. It should be visible to user in "Version History"(Service Center) and in "Compare and Merge with Another Version or File"(Service Studio).  This way, user and his team will know the important notes/comments about a specific version if they want to rollback to it. This comment field should not be less than 500 characters long.  

Merged from 'Allow user to add comments before uploading/publishing' (idea created on 2015-09-18 05:00:11 by Peter Areewatanakul), on 2015-09-19 08:09:20 by Goncalo Borrega
J.18 Sep 2015
similar to http://www.outsystems.com/ideas/70/check-in-comments

Merged from 'Allow user to add comments before uploading/publishing' (idea created on 2015-09-18 05:00:11 by Peter Areewatanakul), on 2015-09-19 08:09:21 by Goncalo Borrega
Doug_inVA28 Jan 2016
Another vote for this - surprised this basic functionality is not available as of yet 
Really missing that.
It would be useful to be able to have to option to add version comments at the beginning publishing cycle. Something similar to the Changesets of Team Foundation Server (TFS) within the Microsoft Visual Studio IDE. In my company, we sometimes have 2 or more developers making modifications to the same project at the same time. If someone breaks something, it would be helpful to have some idea what they were working on. The version number, change date, and changed by are rather sparse. Especially when you have over 1,000 publishes in a short period of time.

Merged from '1-Click Publish - Ability to Add Version Comments' (idea created on 2016-02-29 19:03:03 by Daryl Van Johnson), on 2016-03-01 08:43:48 by Goncalo Borrega
SamyCode16 Oct 2016

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

Currently it is very hard to identify a set of changes made in the past when trying to track down an issue.
There may have been hundreds of these 1-Click publish events between deployments. It seems that you can only add comments at deployment time.
#MissingRealisticSourceControl



Merged from 'Add revision comment to the 1-Click Publish feature' (idea created on 2017-02-01 20:36:07 by Anthony Sitterly), on 2017-02-02 08:55:28 by André Vieira

This is a duplicate of an Idea that gets posted up fairly frequently it seems.

J.Ja



Merged from 'Add revision comment to the 1-Click Publish feature' (idea created on 2017-02-01 20:36:07 by Anthony Sitterly), on 2017-02-02 08:55:28 by André Vieira
Alex.11 Feb

I think the title says it all.

When you publish an oml, you must deploy a non-mandatory message field, which allows the developer to briefly identify the changes that he made, and later become available in the different versions of eSpace on service center.

I currently have a workaround, by changing the oml description whenever I make a change that I want to be identified in the service center.



Merged from 'Publishing comments' (idea created on 2017-02-11 20:48:59 by Alex.), on 2017-02-12 21:25:36 by André Vieira
J.12 Feb

roughly the same as http://www.outsystems.com/ideas/70/check-in-comments




Merged from 'Publishing comments' (idea created on 2017-02-11 20:48:59 by Alex.), on 2017-02-12 21:25:36 by André Vieira

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.

Give the option to add names to a version you publish or have published before so you can look back to what you've changed in that version. 

This makes it easier to use the version system like some sort of version control.



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.

Wouldn't that be the same as this idea https://www.outsystems.com/ideas/70/check-in-comments ?



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.

Yap, agree. Probably the same problem with two slightly different solutions ;)



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.

Yes, you're right. I didn't see that idea before posting this :)



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.
J.6 Oct

@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?

Richard Tilbury24 Nov (3 weeks ago)

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.


Johan den Ouden26 Nov (3 weeks ago)

Hi Richard,

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