From CI to Production, direct!

Submitted by John Ferguson Smart on Thu, 2008/02/07 - 10:39pm

Tags:

continuous integration

Crystal Reports - New Innovations Download a free trial and learn
about CR Server trade in offer! businessobjects.com

Ads by DZone

In a recent article in his TestEarly blog, Andy Glover makes the case that you should be able to use a Continuous Integration environment to produce and deploy production-ready software, well, continually. His case is that, while Continuous Integration is widely used to automate the build process up until, say, deployment to an integration or test server, it can be taken much further. Ideally, it can also be used to automate deployement of working software into staging and production environments.

This is certainly an admirable goal. It does not necessarily mean deploying into production whenever the code changes, an idea that would scare the pants off more than one CIO. Indeed, few big organisations would be willing to forgo the usual traditional (and somewhat bureaucratic) processes involved with production deployments, such as user acceptence testing, traceability, and formal signoff. This is often an essential safeguard in big organisations.

However Andy's suggestion that a CI server should be capable of building a production-ready application on command makes good sense, and is something at least one major client I know over here is trying to achieve - one-button deployment into any environment. We're not quite there yet, but it's the goal.

John is a freelance consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand. Well known in the Java community for his many published articles, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in open source technologies, SDLC tools, and agile development processes. John is principal consultant at Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Tomas Malmsten replied on Fri, 2008/02/08 - 4:38am

I fully agree with this. A build tool/CI tool should definitely be able to, at the click of a button/one line shell command be able to deploy a release into it's target environment. Be that development, QA, staging or live. In my experience allot of issues manifest them self in production due to mistakes in deployment that would never have occurred if an automatic process was in place. And what better tool to automate this process then a CI server. It's already specialised in this type of work.

Rui Campos replied on Fri, 2008/02/08 - 10:36am

In the project I've worked on the last 3 years, although we don't have a Continuous Integration system setup, we have a system to deploy on pre-production or production environments with a single command.

This is done through an ANT script (yes, we may need to change to Maven but things work fine with ANT) that has different targets for development, pre-production and production environments (invoked from the development environment) and:

Fetches the code from CVS repository with the appropriate branch (we have different branches for PP and PRD environments, as the system is live and we need to be able to anytime deploy an emergency bugfix to PRD even if we are in the middle of testing some new development in PP branch)
Compiles the code
Generates the EAR file (accoding to the target, different data-sources.xml and application.xml are used)
SCP the ear file plus some config files that may have been updated to the target environment
Invokes a shell-script on the server to redeploy the application (through SSH)

This setup is been working with success for 3+ years.

--Rui Campos

Mostly Harmless replied on Mon, 2008/02/11 - 9:17am

Rui, that sounds great. The problem is that YOU had to write it, and that it was written for YOUR organization. This feature should be more universal. Thats one of the benefits of Maven. We don't all have to write everything on our own. And once its written, we can all take advantage of it.