3 Tips for Getting Started with CI/CD

In "5 Embedded Software Trends to Watch in 2024," I pointed out that one of the top trends is adopting and improving continuous integration/continuous deployment (CI/CD) practices. The idea behind CI/CD is that teams need to automate as much of their development processes as possible.

Today’s embedded systems have become too complex and sophisticated for manual work. Sure, you can’t get away from it, but there is so much in the development cycle that can be automated. Automation can streamline development, decrease costs, and time to market if leveraged properly. 

In today’s post, we are going to look at three simple ways you can get started with CI/CD for embedded software. 

Tip #1: Quantify the Value

Teams considering adopting CI/CD often make a simple first mistake: they don’t quantify the value that CI/CD will provide them. I absolutely believe that every embedded team probably should be using CI/CD, but you can’t know that for sure if you don’t know the benefits and costs of implementing it. 

Start your CI/CD journey by quantifying what it will take time and cost wise to get started and then what the benefit will be. For example, you might look at the cost of implementation such as:

Related:5 Embedded Software Trends to Watch in 2024

The costs for tools and training are nothing compared to the costs for your team to learn and use the new tools and processes that must be put in place. Once you do understand the costs, you must ask yourself:

Asking the above questions in a vacuum is not going to give you the full picture though. You must have the value statement side, too. For example, you also need to quantify the benefits such as:

If you take some time up front to analyze what you get from CI/CD versus the cost, I think you’ll find that it provides a good ROI. 

Tip #2: Build Automation

The easiest and lowest hanging fruit to get started with CI/CD is to get your software to build automatically. Build automation is the critical first step. It gives you the experience to set up a reusable build environment and scripts to control your pipelines.

A reusable build environment is often accomplished using a container tool like Docker. Docker allows you to package the environment and tools you need to build your software. That container can then be used to build your software on the server, but it can also then be used by developers to build the software during development! 

Related:5 Tips for Becoming a Successful Embedded Software Architect

It’s not uncommon for bugs to crop up due to developers having different build environments on their computers. I once ran into an issue where a colleague had a compiler version that was 0.0.1 versions ahead of mine and it had a bug that caused the code to crash and burn! 

Containers help ensure that everyone is working with the exact same tools, in the exact same environment. That includes your fledgling CI/CD pipeline! 

The same environment is important because when you run a job in your CI/CD pipeline to build your latest firmware, the environment on the server should be the same as the one you developed code in. Otherwise, you could end up with the pipeline saying that your code doesn’t build, when in fact, it could just be a server configuration issue. 

Build automation is a great first step because it allows you and the team to verify that your most recent commits actually build successfully. While you might wonder, who would commit code that doesn’t work? It does happen. It’s not uncommon to make a small tweak to the code that seems fine only to discover it doesn’t build. (Ever forget a ; when programming in C?)

Related:Fast-Track Your Embedded Product: 3 Essential Time-to-Market Strategies

Tip #3: Automate Code Metric Reporting

Once you have a container that can build your firmware on the server, the next step is to automate your code metric reporting. There is so much value in analyzing your source code for issues. It helps you track your progress, along with many issues that often aren’t discovered unless a manual code review is being done. 

For example, every team strives to follow a coding standard so that all the code looks the same. We create coding style guides and all kinds of other processes. However, how often do developers deviate from those styles? All the time! It’s too much work to review every line of code and make sure it adheres to the standard. That’s where automation comes in! 

You can set up your pipeline so that the software is analyzed. The analysis can vary greatly, but let me give you some ideas on what you can analyze:

The list can go on and on. Reporting on your code metrics can then be used to spot issues with development or the code. For example, I like to report Cyclomatic Complexity. It tells you how complex functions are and the likelihood of bugs existing in that function, and the chances of injecting bugs if you modify the function. 

I find that most teams ignore basic software metrics. Unfortunately, this leaves the team blind to potential issues and technical debt that they are accruing. If you build reporting into your pipeline early, it will give you the insights necessary to spot the issues early and fix them while the cost of change is still low.

Conclusions

CI/CD is a modern technique that should probably be adopted by nearly every embedded software team. The tools exist today to make adoption very affordable. In fact, it’s super easy to get started and doesn’t require a lot of time and money to get a basic pipeline in place. 

As we discussed, the best way to get started is to first get a container build system in place. You’ll be able to then set up a build job in your pipeline to verify that the code at least compiles successful. From there, analyzing your software for metrics, static analysis, and so forth is not much more work. 

From there, you’ll find that you already have a lot of visibility into your development processes that otherwise wasn’t there. The automation helps ensure you can continue to get the insights without much effort from the team. 

These two first tips can help you to form a baseline CI/CD process that provides a lot of value to your team and your customers and is scalable to a more-sophisticated form of automation. The trick is to get started first and see how quickly you get a return on your investment.