One of the things I've noticed over the years is that when deploying web sites, there is often a bit of friction between engineering and operations hand off. For some reason, lots of people miss that process improvement and automation does not need to stop at the build process and continuous integration server.
Granted there are those that do tie in their build process to their deployment. There is even a term for the extreme form of this: continuous deployment. It means that any change that you check in will automatically propagate itself all the way to the production site eventually - provided it passed all its tests. So if I fixed a bug, it would automatically roll itself out! Unfortunately, it would also do the same if I introduced a bug - which is what makes this a bit extreme for my tastes. But I see great advantages of applying this model to at least the development and test/QA portions of app deployment.
- Changes become instantly available and testable.
- By focusing on automation, applications become more self-contained over time. There are no ad-hoc configuration changes during deployment.
- A well done deployment mechanism should also have a rollback mechanism, making downgrades in case something (inevitably) goes wrong.
- It can incentivize developers to work in chunks that are manageable. (For a very thought provoking read on this, I might recommend this article.)
- If you've automated your development and QA side of the web site, it makes automating the production upgrades (and rollbacks) that much easier. It should just be a simple promotion of a build to a larger site cluster.
So when we created
Tcat Server (MuleSoft’s enterprise version of
Apache Tomcat), this was one of the things in the back of our minds: how can we make application deployment seamless and continuous?
It became clear that we could integrate with the build process through our repository and APIs. As part of the build and release process, the build can be published to our repository via a Maven plugin we created. This build can then be pushed out to any number of servers with a few clicks. This opens up some interesting options:
- You can automate deployment to test machines whenever a new build is uploaded via our scripting console.
- Once you're ready to go to production, your operations team can select the new version of your application, hit publish and have the application available.
- Since applications are stored in the repository, you can easily select an older build and roll back.
Of course I'd be remiss if I didn't highlight that some of this depends on having self-contained application. If you have to do application specific configuration, like configure database resources inside your server instead of your application, it quickly increases the amount of work a release takes, and inhibits your ability to automate it without much more complex tools and testing. The goal should be to make the cost of doing a release zero.
This is why I also have an aversion to some of the deployment automation tools out there (YMMV). I would rather not be scripting configuration changes or scripting installation of various software packages into my server. I much prefer an environment where I have a static machine image which is used, and I can deploy my application into it.
This is not to say Tcat Server doesn't have the ability to help you do per-server configuration – we have some very cool tools to help people do this in our R2 release coming out soon.
Right now though, we've just released a new white paper which goes into the details of how to
http://www.mulesoft.com/downloads/integrating-maven-build-and-tomcat-deployment.pdf">automate deployment to Tomcat with Maven. I highly recommend you download it, along with
Tcat, and trying it out!
