Changelogs. What do you use?

Forums › IT Pro and developers › Changelogs. What do you use?

tigercorp

668 posts

Ultimate Geek
+1 received by user: 81

#88367 14-Aug-2011 20:08

These days it seems like every customer we have wants a test, dev, training and production system. Great news for the company's bank balance but not so great for the engineers.

At present our internal processes for managing technical changes are pretty non-existent, very much relying on whoever made the change to document it (in a hard to search helpdesk app) and apply the changes to all environments. And then document that.

So I'm curious as to what everyone else does, both in terms of process and software tools used?

magu

Professional yak shaver
1599 posts

Uber Geek
+1 received by user: 7

Trusted

BitSignal

Lifetime subscriber

#506434 14-Aug-2011 20:14

Currently using TiddlyWiki with a company Dropbox account. All the authorized people have the most up-to-date copy of the essential stuff anywhere they go.

Non-essential stuff gets recorded in our own ERP (eating our own dog food).

"Roads? Where we're going, we don't need roads." - Doc Emmet Brown

sleemanj

1514 posts

Uber Geek
+1 received by user: 315

#506714 15-Aug-2011 12:47

Changelogs are what your VCS spits out (with appropriate humanising ;-))!

In so far as VCS I use a mixture of Subversion, Git, Mercurial and Darcs depending on what is most suitable for the job.

I do use TRAC with some projects, but as I'm sure I don't need to explain, keeping a wiki up to date isn't always top of the priority list for a programmer.

---
James Sleeman
I sell lots of stuff for electronic enthusiasts...

Ragnor

8279 posts

Uber Geek
+1 received by user: 585

Trusted

#506735 15-Aug-2011 13:09

Not sure what your specific applications are but yes +1 for VCS.

Usually only a handful of settings differ between environments eg: url, database connection string, storage location/path etc...

Those can be in separate config files you can switch via script for deployment or in the one config file that that you switch by changing an environment setting.

Ideally what you want is:

- Everything in a VCS
- Automated builds (continuous integration)
- All database changes should be done via migration, ie: all changes are scripts, all scripts have a version number. Typically copy version of the DB (test, dev, train, live) has a version table that knows what it's current version is so you can automate running all the scripts with a higher version number against the DB during deployment.
- Scripts for deployment (deploy to dev, deploy to test, deploy to live etc) that copy application files, update databases and change/switch config settings

Quite a bit of initial work but pays off in the long term massively.