5 Obstacles to Continuous Delivery in Embedded Software
Presented at Electric Cloud Spark 2013, October 16, 2013, http://www.electric-cloud.com/summit/ Based on content from blog-post at http://www.electric-cloud.com/blog/2013/05/03/5-aspects-that-makes-continuous-delivery-for-embedded-different/ Continuous Delivery means making sure your software is always production ready – that any build could potentially be released to users at the touch of a button using a fully automated process. This relies on comprehensive automation of the build, test and deployment process, and excellent collaboration across all teams involved. While the absolute majority of the general theories and concepts defining Continuous Delivery are very much valid also for embedded product development organizations, the typical technical environments are vastly different from what’s commonly being referenced. Legacy, infrastructure, lead times, and compliance are all very common challenges (in many cases intertwined with each other) that needs to be addressed if you are to succeed with Embedded Continuous Delivery. Finally it is also important to understand that the end goal of a Continuous Delivery implementation for an embedded product development organization is typically very different than what it would be for a product development organization based on web or cloud based technologies. This talk will discuss how the concepts of Continuous Delivery are applied across a wide range of embedded industries, highlighting 5 key aspects and common pitfalls that needs to be considered gating a successful Embedded Continuous Delivery implementation.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
5 Obstacles to Continuous Delivery in Embedded Software
- 1. 5 Obstacles to Continuous Delivery in Embedded Software Presented by David Rosen
- 2. Embedded Continuous Delivery Obstacle: Infrastructure
- 3. Continuous Delivery Defined Continuous Release Continuous Delivery Continuous Integration Agile Development Define Develop Build Test Release Operate Requirements Model Version Control IDE Compile Build Functional Non-Func Deploy Configure Provision Monitor • • • • Agile = frequent, smaller deliveries Continuous Integration = build/test every check-in Continuous Delivery = any build potentially released to users Continuous Release = release every good build into production 4
- 5. Embedded Continuous Delivery Obstacle: Legacy
- 8. Embedded Continuous Delivery Obstacle: Infrastructure
- 9. Embedded Continuous Delivery Obstacle: Infrastructure
- 11. Embedded Continuous Delivery Obstacle: Compliance
- 12. Embedded Continuous Delivery Obstacle: The End Goal
- 14. Q&A
Editor's Notes
- Agile = frequent, smaller deliveries Small batch sizesContinuous Integration = build/test every check-in Fail fastContinuous Delivery = any build potentially released to users Continual flow through processContinuous Release = release every good build into production Eliminate waste (WIP)On next slide, mention speed bumps (optimize constraint points)This is a generic representation of a software delivery pipeline. Across the top is coordination between stages and often times siloed groups which need to happen. But in each stage, such as Dev, are many other steps that need to happen in an orchestrated manner, to determine if the project can move to the next stage or not.This “pipeline” is modeled using a derivation of the lean manufacturing principles, which actually map well to software delivery as well. Lean manufacturing famously came out of the Toyota Production System, where they looked at how to build better automobiles more quickly. They did this by optimizing their constraint points, so that no work get’s backed up waiting for them. Work that is waiting is called WIP (work in progress) and is considered to be waste. The goal of Lean is to weed waste out of the system.This parallels software delivery where a slow build time, for example, can make a developer wait, and fall out of context, resulting in much more time and effort spent when troubleshooting. Another constraint area is in system/environment configuration, which can be needed at every stage of the delivery process, yet when done manually, out of context of the greater focus, can take weeks to accomplish.And so, accelerated software delivery requires an end to end system which is flexible to work with 100’s of tools, can integrate, manage, and fullfill the resource demands, and orchestrate activity across all of the delivery pipeline stages.