{"id":181912,"date":"2024-02-28T09:56:09","date_gmt":"2024-02-28T09:56:09","guid":{"rendered":"\/knowledge\/forums\/topic\/setting-up-a-continuous-integration-continuous-delivery-ci-cd-workflow-with-scade\/"},"modified":"2026-02-17T10:04:25","modified_gmt":"2026-02-17T10:04:25","slug":"setting-up-a-continuous-integration-continuous-delivery-ci-cd-workflow-with-scade","status":"publish","type":"topic","link":"https:\/\/innovationspace.ansys.com\/knowledge\/forums\/topic\/setting-up-a-continuous-integration-continuous-delivery-ci-cd-workflow-with-scade\/","title":{"rendered":"Setting up a Continuous Integration \/ Continuous Delivery (CI\/CD) workflow with SCADE"},"content":{"rendered":"

\n
\n <\/em>\n<\/p>\n

Continuous Integration \/ Continuous Delivery, or CI\/CD<\/a> for short, is a prevalent practice in collaborative software development. It allows teams to iteratively build complex software while keeping confidence levels high.<\/p>\n

In this article, we are going to look at how to implement it 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.<\/p>\n

What is CI\/CD?<\/h3>\n

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

\n
\n High-level view of a CI\/CD workflow for model-based embedded software<\/em><\/em>\n<\/p>\n

Continuous Integration<\/h4>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Continuous Delivery<\/h4>\n

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

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.<\/p>\n

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.<\/p>\n

Pipelines<\/h4>\n

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”).<\/p>\n

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

\n
\n A sample CI\/CD pipeline for model-based embedded software<\/em><\/em>\n<\/p>\n

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”.<\/p>\n

Benefits<\/h4>\n

Thanks to a CI\/CD approach:<\/p>\n