Introduction

In this article, we are going to look at how to implement the prevalent CI/CD (Continuous Integration / Continuous Delivery) practice on software developed with SCADE Suite.

We will start by exploring the concepts of CI/CD. We will then look at what software and services are used to set it up. Finally, we will showcase a concrete working example of CI/CD with SCADE, complete with a Git repository you can play with.

What is CI/CD?

Continuous Integration (CI) / Continuous Delivery or Deployment (CD) is a method to deliver software changes frequently and reliably in an iterative fashion.

High-level view of a CI/CD workflow for model-based embedded software

Continuous Integration

Continuous Integration was born from a simple observation: when collaborating on a complex piece of software, it is easier to review small, incremental changes often than it is to wait and check in large changes.

Since reviewing changes and integrating them is still a lot of work, the process relies on heavy automation to make things as smooth as possible.

When software developers collaborate around a Version Control system (such as Git), the Continuous Integration system will pick up any new changes, build the complete software and run automated tests on it, raising alerts in case of failures. The specifics of building and testing depend on the project’s tech stack.

Continuous Delivery

By design, Continuous Integration regularly produces a piece of working software. The next logical step is to do something with it! Enter Continuous Delivery.

Packaging a build and distributing it is a repetitive process that lends itself well to automation. Continuous Delivery heavily relies on scripted actions to accomplish this, freeing engineers to work on higher-level tasks.

When Continuous Integration successfully produces a build, Continuous Delivery picks it up and performs specialized tasks to package and distribute it. For instance, if the software is an online service, it may be deployed onto a server so that users can benefit from the changes. For an embedded software module, it may be uploaded onto a test bench for Hardware-in-the-loop testing.

Pipelines

A specific project’s CI/CD configuration is called a CI/CD pipeline. It is composed of large blocks (e.g. “build”), each containing inner steps (e.g. “compile this sub-system into a DLL and move on to the next step”).

At a high level, a CI/CD pipeline looks like a piece of the workflow diagram, unrolled into a straight sequence of automated actions:

A sample CI/CD pipeline for model-based embedded software

Pipelines are often triggered automatically by predefined events: a code check-in, a pull/merge request, or other changes in the Version Control system. Due to the extensive automation, this commit / build / test / deploy process becomes continuous – hence the “C”s in “CI/CD”.

Benefits

Thanks to a CI/CD approach:

• Teams have an incentive to focus on creating small, incremental changes, and be assured that the overall software continues working.
• Relying on extensive automated testing is encouraged. Adding tests with each new increment of the software, or when repairing regressions, ensures that the pipeline will be more effective at producing quality output.
• The CI system often produces working builds of the whole software, re-running all tests and ensuring issues are detected early.
• The CD system automates repetitive packaging and delivery tasks, freeing up the team to work on higher-level topics.

SCADE Suite and CI/CD

SCADE Suite is a model-based software development environment. While engineers work on models instead of writing code, the principles of software development still apply, including a CI/CD approach.

When engineers collaborate on a SCADE model to produce safe embedded software, they can use a Version Control system (such as Git) to track changes, just as they would if they were collaborating on manual code.

Typical lifecycle activities for a SCADE Suite model are:

• Check a model’s compliance with semantic rules
• Build a diff report for new changes
• Launch a model traceability coverage report
• Execute a functional test suite
• Acquire model coverage
• Generate code from the model
• Deliver application binaries downstream (e.g. onto a download repository, a test bench…)

Note that testing activities typically happen at model level, before generating the code and building a binary. This is reversed compared to traditional manual development, and possible because the SCADE code generator is qualified and guarantees that a correct model yields correct code.

All the above activities can be automated inside of a CI/CD pipeline. The preferred way to automate these tasks is through a Windows batch file that runs SCADE in command line mode with the proper arguments, displays the results and returns a success or error code.

Practical examples

Version Control services GitHub and GitLab support their own flavors of CI/CD. For self-hosted Version Control, dedicated open-source software such as Jenkins fills that role. Let’s look at those three in detail.

GitHub

GitHub provides an automation framework called GitHub Actions, which can support CI/CD pipelines.

GitHub relies on a Runner concept: a piece of software, running on a machine, which picks up CI/CD jobs as they are triggered. Runners may be hosted by GitHub (for a fee), or self-hosted by installing them on machines you own. Should you use self-hosted runners, you may configure them from your repository’s settings.

GitHub runners execute CI/CD pipelines called workflows. They are triggered by events and contain jobs, which are made of steps.

The whole CI/CD configuration is described in a YAML file, stored by convention inside the .github/workflows directory. The file’s structure is documented in more detail here.

GitLab

GitLab relies on a Runner concept (similar to GitHub’s), including the possibility to use GitLab-hosted runners (for a fee) or to register machines you own as runners. Should you use self-hosted runners, you may register them and later refer to them by name or tag when running jobs.

GitLab runners execute CI/CD pipelines. They are triggered by events and contain stages, which are made of jobs.

The whole CI/CD configuration is described in a YAML file, called by convention .gitlab-ci.yml, stored at the root of the repository. The file’s structure is documented in more detail here.

Jenkins

Jenkins is a self-hosted software that runs CI/CD jobs by itself, on a machine you own. It is possible to connect multiple instances of Jenkins for scalability (to run multiple CI/CD tasks simultaneously). Jenkins provides a web interface to configure and manage the service.

Jenkins agents execute CI/CD pipelines. They are triggered by triggers and contain stages, which are made of steps.

The whole CI/CD configuration is described in a text file, called by convention Jenkinsfile, stored at the root of the repository. The file’s structure is documented in more detail here.

Let’s do this!

In the Git repository below, you will find:

• The Cruise Control SCADE model (as seen in the software’s out-of-the-box examples)
• Pre-made batch scripts to launch various activities using SCADE in command line mode
• Ready-to-use CI/CD configurations for GitHub, GitLab and Jenkins

Repository link: GitHub link

The README.md file provides step-by-step instructions on how to configure each of these with your setup.

Are you ready to try this out? Then go clone the repo, upload it in your Version Control system of choice and play with it!

About the author