Introduction

ProjectDeployer is a python project I created to deploy our projects.  The aim is to make channel rollouts easier, repeatible, and easily audited.  There are two components to the project.  The ProjectDefinitions are a directory of our projects that each have a project.cfg file and optionally properties files.  The rollout script uses the project definition to perform the build.  For example, the svnurl is defined in project.cfg.  If this value is changed to a different svn branch, the rollout script will re-checkout the project from the appropriate svn path the next time that project is built.  If the commands are changed (switching from ant to maven) the rollout scripts won't need to change as long as the command name remains the same, e.g. build.  This will make more sense if you look at the rollout script and project.cfg formats bellow.

Installing

Copy the ProjectDeployer folder somewhere in your system.  (This contains the rollout script)

Go into the ProjectDeployer directory and copy and edit the config file

cp ProjectDeployer.cfg.in ProjectDeployer.cfg

Next, checkout the project definitions appropriate for your environment.  (Or create them)

svn co $SVNROOT/its/aim/ProjectDefinitions/trunk/development ProjectDefinitions

Usage

There are two components to ProjectDeployer, rollout scripts and project definitions.

 Rollout Scripts

Rollout scripts are run with the rollout command under ProjectDeployer.  Currently they're very simple.  It simply says run these commands on the project with the given path.  This path is relative to the ProjectDefinitions directory, which is defined in ProjectDeployer.cfg.  The project will be checked out under ProjectSource with the same relative path that it has under ProjectDefinitions.  Here is an example script:

# Example rollout script, #'s are used for comments

libs/utils build inject
aim/DisabilityServices inject

Project Definitions

Each project has a directory in the ProjectDefinitions folder (defined in the rollout config file).  Each project directory has a project.cfg file.  They look like this:

[Project]
name=DisabilityServices
svnurl=svn+ssh://indus@svn.its.calpoly.edu/home/svn/isi/chnldev/drc/DrcStudentChannel/branches/DrcStudentChannel_WF
[Commands]
deletedb=ant deletedb
createdb=ant createdb
publish=ant publish
spotless=ant spotless
inject=ant inject
clean=ant clean
depublish=ant depublish
build=ant compile

The commands are not required to have certain names. The rollout script simply runs the command for the given command name. However, by using a common name scheme it makes changes between ant and maven more transparent.

Any files in the project definition directory will be copied to the checkout directory prior to running commands. e.g. localbuild.properties

Issues and Limitations

There are a few issues with the current scheme:

• It's assumed that the .properties files placed under the project definition are same for all servers on an environment.

This isn't true for the portal and some other projects.  One workaround would be to create a syntax in project.cfg to specify which file to deploy, for example:

[Files]
diemos.its.calpoly.edu:/localbuild.properties=localbuild.properties.diemos
phobos.its.calpoly.edu:/localbuild.properties=localbuild.properties.phobos

• Currently properties files are only copied to the root directory, if needed the script could copy to a deeper path, but I haven't implemented this yet

Future Ideas

I was thinking it'd be cool to be able to switch projects into maintenance mode, run the rollouts across multiple servers and pause for testing.  Say we're upgrading a channel but it's database needs to be modified, we want to switch it into maintenance mode so no one will be using it while we upgrade the database.  We want to do testing on phobos while it's out of the loop, then perform the rollout on the remaining servers.  Such a rollout script would look something like this:

[phobos.its.calpoly.edu]
*out_of_loop
*shutdown
*start_maint aim/DisabilityServices
aim/DisabilityServices inject upgradedb
*startup

Then you would do your testing on phobos, afterwards, you would run a second script:

[phobos.its.calpoly.edu]
*into_loop

[diemos.its.calpoly.edu,futureserver1.its.calpoly.edu,futureserver2.its.calpoly.edu]
*out_of_loop
*shutdown
aim/DisabilityServices inject
*startup
*into_loop

I'm not sure if we could get permission to script the load balancer, but it'd be cool.