Friday, March 11, 2011

Part 2: Continuous Deployment with Pinax and Jenkins

Part 1 is here.

So once Jenkins is running the code, we need a way to copy over that code to our staging server (we don't have a real production server yet). Our Jenkins user is the same as the staging server user, so it's simply a matter of copying things over in a script. If this were not the case, then we'd have to install the "Publish over SSH" Jenkins plugin and use that to copy things over and establish the symlinks.

Instead of having it as an additional step in the build process, our setup uses a separate task that is executed after the CI task is completed. However, we start off in the CI task's workspace so that we can clean up before moving things over.

Create a Jenkins Job:

Again, click "new job", select "build a free-style software project" and make sure the title has no spaces in it.

Job Settings:
  • Again, fill out a description. This is not going to do anything with Git or Github, so you don't need to fill out those sections.
  • In "Advanced Options", select "Use custom workspace" and put in the path to the CI task's workspace. The path is relative to the root Hudson folder (typically ".hudson"), so your path should be something like "jobs/[CI task name]/workspace".
  • Instead of polling, we will build after other projects are built. Check the box and type in the name of the CI task.
Build steps:

Step 1: Cleanup


Remember that this is starting from the CI task workspace, so the virtualenv should already be set up. We just use this to remove the pyc files before copying.

Step 2: Create new folder and copy


Simple script to create a new folder and copy. We use the environment variable "BUILD_TAG" to name our folders. It comes out as [task-name]-[build number].

Step 3: Start staging virtualenv and pull in external files


We use a separate virtualenv for the staging server, so we don't need .env anymore. We also copy a separate local_settings.py file and establish a symlink to the staging server's site_media folder.

Step 4: Update the staging environment's requirements and the database


We update the requirements using the same pip command from part 1. We then sync the database. We also use South for database migrations, so we also execute the migrations.

Step 5: Establish symlink and reload the code


We use mod_wsgi in Daemon mode, which means we don't need to restart the server once the code changes. mod_wsgi is using the "makahiki" symlink, so all we need to do to update the code is change the symlink. To be extra sure, we touch our wsgi script to make sure it reloads.

And that's it! We now have a project that polls Github, runs tests, and then deploys it. We can also rollback by changing the symlink to a previous build.

No comments:

Post a Comment