Continuous Integration (CI) and Continuous Deployment (CD)

How To Set Up a Continuous Integration and Delivery (CI/CD) Pipeline

What is a CI/CD pipeline?

The primary goal of a CI/CD pipeline is to automate the software development lifecycle (SDLC).
The pipeline will cover many aspects of a software development process, from writing the code and running tests to delivery and deployment.
Simply stated, a CI/CD pipeline integrates automation and continuous monitoring into the development lifecycle.
This kind of pipeline, which encompasses all the stages of the software development life cycle and connects each stage, is collectively called a CI/CD pipeline.

This process will reduce manual tasks for the development team which in turn reduces the number of human errors while delivering fast results.

Stages in a CI/CD pipeline

A CI/CD pipeline can be divided into four main stages:

1. Source
2. Build
3. Test
4. Deployment

Each subsequent stage must be completed before continuing to the next stage. All the stages are continuously monitored for errors or any discrepancies, and feedback is provided to the delivery team.

Source stage

The CI/CD pipeline will get triggered by any change in the program or a preconfigured flag in the code repository (repo).
This stage focuses on source control, covering version control and tracking changes.

Common tool in the source stage : Git.

Build stage

This stage covers software builds.

Commin tool that support the build stage: Jenkins

Test stage

The test stage incorporates all the automated testing to validate the behavior of the software.

Deploy stage

After passing all the previous stages, the package is now ready to be deployed.
In this stage, the package is deployed to proper environments as first to a staging environment for further quality assurance (QA) and then to a production environment.

CI/CD pipeline examples

Traditional CI/CD pipeline

Cloud-based CI/CD pipeline

What is Continuous Integration?

Continuous Integration (CI) is a software development practice :

• Developers integrate code into a shared repository
• Each integration can then be verified by an automated build and automated tests.
  
  
  

Here is the big picture of the workflow: 

 The main steps are:

• We have a Simulink Project with source control integration configured to a GitLab repository
• In the Simulink Project, we have a test suite created using Simulink Test
• Every time we commit and push changes to a specific branch of the Git repository, the remote repository notifies a Jenkins server
• As soon as it gets notified, the Jenkins server pulls the commit, launches MATLAB, opens the Simulink Project and runs the Simulink Test test suite
• If the test passes, the Jenkins server creates a merge request in GitLab.
• If a test fails, the Simulink Test results are saved and a bug issue in GitLab is created.

Jenkins CI service

From GitLab, you can trigger a Jenkins build when

• you push code to a repository
• a merge request is created.

使用 Jenkins 實作 Pull Request 測試

先行條件

如前面所提到的在這篇文章提供的方法需要有以下條件：

• 用 GitHub 管理你的程式碼
• 有一個 Jenkins 平台
• Jenkins 能夠自公開網路中存取 (GitHub 要能連的到)

GitHub Access Token

為了讓 Jenkins 有權限能夠接收 GitHub 的 PullRequest 通知，需要產生一個 GitHub access token 給他使用。

設定 GitHub Webhooks

• 切到 GitHub repository的頁面
Setting -> Webhooks -> Add webhook
• 在 Payload URL 輸入 jenkins 的網址，如：
http://<your-jenkins-url>/github-webhook/

在 Jenkins 設定 GitHub Servers

之後在 Jenkins 的 Configuration 介面中的 GitHub -> GitHub Servers 增加一筆設定。

建立任務

• Jenkins -> New Item -> 選 Multibranch Pipeline 並為它命名
• 在 Configure -> Branch Sources 指定repository
• Build Configuration 需要輸入使用的 Jenkinsfile 路徑

設定完成後 Jenkins 就會檢查所有分支，如果有找到 Jenkinsfile 就會依照檔案設定來工作，如編譯測試版本或運行單元測試等。 之後repository的 Pull Request 有變動時就會觸發 Jenkins，運行結果再回傳到 GitHub 顯示在 PR 的下方

CI/CD as a service: 10 tools for continuous integration and delivery in the cloud

There are many continuous integration services and they all do much the same thing, at least in an abstract sense.
They begin with a list of the tasks like compiling or testing that must be accomplished before the world can appreciate the genius in your new software.
When you commit your lines of code, the tools start working through the checklist until they run into a roadblock. If there are no roadblocks, everyone is happy.

GitLab CI/CD

This company that wants to handle every step of the process between your fingers and running deployment.
GitLab’s build, test, and deployment mechanisms are likewise connected directly to its Git repositories so they can be triggered on commitment.
The build tasks can target any language but must be triggered by GitLab Runner, an autoscaling tool written in Go that’s ready for most platforms. This flexibility means you can trigger any random job on other machines.