Xebia Labs
Deployment automation vs. build automation Vincent Partington 12 Oct, 2010
a. Run create table definition SQL scripts against the database. b. Configure JDBC data source in the application server c. Configure http ports and virtual hosts in the application server so the application is reachable for http requests d. Install the application on the application server e. Start the application f. Configure the firewall, by opening ports to allow communication between the http server and the application server g. Configure an http server so requests that are coming in for "www.app.com" that do NOT end with e.g. .js,.html,.gif are routed through to the application server h. Place the static html content on the http server i. (re-)Start the http server so it reads in the new configuration j. Configure the outside firewall, to allow access from "www.app.com" to route to the right http serverOf course, a more complex environment just adds steps to the deployment step list. For example, in a high available clustered environment, I have to do everything at least twice and make sure that all the components are configured and (re-)started to run in that clustered environment. A deployment really is... The above steps make sure that "an application is available to end users" in production. They can generally be broken down into the following deployment categories, and thus this is what a deployment really is:
1. Installing applications (Step d.) This is the core part of the deployment, where the actual application logic is installed on the server, in J(2)EE/Java this usually means installing an EAR or WAR file. 2. Configuring resources (Step b.) The application might need data from other systems, like databases or mainframes. The application can use resources to query for or receive data. Resources are typically configured in the application server. 3. Configuring middleware components (Step a, c, f, g, h, j.) To reach the application or to provide an instance where the application can run or house data on (e.g. create application server clusters, http server instances, create database instance, create/update tables) middleware must be configured. 4. Starting/Stopping components (Step e, i.) To make sure that a component can function properly, it might need to be (re-)started. 5. and doing all the above (1, 2, 3, 4) in the right order. To make sure the application starts up nicely, without errors some order has to be maintained as what component needs to (re-)start at what time. E.g. If you install the application (step d.) and start it before the data source is configured (step b), the application might not start up properly. This becomes even more important when deploying a new version of your application in a high available clustered environment. There is one additional category for companies that use a DTAP (Development, Test, Acceptance, Production) environment setup: 6. Configuring the installed application for different environments A deployment must make sure to customize the configuration to suit a specific environment. E.g. when you install an application on development it needs some data from the development database, the same application in test needs data from the database in test, and so on.What a deployment is not... A lot of people seem to think that installing the application on an application server is the actual deployment. Sure, the button in the application server administration console says, "Deploy application" but that will only do the application server part and will only work in simple environments, like the development or developer workstation environments. As soon as the application reaches a more complex environment with multiple middleware components it just does not cut it anymore and you need additional steps to make the application accessible to test/end users. What or who can do a real deployment Most people are relying on other people to make the real deployment happen, manually configuring middleware, pressing the deploy button in the administration console and all that other stuff. Some are trying to automate deployments and are relying on deployment scripts or products like Phurnace or Buildforge, but these will only do a very small part of the real deployment, only installing applications (see category 1 above) and configuring resources (see category 2 above). There aren't many products around on the market that can do "real" deployment. XebiaLabs offers a product named Deployit that has supports for all 6 deployment categories. Be aware of what it takes So if you aren't in the lucky position of having access to a product that does real deployment, be aware of what needs to be done to get your application available to the end user. Do some scripting, make use of deployment tools and reserve time in your project to let (operations) people configure those middleware components manually.