Automated Software Delivery Dataflow

As software developers, we are forever scheming on ways to increase the quality of our software. It’s a great feeling when customers are enjoying some bit of code that you wrote, so making it even better next time is a worthwhile goal. In contrast, I've observed a number of SaaS development shops have a lack of quality when it comes to the delivery mechanics. It’s as if once the software is written, the development effort is over and it’s time to tediously prepare for the deployment ceremony. What I want to write about is the deployment process itself – there’s a whole other topic relating to deployment project management which includes tracking changes, scheduling – perhaps another day on that.

The fact is that many software shops will deploy their services manually. This may (hopefully) include multiple environments for development, QA, staging, and finally production. Deployments will have checklists looking something like:

1. Log into target machine
2. Shut down service
3. Copy updated binaries
4. Make any configuration changes
5. Restart service
6. Repeat for every target

If the application has data/schema updates, it could be added as another step in the deployment process. Likewise, in a multi-target environment, there may be preliminary steps for switching out the targets from an application pool. Finally, in the case of a software emergency, a working roll-back strategy is essential. A few points:

• Deployment is time consuming
  • While each step may only take a few minutes, together it can add up to a significant chunk of a work day. Multiply that by the target count for the environment - lather, rinse, repeat.
• Steps are error prone
  • A missed or botched step may not be noticed until it’s time to turn on the service – or worse, afterwards. There’s a lot of click-click-typedy-typedy-clicking with not a lot of feedback.
• None of the steps actually require human interaction
  • I have never seen a deployment plan where all of the steps and details were not known beforehand. If the plan is not 100% deterministic, it’s probably more of a deployment idea and should be re-thunk’d.

Automating the deployment seems like a no-brainer. Ayende Rahien makes his views clear -

If you don't have an automated deployment, it generally means that you are in a bad position. By automated, I mean that you should be able to push a new version out by double clicking something. If you can't get automated deployment script in under an hour, you most certainly have a problem.

But how to get from source code to having it automatically deployed? It takes a bit of setup, but it’s well worth the effort for a project in active development. Here’s one potential dataflow:

1. Code gets written for the project and placed in source control
   • All code needs to be in source control – no exceptions!
2. Continuous integration triggers a build
3. Builds artifacts are created by the build server
   • For reliable builds, it’s important to have a dedicated build machine - magical or not
4. Project configurations for each potential target
   • This includes setting environmental variables and injecting any content needed to make the code run correctly once it is deployed
5. Automated Deployment
   • This is essentially a scripted equivalent of the manual deployment process

There are many open source and commercially available technologies catering to each of these functions – I'll dig into a few of them in some future posts. In broad terms, it’s a worthwhile endeavor to have an end-to-end software delivery process. It’s a guarantee that your time and energy are kept focused on doing what’s important – developing software!

CodeProject