Middleware | Xebia Labs
Deployit! 
Vincent Partington 10 Feb, 2010
Share 
In a recent post, XebiaLabs‘ CTO Vincent Partington discussed some important organizational topics you will want to address while introducing deployment automation using Deployit.
Preparing your organization is, of course, crucial to getting maximum possible benefits from deployment automation. A few technical considerations also apply when introducing Deployit, and here we’d like to go into these so that you can be sure your infrastructure is ready when it comes to carrying out your first fully automated deployment.
Preparing your infrastructure
Getting Deployit running on your infrastructure usually requires only minimal adjustments, but you’ll be able to get up and running even more quickly if a couple of things are set up in advance.
Configuring LDAP groups
Roles and access rights in Deployit are associated with users and groups in your LDAP. Once you have thought about who should have which permissions in your organization you can create the appropriate LDAP groups and assign users to them. Common examples are a developers group (or even one per application or “funtional area”), a set of deployers, middleware-experts and, of course, the administrators.
If some of your development is outsourced and you’re going to set up Deployit to allow externals to carry out secure “self-service” deployments, you’ll want to consider how to manage their access rights. One account per project or oursourcer is common, but we’ve also seen limited LDAP federation used here.
Identifying a Deployit host
In a normal installation, the Deployit server runs as a standalone Java 1.5 application. Its low resource footprint means that you don’t usually need a dedicated machine; we usually see Deployit installed on a “utility” box.
Since the Deployit server will attempt to make connections to the target machines, it is, however, essential to choose a host with network connectivity to all the machines Deployit will manage. The ports that need to be accessible will depend on the connection type, with SSH being by far the most common option. Of course, the Deployit server will also have to be able to access the LDAP used for authentication.
Users working with Deployit’s Flex GUI simply use a web browser to connect to the server. Obviously, they need to be able to make HTTP(S) connections from their local machines to the Deployit server to do this.
Preparing target machines
As Deployit is agent-less, no intrusive changes to the managed machines are required. A couple of small things are worth verifying before installing Deployit, though.
Obviously, the Deployit server will need to be able to connect to the managed machines, using the protocol and credentials given. Verifying that the specified account is correctly set up, can connect remotely and has sufficient permissions to execute management commands (refer to the User Guide requires authentication) is a good idea.
You can also use different credentials for connecting to the target machine and command execution, by specifying a SUDO user. If so, check that that user will be able to run the management commands.
Checking your middleware configuration
Deployit supports many versions of popular middleware stacks such as WebSphere, WebLogic and JBoss; check for your version on the list.
Since Deployit uses native management interfaces, such as wsadmin and WLST, to manage and deploy to middleware, you’re generally quite free to set up your middleware installation in your preferred way.
For some stacks there are a small number of requirements, such as wsadmin being installed. Also, if you will be deploying Java EE applications that are “fronted” by a web server such as Apache, Deployit needs to be able to modify the web server’s configuration. The documentation of the standard plugins describes these requirements in detail, and it’s good to check them in advance.
In some cases, such as deploying to Tomcat, certain features depend on specifc container configurations or modules. Deployments can also be carried out on a “bare-bones” installation, of course, which may well be enough for your needs.
Preparing data for your Configuration Item Repository
In order know how to connect to and manage your target machines, Deployit needs some information about your environments, such as the IP addresses or hostnames of servers, or the WAS home directory of a WebSphere cell.
By looking at the Configuration Items you plan to use, it’s easy to get an overview of the pieces of information required. Collecting these and extracting them from CMDBs and similar data sources, where appropriate, will make it easy to automatically feed them into Deployit via its Command Line Interface.
Next steps
Running through this checklist will put your in a great position to get Deployit installed, up and running and carrying out deployments using the out-of-the-box processes with a minimum of hassle.
Next time, we’ll discuss how to identify and evaluate the need for customizations to the standard process, and how you can go about further adapting Deployit to your organization’s procedures.
If you want to know more, these and other relevant issues – technical as well as business-oriented – are covered in detail in the free Deployit Training Series.
