In the last post of this series we talked about how a repository manager, when coupled with a continuous integration server, allows you to work on individual modules in complex multi-module projects. In the post before that, we talked about the repository as something that enables greater collaboration between workgroups. In this post, I explore how using a repository manager simplifies deployment.
The following diagram shows the process of pushing code to production and automating a deployment:
This post will first discuss production deployments by setting up a hypothetical example. Assume that your organization runs a fairly complex application that consists of a few back office systems, a CRM system, and a web application. When your company needs to deploy one of these systems to production, the result is a highly orchestrated symphony of activity. Servers need to be taken offline in a coordinated manner across a distributed network of machines. Downtime needs to be planned and communicated to the right individuals, and backups need to be created before any new code is pushed to a production system.
In other words, any time you need to push new code to production, it is a real challenge to make sure that everyone is coordinating in just the right way. A few days before a production deployment, the development team freezes a particular branch and tags a release. This release is then installed in a QA environment. The QA team tests the release candidate, and if all goes well, this release is then deployed to production.
Without a repository manager, your operations teams has to know how to checkout a release tag from SCM, they have to run the entire build to generate a few binary artifacts, and then they need to write some scripts to automate a deployment to production.
With a repository manager, you can publish a release candidate binary to a hosted repository. This release candidate binary can then be used by a series of deployment scripts (or a tool like ControlTier or Puppet). You can have a deployment script that will publish the deployment to a QA environment, and then you can have a deployment script that takes the same, certified binary and publishes it to production.
The main difference between these two approaches is that the second approach adds some isolation between the SCM system and the deployment script. If your production deployment depends directly on your build, you have to recompile and repackage your entire system every time you do a deployment. This is often a challenge because the people that run the build system for deployment are seldom the same engineers that develop your system. If your operations team has to check out source code from an SCM just to build a production network, you are introducing some risk into your process.
Instead, use the repository manager as a way to share binaries with operations. If you are deploying applications to QA and production, having to rebuild an entire system from SCM just to deploy a system to an environment is an unnecessary risk. Instead of certifying tags in an SCM, your QA testers should be certifying binaries. This way you can be certain that the systems you are deploying to production have been tested.
