App for storing ChangeLogs in database

[Thomas Güttler]

Hi,

we want to make the changes in our applications better visible for our customers.

We use several git repos:

- foo_customer: Here settings.py lives. It is quite small.

- foo_core: Central part of our application. The same code gets used for several customers.

- foo_plugin_bar: Just an example. There are several optional plugins.

Here is my current road map:

A nice interface for the customer implies: The changes need to be stored in
the database. This makes it easy to sort and filter the changes.

The origins of the changes are the git repos. I don't want to show
the customer our commit messages. I want a manual step from
commits to ChangeLog. But that's ok. This could be optimized later.

Use Case: A developer merged a feature branch into foo_core.
He needs to create a ChangeLog. The ChangeLog gets stored
into the git repo, but on the next deploy some tool reads
the new changes and puts them into the database.

ChangeLogs need to be tag-able: You can apply tags like "performance-improvement"
"new-feature" "bug-fix".


I searched the web, but could not find something like this.

Before I start to code, I want to get some feedback:

What do you think?

How do you handle your ChangeLogs.

PS: Our customers are normal (non programmers) people. They
don't want to see diffs or commit messages they don't understand.




--
Thomas Güttler
http://thomas-guettler.de/

[Mike Dewhirst]

I don't have a solution for you but maybe you are just looking for
strategies? Like you, I don't like showing users the commit messages.

We use Trac for our ticketing and insist no work gets done without a
ticket. We added a custom field to Trac called "Release note". So when
someone raises a ticket they are prompted to immediately write the
release note they want to see when the work is eventually done and
tagged for release.

I think this helps developers focus on what they have to deliver. If a
user writes a ticket (we encourage that) the user writes the release
note. Obviously it can be edited later if necessary.

The release notes for a tagged release can then be automated as a Trac
page and the displayed application revision number can be made into a
link to that page.

Works for me

Mike

[Russell Keith-Magee]

On Fri, Feb 6, 2015 at 8:24 PM, Thomas Güttler <h...@tbz-pariv.de> wrote:

Hi,

we want to make the changes in our applications better visible for our customers.

We use several git repos:

 - foo_customer: Here settings.py lives. It is quite small.

 - foo_core: Central part of our application. The same code gets used for several customers.

 - foo_plugin_bar: Just an example. There are several optional plugins.

Here is my current road map:

A nice interface for the customer implies: The changes need to be stored in
the database. This makes it easy to sort and filter the changes.

The origins of the changes are the git repos. I don't want to show
the customer our commit messages. I want a manual step from
commits to ChangeLog. But that's ok. This could be optimized later.

Use Case: A developer merged a feature branch into foo_core.
He needs to create a ChangeLog. The ChangeLog gets stored
into the git repo, but on the next deploy some tool reads
the new changes and puts them into the database.

ChangeLogs need to be tag-able: You can apply tags like "performance-improvement"
"new-feature" "bug-fix".


I searched the web, but could not find something like this.

Before I start to code, I want to get some feedback:

What do you think?

 

To me - it sounds like something pretty closely tied to your own development process, branching policies, and customer relationships. I have no difficulty seeing how this could be implemented as a Django app - and a fairly trivial one at that - your average change log is really not much more than:

class Change(Model):

    message = TextField()

    created = DateTimeField()

    change_type = IntegerField(choices=CHANGE_TYPES)

How do you handle your ChangeLogs.

Through a process that is completely unrelated to the commit process. 

For me, minimising the number of customer communications is key. I have difficulty getting users to read and comprehend the notifications I *do* send them - sending them complete change logs would be overkill, and would result in important messages (like YOU NEED TO UPDATE YOUR ACCOUNT SETTINGS OR THINGS WILL STOP WORKING) being ignored. As it is, these messages are often ignored, and I need to follow up with individual users.

My audience would gain nothing from a fine grained commit log telling them about every bug fix or performance improvement. They just want the system to work. If it doesn't work, they email me, and they'd like to know when it is fixed. To that end, I might not even send out a notification for a new *feature*, unless that feature is something that has been requested by them, or it will impact on the way they're using the system.

Lets be clear, though - I'm not saying your approach is *wrong*. I'm just saying it wouldn't work *for me*. You know your own users/customers better than I do. 

Yours,

Russ Magee %-)

[Thomas Güttler]

Am 07.02.2015 um 00:31 schrieb Russell Keith-Magee:
...

> To me - it sounds like something pretty closely tied to your own development process, branching policies, and customer
> relationships. I have no difficulty seeing how this could be implemented as a Django app - and a fairly trivial one at
> that - your average change log is really not much more than:
>
> class Change(Model):
> message = TextField()
> created = DateTimeField()
> change_type = IntegerField(choices=CHANGE_TYPES)
>
> How do you handle your ChangeLogs.
>
>
> Through a process that is completely unrelated to the commit process.
>
> For me, minimising the number of customer communications is key. I have difficulty getting users to read and comprehend
> the notifications I *do* send them - sending them complete change logs would be overkill, and would result in important
> messages (like YOU NEED TO UPDATE YOUR ACCOUNT SETTINGS OR THINGS WILL STOP WORKING) being ignored. As it is, these
> messages are often ignored, and I need to follow up with individual users.
>
> My audience would gain nothing from a fine grained commit log telling them about every bug fix or performance
> improvement. They just want the system to work. If it doesn't work, they email me, and they'd like to know when it is
> fixed. To that end, I might not even send out a notification for a new *feature*, unless that feature is something that
> has been requested by them, or it will impact on the way they're using the system.

Thank you for your reply.

That's the same here: The customer just want the system to work. And I don't want to waste our customers time
with announcements like "on page ... we improved the ... input field. You can do ... now". The are not interested
most of the time. But sometimes they are. And if they are interested, the customers should be able to get the changes
without talking to developers. And the changes should be aggregated to human non programmer readable sentences.

The ChangeLog I have in mind aggregates information of commit messages and tickets. This aggregation needs to done by a
human. It can't be automated, and I think it is worth the effort.

Regards,
Thomas Güttler