So, in conclusion, you need a tool to :
- automate and ease deployment, (roll back too , ..)
- keep history of change in configuration file ( they can be changed between two release due to production issues, investigation, …

Laurent, thanks for your comments. I agree with what you have to say, probably it would be a part of our production infrastructure though. I wanted to bring about the minimalistic infrastructure for the dev team. You are right that once we get to production there are bigger things to worry about. Automated deployment is one part of the pie and indeed an important one.

So, I’ll try to give more details.
Imagine a simple app (in a large/medium company). It’s made of :
1) An apache frontend
2) a web service (tomcat/jboss/…)
3) a database.
Of course, to be scalable you’ll have a load balancer between 1 and 2, and between 2 and 3.
You’ll have monitoring application, network configuration ….
So, when you deploy your whole system (made of main 3 applications) you deployed in fact a bunch of jar file, of RPM, CPAN/YPAN modules, and you need to update a set of configuration files (httpd.cong, my.cnf, app.xml, log4j.xml, ….). If you are lucky, your application is very well design and coded, and all your webserver instance have exactly the same configuration …. but because of hardware upgrade, developper … most of the time, configuration defer from one box to an other one.

So, in conclusion, you need a tool to :
– automate and ease deployment, (roll back too , ..)
– keep history of change in configuration file ( they can be changed between two release due to production issues, investigation, …)

Currently i’ve not seen much tools doing date efficiently (maven work very well to package application using only Java, but as soon as you want to deploy RPM/CPAN module with your application, you need to add an other layer to your framework to deploy your application, and it doesn’t offer any mechanism to keep history of configuration changes.

To illustrate, let say i’m an RPM addict, and I’m using yum to deploy my application.
So, i would like to use yum to deploy my application on my CI farm, in order to validate my deployment process in the flow ….. and the problems start here , integrating such tools/framework in a CI flow …… it’s a mess !

(note, i’ve not talk about dynamics allocation of server in my CI farm, or about virtualisation in order to increase server usage, or to reduce my electricity bill, or to ease some tests I should wrote a dedicated post on that.

Hope that’s more clear, and that I’ve not lost you in my explenation.

Thanks for your comments. I guess you are right the build tool is very important and that is the reason that I mentioned maven and ant. I agree on your point of build tool being responsible for 3rd party jars and reports and I maven is capable of doing that.

I am not sure if I fully understood the distribution/configuration management server part. My understanding of Software configuration management can be handled with tools like CVS /SVN. May be you can elaborate.
And yes there may be a couple of boxes missing but as I said during the start of the post, this is the minimum configuration that you would need to start with. Of course with the complexities of the environment you may need more.

I think, there is one (or two) missing box : the distribution / configuration management server. An application in large/medium company is not only a war file you deployed on a tomcat/jboss, but a bunch of webapp/monitoring tools/cron/…. and so, such a box, alimented by the CI (packages in nightly/release mode) will help to deploy the CI farm, the QA and the production.

In the tool family, you should also point i think virtualisation tools. It’s an easy/cheap way to test several configuration, and to have several CI line having some small differences (in lib versions, OS, …).

You may also check out our Parabuild for Continuous Integration. It includes statistics for CheckStyle, PMD and FindBugs and integrates with Bugzilla.