Blog
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

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

Automate the quick wins first: deployment process steps

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 ;-)).Vincent Partington
Contact