Getting Started with Continuous Integration

If you want to get just a taste of CI’s benefits, start with the automated build step. Building each commit using all the relevant build configurations reassures developers that they aren’t breaking one configuration by changing another. It also removes the error prone and time-consuming manual build process from your developer’s workflow.

Recently, I was involved with a project that was exploring alternative hardware configurations. Each of these involved compiling different drivers for the hardware. Having the CI server build all these configurations made it a breeze to swap in different firmware to test our alternative hardware.

Once your static analysis tools are configured in CI, every commit will be scanned, and problems will be brought to your attention sooner rather than later. The CI server will also build and run all your unit tests (which you are writing, right?), confirming that the changes introduced as the program grows haven’t broken the foundation that you’ve built. You’ll also see when new units are missing tests. Could this be tested with a unit test on the host PC? If so, there’s no reason not to write the test and have CI record that your module works the way you think it should.

Why Use Continuous Integration for Small Teams?

The principle benefit I’ve found from using some of these CI approaches on small projects is that my confidence in my own software goes up. I can clearly trace out changes and understand that everything I had working and tested still works. I know that the linters are happy with the code, and I’m not introducing any spectacularly unstable code into the code base. I know from running tests off the side of my desk that the changes work, but I’m also more certain that they integrate nicely into the existing program. This confidence in my software base allows me to move faster through development cycles and pass working builds over to a tester sooner.

Setting up CI removes the developers from being a bottle neck for downstream tasks. It allows testers, electrical engineers, and others to fetch a binary from the CI server. If all they want to do is test new features or use a binary to exercise some hardware tests, they don’t have to set up the build environment and figure out how to build their configuration from source.

CI builds are reproducible, and the instructions for building the software are stored right alongside the code in the repository. Usually, the build will happen inside of a container such as Docker. The Docker file will also be stored in the repository and dictates exactly which version of the compiler, linter, and other tools to use. This makes aligning the team on the build environment easier. The CI server will act as the single source of truth for the build process: if the CI pipeline fails, then the build is broken.

Finally, CI for small teams encourages positive behaviours by developers. Things that might have been dropped in a fast-paced environment lacking CI will be respected with it in place. Running two or more static analysis programs over new firmware might be skipped in a rush, but the CI server will do it for every build. Developers will be aware of that. Even when it’s only me on a project, I find myself writing better code knowing that the CI server will run all its stages for each commit. This encourages better programming practice from the start, side-stepping common issues for small software teams such as missing tests and unhappy linters.

There is a non-zero cost associated with setting up CI, especially if the project is legacy code, lacking unit tests and using the integrated development environment (IDE)’s opaque build configurations. It is not the right fit for every small firmware project. CI will not help you write your business logic any better – instead, it guides you into writing cleaner code through linting and testing, which makes debugging issues in your business logic easier.

CI can support a successful medical device software development strategy, so if you are just starting your next project, consider standing up a limited CI workflow to automate building, linting, and testing. Your code quality will improve as your CI system keeps you honest, and you can focus on the more interesting medical device problems that need solving.