---
title: "Automated Software Delivery Dataflow"
date: 2010-02-28T21:03:24.838-06:00
slug: automated-software-delivery-dataflow
published: true
---

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 at a number of [SaaS](http://en.wikipedia.org/wiki/Software_as_a_service) 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: 
 
- Log into target machine.  
- Shut down service.  
- Copy updated binaries.  
- Make any configuration changes.  
- Restart service.  
- 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 before hand.  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](http://ayende.com/Blog/archive/2008/09/08/Requirements-101-Have-an-automated-deployment.aspx) - 
>  

*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: 

 [![Service Development Workflow](../media/images/AutomatedServiceDeploymentWorkflow_1325C/ServiceDevelopmentWorkflow_thumb.png)](../media/images/AutomatedServiceDeploymentWorkflow_1325C/ServiceDevelopmentWorkflow.png) 
 
- **Code gets written for the project and placed in source control** 
 
  - All code needs to be in source control – no exceptions!
 
- **Continuous integration triggers a build** 
- **Builds artifacts are created by the build server** 
 
  - For reliable builds, it’s important to have a [dedicated build machine](http://blog.ianuy.com/2009/06/07/the-importance-of-a-dedicated-build-machine/) - [magical or not](http://www.codinghorror.com/blog/2004/12/the-magical-build-machine.html)
 
- **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
 
- **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!