Fix image URLs to relative paths, add code block fencing

posts/2010-02-28-automated-software-delivery-dataflow.md

@@ -7,21 +7,31 @@ 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:  
+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. 
+- 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. 
+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) - 
 >  
@@ -30,15 +40,25 @@ Automating the deployment seems like a no-brainer.  [Ayende Rahien makes his vi
 
 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](http://popcyclical.com/content/binary/images/AutomatedServiceDeploymentWorkflow_1325C/ServiceDevelopmentWorkflow_thumb.png)](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! 
+ [![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 
+- **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!