Anyone implementing software projects in a team these days can no longer ignore continuous integration. The benefits of the process outweigh the initial setup effort to such an extent that – except for very small projects – there is no rational reason not to work with continuous integration. In this blog, I would like to introduce continuous integration and our personal implementation in our software projects.
What is Continuous Integration?
Continuous Integration (CI) refers to the regular (preferably several times a day) merging of changes in a software project. The goal is to identify complications in software projects early on. This prevents a huge mountain of problems that could arise during the final merging after months of simultaneous implementation within a project. Part of the merging process includes actions that, in addition to compiling and linking, also check the software quality through automated tests. The entire process is implemented on a build server. This guarantees independence from local modifications by individual developers. Furthermore, a reference build is obtained, which can then be delivered to the customer later on. The IEC 62304 standard for medical device software requires such configuration management. Continuous integration is therefore a must for us, but it can also be considered state-of-the-art in other industries. To achieve this, version control is essential. In the next step, I would like to introduce the tool we use for this.
GitLab CI
GitLab is, first and foremost, an open-source version control system. It extends its functionality to include a wiki and a ticket system. Using GitLab relieves us of a lot of maintenance and validation work, making it an attractive tool for software development. Furthermore, it integrates GitLab CI, which enables continuous integration. GitLab CI is accessed via the file .gitlab-ci.yml configured in the repository. Detailed instructions are available GitLab CI/CD. Essentially, with every push to a build server, a pipeline for compiling, linking, and testing is started. Developers can track the exact output and are notified if an error occurs. At each step of the pipeline, the generated artifacts are automatically archived and made available for download. This allows specific artifacts to be assigned to each specific software version. Furthermore, visual feedback in the form of green checkmarks or red crosses encourages the generation of code for an error-free pipeline.
Our pipeline
Our personal CI pipeline consists of two steps. First, the project is built, followed by the testing step. However, everyone is free to design and expand their own pipeline. Before each job within the pipeline, the original state is restored to ensure a clean code base. This is achieved by checking out the latest version.
Below I will give a brief overview of our pipeline, its purpose, and the tools we use.
Clean Build
This step is the most important part of the pipeline and should be performed first. This is important because a successful build is a prerequisite for further testing. To ensure reproducibility and traceability, a clean build on a build server is essential. With every code change, the project is automatically built on a server with fixed settings. This creates a reliable code version that can later be made available to the customer.
Static code analysis
Even before testing the software with unit tests, it's a good idea to perform a static code analysis. This examines the source code for memory leaks, buffer overflows, incorrect casts, and out-of-bounds accesses, among other things. A well-known tool that we also use is PC-lint. This is commercial software with outstanding functionality. It offers, among other things, extensive feedback.
Cost is no excuse for static code analysis. There's plenty of free software available. We're using Cppcheck here. Its functionality is significantly more limited, but it's definitely worth using a free code analysis tool, as it can save you a lot of time and effort, while also improving code quality.
Doxygen
Another tool in our CI pipeline is Doxygen. This is a free software documentation tool. The tool's primary purpose is to create clear source code documentation. We don't use Doxygen's documentation feature for projects, but rather simply review the tool's warnings. This ensures that every function, variable, etc., has been explicitly commented and explained, thus ensuring good code review and generally good source code comprehensibility.
Ceedling
As the final step in our CI pipeline, we integrated a unit testing tool. Ceedling is a unit testing framework written in Ruby that uses Rake, Unity, and CMock. It is open source and specifically designed for the C programming language. Furthermore, the tool enables test-driven development (TDD). For these reasons, we decided to use Ceedling for our unit tests. Tests can be easily created and executed automatically. These tests test the source code for correct functionality and can thus also uncover errors that only arise later through additional implementations or code changes. The tool's feedback meets our requirements. This provides concrete feedback on where and what errors were found in the source code, allowing you to subsequently correct them. Of course, this requires writing meaningful unit tests. Ceedling is a practical unit testing tool that integrates various helpful plugins.
In an older article we already talked about Test coverage Generally speaking, it's not just the percentage of test coverage that's crucial, but above all the traceability of which lines of code have been tested and which haven't. Ceedling integrates the gcov tool. This makes it incredibly easy to calculate and display such test coverage. In addition to the percentage of coverage, you get visual feedback on which lines of a source file have been executed. This is very helpful for getting a quick overview of missing unit tests for a source file.
Conclusion
In summary, continuous integration is a standard that should definitely be applied to larger software projects. In medical technology, configuration management is mandatory starting with software safety class A. CI can contribute to meeting the configuration management requirements of IEC 62304. The pipeline design is, of course, variable, and you can use your personally preferred tools; however, the test concept must still meet the requirements of the software safety class. We chose GitLab CI to implement a CI pipeline because it also integrates other practical tools, such as a wiki or a ticket system. However, there are also other good tools for creating a CI pipeline.
Please feel free to contact us if you have any questions or need help setting up a CI pipeline.