The practice of continuous integration (CI) is well established within traditional C development environments and is at the core of agile workflows.  Model-Based Design processes are able to extend the base level of CI testing through the use of simulation to validate functional behavior.  While this is possible in traditional environments it requires the development of specific test harnesses which the MBD environment provides for “free”

Continuous Integration: Background

There are 5 best practices for CI systems

1. All source objects must exist in version control: Source objects are used to create derived objects such as C code or test results.  The derived objects do not need to be kept in the repository.
2. All operations on the objects must be automated: Operations include code generation, running test, collecting code metrics.
3. Any commitment to the repository should trigger a build and test operation:  The “level” of test can be set for each check-in.  If the impact of the check-in is localized then a subset of the tests should be run.
4. Results from build and test are easy to interpret: Every build and test operation should generate a report.  Results in that report should be easy to interpret and, in the case of errors, easy to trace back to the root cause of the error (e.g. which file resulted in the failure.)
5. Minimize build and test execution time: To the extent possible the execution time of the build and test operations should be minimized.

The continuous integration workflow

The continuous integration workflow has two primary paths, an event, and temporal based triggers.  With the temporally-based trigger, the testing environment is run at predetermined intervals, generally nightly and weekly test runs.  With the event-based triggers, the testing environment is “triggered” by the check-in of a model or related data objects.

Testing levels

To improve the speed of test execution the concept of test “levels” is introduced.  At each level, the pass/fail criteria are assessed and if passed the next level for that model can be run; failure results halts further testing.

Level	Info	Runs
Level 1	Smoke tests to ensure that the model updates and passes basic modeling guideline checks	Check-in, Nightly, Weekly
Level 2	Functional testing against requirements	Checkin, Weekly
Level 3	Coverage and functional testing	Weekly

Final considerations

There are multiple continuous integration servers such as Jenkins and TeamCity.   Further, there are multiple version control programs that can be combined with the CI servers (such as Git or SVN).

The key consideration is the set up of testing infrastructure “patterns” that enable simple integration with the CI system down the road.  These testing patterns will be covered in a future post.