Monday, September 26, 2011

Automation: Auto-deploy

One of the biggest time savers that has been implemented recently at our company has been something that we call an auto-deploy. Our software consists of windows services, web services, web applications, and databases; installing and configuring a system to test against can take quite a while when doing the entire process manually. A handful of individuals here have been working to improve this process by creating an auto-deploy process that will automate the following:
  • Uninstall the software if previously installed
  • Copy the latest build of the software to the server
  • Install the software
  • Configure the databases
  • Start the software
  • Check the software status to ensure that it is running
This used to take easily 30 minutes and sometimes several hours. The problems before mostly revolved around finding the right configuration for the server and setting up the configuration in the database through a combination of wizard screens in our windows app and different pages of our web application. (Just to explain a little about the configuration, our software is capable of talking to multiple types of telephone switches and only certain servers in our lab are configured to talk to certain switches in the lab. Because not any server can talk to any switch, the difficulty was figuring out where the configuration for Server A's connection to Switch B is and then deciphering the excel document that the lab tech's use to keep track of the configured numbers on the switch.)

Now, within ten minutes I can have a system installed with the latest version and fully configured for testing. It takes about 20 minutes to setup an auto-deploy for a server for the first time, and usually within the first two or three times it is run, all of the kinks have been worked out for that environment.


The configuration for the server is now contained within a .yml file that is read in by ruby code which is called from a scenario in a cucumber feature file. A Jenkins job is setup for each server configuration, and this job runs the installation feature. Because it is in Jenkins, it is available to put on our reader board that shows each of our projects' build status.

Our team has already seen the benefit of this. There was a bug introduced in the code that caused the services not to start. Because we have this as part of our CI, we were able to know that a problem was introduced within an hour. Without CI and the auto-deploy, this could have taken days until another build was completed.