Version control and release management

Question

Are there any so-called "version control systems" that also support actual release management / deployment ?

The mainframe shop I used to work for, had an automated release management tool that did not only control concurrent modifications to sources, but that also took care of running compilers, precompilers, database bind utilities etc. etc., making it our fully automated deployment tool as well.

My understanding is that "more modern" version control tools support only the source management part. Is that understanding correct ?

Answer 1

--> My understanding is that "more modern" version control tools support only the source management part. Is that understanding correct ?

The VCS just deals with the source management part, and it is pointless if you are unable you get notifications of the changes (and after someone implemented the vcs basics there will be no difficulty to provides this ;-) )

--> The mainframe shop I used to work for, had an automated release management tool that did not only control concurrent modifications to sources, but that also took care of running compilers, precompilers, database bind utilities etc. etc., making it our fully automated deployment tool as well.

This is called build automation, and yes, it's very desirable if the best bits of the project get "ready to ship" when someone makes a change but no necessary. You can do anything you want with the tools mentioned previously (they are extensible).

The continuous integration practice is the interpolation of these points in the way such that you only have a clean, stable, and noble code in the repositories. There are the so called CI servers that connects the VC and the BA parts.

check this page for CI http://martinfowler.com/articles/continuousIntegration.html

and if anyone needs a CI server compatible with many BA tools and many VCS take a look at JetBrains TeamCity

hope this helps

Answer 2

I am currently developing a web application for a release management and if you would like to be beta-user, please let me know. I have a working version for essential release management processes such as ability to create releases by cherry picking changes you want (while automatically taking care of dependency changes) and roll out or rollback to any point in release history to many different environments (test or production servers). Currently, it supports integration with SVN.

Please http://www.ngashint.com for the project's blog site. You can leave your email to start receiving a beta version or email me kzt001[at]gmail.com

Answer 3

This question caught my attention, because of the

'... so-called "version control systems" ...'

in the question, and because of the question being tagged with version-control ...

I'm coming from the mainframe world (too), and mainframe 'SCM' (=Software Change Management) is about all we've been doing for the past 25 years or so.

I'm a kind of surprised (maybe "shocked"?) to see all the so-called synonyms of the version-control tag. Especially the scm tag (and I'm not sure what the SE process is to suggest for no longer considering it as a synonym). SCM, at least in the mainframe world, is so much more then just version-control (that's just part of SCM). What about any of these somehow related topics (which are, IMHO, subfunctions of SCM):

• release management (part of the original question).
• deployment processes (part of the original question).
• impact analysis.
• approval workflows.
• trustworthy and usable test-environments.
• emergency procedures, eg during none business hours.
• automated rollbacks (backouts) that take like a few seconds only.
• auditing (governance processes).
• ... (on and on goes the list).

To illustrate how important all of them are, I often ask this question to think about: "What would it take to apply a (bug?)-fix to the automatic pilot software in a plane ... Inflight!?!?" In other words: "What are all the steps and procedures that have to be in place before you'd feel comfortable for such fix to be applied during a flight you're on?".

From the various answers provided before, I'm not sure (yet) which one of them, if any, to select for such inflight-bugfix.

Answer 4

It depends how much money and time you wish to invest in such system. many people use simple version control - like svn, and manage manually releases (using Labels, and branches) There are other (free) tools for continuous integration (constant building the app) like cruisecontrol.

IN the database field I don't know anything good in the free world, but someone here might complete this. so by now I manage database versions manually....

Answer 5

Version control has little to do with release management or deployment, so it makes sense that the VCSs don't try to do this as well.

What I've seen in this area are build or Continuous Integration (CI) servers. These listen to changes in the VCS, do a fresh checkout on any commit and then try to build everything. So they integrate the VCS and the build tools, collect the logs from them and present everything in a nice web UI.

This way, every tool can stay simple.

[EDIT] Added value of a CI server:

1. It can analyze the output of your build scripts and present an overview in a mail or a web page.

2. It makes sure that all tests are run after a commit. No more "but it runs for me".

3. Some of them support deferred commit (it will only commit changes to the VCS when all tests run)

4. It can run builds on several projects which depend on each other.

Answer 6

I think what you are calling release management here is more often called build automation. There are various tools in this space (make, ant, Nant, etc), but they tend to exist as seperate tools. The can often pull code from seperate source control, and you get products designed to oversee the process (which is called continuous integration when it is done automatically.)

There are some vendors who ship end-to-end tools which go under the heading Application Lifecycle Management