Andrew Graham, Tektronix
Applying Continuous Integration principles and practices to embedded software is often frustrating and full of challenges unique to working alongside, on top of, and within a hardware-centric ecosphere. One such challenge overcoming a purely development environment mindset and attempting to test a customer experience before the product is in its final revisions. This proposal covers three key concepts core to employing Continuous Integration in Embedded Software: Minimum accessibility, abstract communication, and abstract hardware configurations. In order to test the physical product in an automated system then some accessibility exceptions must be made, but, to the smallest extent tolerable. When considering how to test a product then the ideal approach is to utilize methods available to end-users and abstract them so that the appearance of automation is simple and coherent for engineering to consume in day-to-day development. The number of physical configurations that a product could potentially be in often times far exceeds the number of prototypes available for testing. So, a methods need to be available that allow engineers to quickly and easily reconfigure an instrument without anxiety that they are potentially making a breaking change to automation.