Seamless webapp deployment with Maven and Tcat Server

Discussions

News: Seamless webapp deployment with Maven and Tcat Server

  1. 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 automate deployment to Tomcat with Maven. I highly recommend you download it, along with Tcat, and trying it out!

    Threaded Messages (7)

  2. pdf is unreadable on my mac[ Go to top ]

    we've just released a new white paper which goes into the details of how to automate deployment to Tomcat with Maven. I highly recommend you download it, along with Tcat, and trying it out!
    The pdf is unreadable for me on my imac. Some weird font issues? Otherwise, I fully agree on continuous deployment being somewhat neglected in Java. Last year I was doing python and my staging server just had a cron job doing "svn up" every 5 minutes. You can't underestimate the value of having a server running the latest and greatest all the time. Basically the more people depend on that server, the faster bugs are found and resolved. In my current job weeks can pass between the introduction of a bug and somebody running into it. That puts a lot of pressure on QA, who in turn get very protective about their QA environment, which in turn leads to even more time passing between someone fixing a bug and it ending up in production. All these delays are fundamentally process related and not technology related.
  3. Sorry that you are not able to view the PDF on Mac, we will look into it. Have you tried downloading and opening it in the Acrobat reader?. Please let me know ( sateesh dot narahari at mulesoft ) if you continue to have problems, and I will email you in a different format.
  4. Sorry that you are not able to view the PDF on Mac, we will look into it. Have you tried downloading and opening it in the Acrobat reader?. Please let me know ( sateesh dot narahari at mulesoft ) if you continue to have problems, and I will email you in a different format.
    I haven't tried acrobat (don't really want that on my mac). This is the first time I run into a pdf that mac preview app can't handle. Since pdf is a native format to the mac, you might want to look into what is wrong with the way you produce the pdf. I opened it in the gimp and the gimp seems to be able to render the text fine, but not really suitable for reading the pdf of course.
  5. Just wanted to update that a new PDF has been posted that works on Mac preview as well: http://www.mulesoft.com/downloads/integrating-maven-build-and-tomcat-deployment.pdf. Also, the link to scripting console has an error. The correct URL is: http://www.mulesoft.org/display/TCAT/Scripting+Examples
  6. Hi guys, We still use continuous integration (build + unit test using CruiseControl (http://cruisecontrol.sourceforge.net)) followed with a full continuous deployment using AutoDeploy (http://buildprocess.sourceforge.net) in my company (http://www.fimasys.com). For your information, AutoDeploy is a complete deployment platform which supports complete JEE world (including datasource, jms, ear, war, etc) and "external" software using an update plan. AutoDeploy and Apache ACE have begin to merge to provide a full platform supporting both JEE, OSGi and "external" software. Resources: http://buildprocess.sourceforge.net http://continuum.nanthrax.net http://maven.nanthrax.net/net/sourceforge/buildprocess http://incubator.apache.org/ace/ Regards JB
  7. With automated deployment comes the need to change the way we test. Instead of just testing as the final step in a continuous build, we also want to be able to test updates as they are deployed to various stages of QA, all the way up to the production environment. Especially if you are deploying something that is built out of components (OSGi, Eclipse, Spring, ...) you want to ensure that all relevant tests actually work in the configurations that you have in production. Testing all theoretical permutations is simply too much. Testing only one static configuration is too little. This is one of the things we want to address in Apache ACE, and it's an aspect where we need to combine forces with other existing technologies, such as Pax Exam, Nexus and Maven repositories, OBR, etc.
  8. Really seamless?[ Go to top ]

    Is the deployment really seamless for JEE webapps? I mean users sessions are serialized and restored at new version of webapp? Without interruption, 404 errors and such?