Implementing Deployit, part 1: organizational aspects

Last month XebiaLabs released the Personal Edition of Deployit. Now that people have been able to experience in a simple environment how Deployit can work for them, you might wonder how to start using Deployit for real in your development and operations environments. In this blog and its sequel we will go over the things we’ve learned when starting to use Deployit. We will also be covering this subject (and a lot of other subjects!) in our upcoming Deployit webinar series.

There are organizational and technical consequences to introducing a deployment automation product. But let’s focus on the organizational aspects first. These pointers will help you get started with implementing Deployit in your organization in the right way.

Involve the right people

Because application deployment is in essence a cross-departmental issue, you will need to find and involve everybody that it concerns. Depending on the organization of your IT department, that might be developers, application (deployment) administrators, system administrators, database administrators, infrastructure experts, etc. Each of these parties stands to gain from the automation of their part of the deployment process so it is good to get their involvement early in the project.

Standardize your deployment process

A very obvious thing to do before automating your deployment process is to standardize it. If each application uses a separate deployment process, it will be a lot of work to automate all of those. But more importantly, this is a good moment to no longer have a “mixed bag” of processes. With some analysis it should be possible to find one or maybe two different deployment processes that will work for all your Java EE application deployments. When standardizing your deployment process, have a look at the ones that come standard with Deployit. They are based on the recommendations of the middleware vendors (such as IBM’s redbooks) combined with XebiaLabs’ experience setting up deployment automation at a lot of sites.

Rethink ownership of (parts of) the process and the environment

While you are standardizing your deployment process, take a good look at why certain parts of the process and certain environments are the responsible of certain groups and possibly change that. For example, until now, test environments have mostly been owned by the system administration group which made it hard for the development teams to verify their work on this environment. To prevent the development teams from making incompatible changes on the test environment, most sysadmin groups have come up with a pretty tightly controlled process to allow developers access to this environment. This has usually led to a high overhead process with a lot of handover moments and waiting time. Because of Deployit’s security features, the system administrators can give development teams permission to deploy new versions of their application without having the ability to touch other applications or the other parts of the configuration.

Question any derivations from the standard

During the standardization of the deployment process, you might encounter certain areas where some special action is considered absolutely necessary. While that may be valid in some cases, we have seen quite a few cases where that is not the case (anymore). For example, some sites still prefer to keep static content separate from the WAR files and host it on the webserver. The reasoning behind this is that the Java EE application server would not have enough processing power to serve that static content. This has not been true for quite a while thanks to advances such as Java NIO and Edge Side Include caching. Always ask the 5 why’s.

Automate the quick wins first: deployment process steps

Deployit can automate every part of your application deployment process. But when you start out with Deployit it is a good idea to take it step by step. Identify the parts of the deployment process where Deployit will give you the most benefit, the most easily. For example, you might want to incorporate updating SQL schema’s into the deployment process but unless you perform a lot of SQL schema updates there is less benefit to be gained here. So you might leave that part of your deployment process a manual step for now. Then again, if you have a lot of problems with SQL schema updates starting here would be the ideal thing to do. Also, the plugin API of Deployit makes it possible to extend Deployit to support custom middleware systems (there are still a lot of ESB-like systems built on top of standard message queueing software out there!) but you will already gain an advantage when starting with the automation of your standard Java EE application deployments.

Automate the quick wins first: applications

Ultimately you will want to automate the deployment of all your applications, but you’ve gotta start with one of those applications. There are two tactics here: choose a simple application or choose the one that is deployed most often. Usually these are different applications. Our suggestion would be to start with that most simple application and deploy it to a number of different environment so you will be able to find out what configuration changes might be necessary there (SSH access, firewalls, etc.). Changing those things might take a while, giving you time to deploy the more complex applications.
As I had promised, this blog has mainly focused on the organizational aspect of implementing Deployit. Part 2 will focus on the technical side of implementing Deployit. We will cover such subjects as “picking the right unit of deployment”, “choosing a machine to install Deployit on”, and “how to import your current environment into Deployit”. In the meantime, don’t forget to join us for on the episodes of the Deployit webinar series (and don’t worry; you don’t have to be there for all of the webinars ;-)).