Posted on by SATURN Conferencein
Notes by Scott Shipp, edited by Tamara Marshall-Keim Impact of Architecture on Continuous Delivery Russell Miller, SunView Software, Inc. First, context: This was a greenfield, from-scratch project for a nontrivial social-monitoring tool. It was also their first attempt at the native cloud. It was a pilot for a truly agile project. Go to http://livepulse.co to see a beta version. Miller uses the term “continuous delivery” (CD) as defined in Jez Humble's book Continuous Delivery. It leverages continuous integration, automated testing, and automated deployment. Releases are frequent, small, and predictable. For example, take Amazon drone delivery. It eliminates waste, and customers do not have time to cancel the order. It also provides quicker feedback from the customer. So CD vs. the traditional release model is similar to drone delivery vs. freight train delivery. "This is a good metaphor for lean vs. legacy."
Another example is Formula 1 racing. CD is like a pit crew in a Formula 1 race. The product is continuously usable and made incrementally better like a race car going through a pit stop. The car is always running. CD provides the team continuous learning. Use the Act > Observe > Orient > Decide cycle to continuously learn and innovate. A key component of CD is the Build Pipeline, which is similar to a car assembly line or to a John Deere tractor assembly line. They are also following lean principles. The Build Pipeline allows you to talk about and measure releases by the "flow" through the pipe. How to start? SunView Software made a goal to deliver every week. They found that they had a bottleneck at deploying from testing to staging and production. Following lean principles, they stopped the line to do root-cause analysis about why things were not going well. But they stopped the line too often. Measuring done: