My talk at JavaZone went surprisingly well. The fact that the projector went dead and that I was planning on opening with a demo raised my pulse, but I felt I managed to get my message across and that people were happy.
The talk was about how we use Jetty to manage the full deployment life cycle of our application. I explained how we had implemented this and what problems we had solved. Here’s a quick summary of our life cycle process:
- Test. All development activities should start with a test. For my presentation, I used an example of an embedded integration test
- Check in. All code should of course reside in a repository.
- Continuous Integration. Every check in is built and tested on our build server. The result is pushed up to our artifact repository (in our case, using Maven). We use hudson.
- Continuous Deployment. We have test servers use cron to poll for updates in the artifact repository, and automatically install the latest version. We check Maven’s metadata.xml to find out whether there’s a new version available.
- Release: After more testing procedures in the continuous deployment environment, the software is tagged as a stable release. We use maven-release-plugin for this.
- Preproduction: The tagged software is deployed to a staging environment for further verification. Since we package everything into a zip file in the Maven repository, this is a very simple process, requiring no special installation on our servers.
- Production: The software and routines are identical to the preproduction environment. The few variations between environments are handled through various mechanisms like Spring’s FactoryBean, which enable us to deploy the exact same software to production as we tested. No files are replaced.
The most important point I wanted to get across was that we don’t want to deploy into an application server. We want our application to contain the a server and everything else it needs to run.
When I spoke to people after my presentation, I could split people into a few distinct groups: Some people were using fairly light weight solutions, and the solution I showed was not very special. However, several people from “enterprisey” organizations like mine were very interested. What garnered the most interest was how we had addressed the organizational resistance to a non-mainstream solution.
It also seems like people using some application servers had much less severe experience from our own. In a way, WebSphere helped us out by being so utterly useless that we ended up throwing the whole concept of application servers out of the window. If our application server has been less broken, we might’ve decided to stick with it for even longer.
For future reference, I will focus on answering two questions: If you have a light weight solution, how do you create a rigorous process around using it, and if you want a light weight solution, how do you deal with the organizational issues of doing so.