44 lines
4.5 KiB
Markdown
44 lines
4.5 KiB
Markdown
---
|
||
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:
|
||
|
||
[](http://popcyclical.com/content/binary/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! |