EDA & Development
Continuous delivery - hope over experience?
Frequent updates of components and systems can compromise both quality and increase the cost of production. Mark Warren looks at some of the techniques being used to provide effective and continuous delivery for embedded systems
low down … we’ve got plenty of time to get the new product out. Let’s think about all the things we think the market needs, build it, ship it and retire to the coast.” Anyone heard anything like that recently? I doubt it! Customer expectations and competitive
“S
pressures now demand very frequent updates of components and systems than has been seen before. Three-year product refresh cycles might be a luxury today, however there is still a lot of R&D, design and validation to be done even before building boxed product ready to sell. How can new products be developed and shipped much more frequently without compromising quality or costs? There is no single solution but some
process improvement lessons might be learned from other development teams. For example, software development projects used to take years from inception to release, but today many teams are making releases daily and even the most traditional industries, such as banking, are looking for significant updates at least quarterly if not monthly.
Continuous delivery
The key enablers for such rapid change in software development have been Agile methods and, more recently, “Continuous Delivery (CD).” Agile methods cover a spectrum of activities, but in general, focus on delivering usable functionality in small chunks (usually at the end of a “sprint” of development that might be only a few weeks) and then re-planning and repeating the process. This ensures the products being delivered are as the customer expects and allows for changes in the plan to reflect changing environment or customer requirements. Continuous Integration (CI) automates the process of building and testing the software components ensuring any errors in the code are found early and are cheap to fix.
CD takes this concept further into the
software lifecycle to automate the deployment of those tested components into staging and, ultimately, production servers.
32 October 2013 Components in Electronics
www.cieonline.co.uk
Can these approaches be adopted by embedded systems developers? It may seem like an impossible goal.
Surely hardware can’t be continually re- built and released into an assembly line as frequently as that? Prototypes can be expensive and time-consuming to build. Setting up production lines in a fabrication
plant is not something that companies want to do too often. However, there is still significant opportunity to benefit from the best practices of CD. For example, hardware designs might be developed and tested or simulated before making physical prototypes. The firmware or applications running on the device can adopt CD relatively easily and, when done well, can ensure the software components are correctly delivered alongside the hardware.
Continuous delivery made possible
Key enablers for software CD are automation and a single source of truth or system of record to manage all the elements of the project.
The heart of this capability is the versioning service being used, for example Subversion, Git or Perforce. The versioning service has to be able to manage all types of digital content – hardware designs, source code, test plans, test data, system environment configurations, build tools, documentation, but not all version management tools can handle the non- source code assets efficiently. For teams that are geographically distributed, or working in parallel, a common version management system ensures visibility of changes and easier collaboration. If conflicting changes are flagged during check-in, either by the version management system or CI build & test, then the version management
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48