6

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 ?

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52

8 Answers8

6

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.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • I'm unclear how these provide added value beyond the standard "run your build process after a commit". It's a nice buzzword, but where's the value added that you don't otherwise have in your build script? – Paul McMillan Nov 11 '09 at 12:58
  • 2
    Run just about anything you please, distribute builds across multiple agents, build based upon dependencies, schedule long running builds and/or tests, run integration scripts, pro-actively advise users as to failures by multiple means, provide "dashboards" to allow you to look at all of the above, host build artifacts... in one sense yes, all it is automated script running but then that's like saying that all a build script does is run commands you can do by hand. – Murph Nov 11 '09 at 13:07
  • CI is more than a buzzword. We use CruiseControl.NET to not only build on commit, but also to run numerous tests including automated GUI tests. The CI server helps catch bugs or unexpected behavior closer to there introduction. The CI server usually knows the build is broken before anyone else on the team. All release candidate builds come from the CI server and therefore we can be sure that our whole suite of tests have been run on the actual the release binaries. – Jerry Fernholz Nov 11 '09 at 14:56
  • I've never thought of running deployment in a post-commit hook. Neat idea. But I'm definitely +1 on the idea of using a "proper" CI server, rather than the more lightweight post-commit hook method. Tools like CruiseControl.Net give you a bunch of extra functionality that's useful to technical management types that a post-commit hook solution would make it pretty hard work to get. CC.Net is what we've used in my last two jobs; it's definitely worth a look. – Owen Blacker Mar 22 '11 at 17:20
5

This is absolutely incorrect. Any modern version control tool supports both pre and post commit hooks, at which point you can run any code you want.

In subversion, we use the post-commit hook to deploy a copy of the app to the dev server every time a developer checks in code.

In our actual production servers, we have code that verifies and then deploys stable minor version tags as they are committed to the repo by the release managers.

Paul McMillan
  • 19,693
  • 9
  • 57
  • 71
  • 1
    I think your "This is absolutely incorrect" is ... not really correct. Also, about the "Any modern version control tool"; consider rephrasing that to something like "Many modern version control tools, such as X, Y or Z ..." (whereas subversion seems to be one of them, but what about GIT, PVCS, etc?). – Pierre.Vriens Mar 28 '15 at 12:59
  • @Pierre.Vriens Git seems to have quite a few [hooks](http://git-scm.com/book/it/v2/Customizing-Git-Git-Hooks). PVCS was first released in 1985... if you consider that a modern version control tool than I'm sure your are pretty satisfied with your modern windows 3.1 OS or something like that... – Bakuriu Mar 28 '15 at 13:10
  • Did I write that I considered PVCS like so? I just added that because I wonder if the author of this question would yes or no consider PVCS as one of these "Any modern version control tool". PVCS is indeed 30 years old, but "still around" (and used quite a lot ... still). And that might be "a" way to interprete "modern", i.e. "it still exists and it is still in use" ... – Pierre.Vriens Mar 28 '15 at 13:29
1

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....

Dani
  • 14,639
  • 11
  • 62
  • 110
  • SCM for databases is another challenge, indeed. In the mainfrare world there are (expensive) tools that do just that, typically from the big software vendors. In Drupal (upcoming version 8) there is what is called "Configuration Management Initiative", which tries to address this challenge about databases. – Pierre.Vriens Mar 28 '15 at 13:03
0

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

Colin Pickard
  • 45,724
  • 13
  • 98
  • 148
0

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

Horacio N. Hdez.
  • 651
  • 5
  • 4
0

In the ruby on rails world Capistrano is the deployment tool of choice.

http://www.capify.org/index.php/Capistrano

Jerry Fernholz
  • 685
  • 5
  • 11
0

This question caught my attention, because of the

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

in the question, and because of the question being tagged with ...

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 tag. Especially the 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.

Pierre.Vriens
  • 2,117
  • 75
  • 29
  • 42
0

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

kthant
  • 44
  • 2