The Lean Startups movement has produced several important and successful techniques that can yield benefits to all types of organizations. One of these is continuous deployment — a process in which all code written for an application is immediately deployed into production. The result is a dramatic reduction in the development cycle time and the freeing of individual initiative. You can read about it here as described by Eric Ries.
Implementing the continuous deployment methodology can be difficult if you are developing Java EE applications, which come with inherent delays associated with the complexity of deployment and restart times for most Java EE servers. However, if you are using a lightweight, efficient application server such as Apache Tomcat, you have an advantage.
Additionally, some of the features of MuleSoft Tcat Server are uniquely suited to help you achieve continuous deployment for Tomcat applications. For example, Tcat Server’s Maven plug-in allows you to export a WAR file as part of the build process, and scripting capabilities enable the Admin shell to listen for events such as the upload of a WAR file and automatically kick off a deployment to the test servers. If QA were forced to go through a formal process of notifications, manual deployments, and documentation, a continuous deployment strategy could result in them spending more time on documentation than on actual testing. Instead, the capabilities provided by Tcat Server can dramatically cut that burden, making continuous deployment a realistic undertaking.
When you deploy applications as frequently as many times a day, you need visibility to diagnose problems quickly. Tcat Server’s web application diagnostics for Tomcat will give you just that: deep visibility into your application running on Tomcat. The ability to look at Tomcat information such as memory utilization, threads, connector traffic can determine if the most recent deployment is problematic. If the latest deployment has problems, you can easily roll back to a previous version from a central location using the Tcat Server console.
Continuous deployment does not mean lack of accountability, and when you do deployments frequently, you need to keep track of the deployments, their status, and roll back to a previous version if required. Tcat Server keeps track of all your deployments, including success or failure codes, and provides you an option to restore back to a older version of the deployment.
Continuous deployment does not mean going light on quality either – most application changes require testing before going into production, depending on the nature of the change. With Tcat Server, moving an application from dev to QA servers is as simple as editing your package definition and replacing the dev server group name with the QA server group name, so you can perform the required QA (or pre-production) testing.
Another consideration for lean startups is the “TechCrunch factor” – what happens if you get coverage in a popular media outlet and your traffic suddenly goes through the roof? You need the ability to quickly add more capacity to support the increase in traffic. Using Cloudcat, you can create new instances of Tomcat in the cloud in minutes, and with Tcat Server you can manage those instances seamlessly with your existing on-premise Tomcat applications.
If you are lean startup or a company that is using lean techniques, I would love to hear your experiences doing continuous deployments. What worked for you and what didn’t work?
