The code developed by the autonomous driving engineer needs to go through a series of development-integration-test-deployment processes from the beginning of development to the real deployment to the domain controller.
What happens if this process is deployed manually?
1. Slow delivery
Manual tasks are tedious and frustrating for the people who do them. These tasks slow down the delivery process and ultimately hinder innovation. If a competitor uses automation and you don't, then the competitor wins. Code waiting to be deployed is not profitable.
2. Lack of visibility
"Where did the error occur? What caused it? What was deployed in each environment? Can we roll back the program?". The process lacks monitoring, and it is difficult to debug program errors.
3. Errors and user dissatisfaction
No automation means users will make mistakes. Every manual task opens the door for errors. These errors occur frequently and are difficult to resolve. Also, since large amounts of code are not merged very often, bugs are found at the end of long development cycles that can be more challenging to fix, or have impacts on other parts of the codebase that are difficult to troubleshoot. Mistakes create tension between individuals and departments involved in the software delivery process. Ops blames developers for bad code. Developers get frustrated with all the manual tasks and blame QA for failing to catch bugs. When customer service agents have to resolve an end user grievance, they blame everyone involved in the process. Ultimately, the organization lacks collaboration and work camaraderie.
so.
In order to help projects iterate faster, continuous integration (CI) and continuous delivery/deployment (CD) have been widely used. In this article, I will introduce how to use the GitLab CI/CD tool to automate the packaging and deployment of projects.
In software engineering, CI/CD or CICD usually refers to the combined practice of Continuous Integration and Continuous Delivery or Continuous Deploy. CI/CD bridges the gap between development and operations teams by implementing automation in the building, testing, and deployment of applications.
continuous integration
Continuous Integration, in daily application development, we often let multiple developers develop different functional modules at the same time, but this will make the merging of branch source codes cumbersome and time-consuming. This is because commits from different developers may conflict. The purpose of continuous integration is to help developers merge code changes into the main branch more frequently. Once the developer's forked code is merged, the system validates the changes by automatically building the application and running different levels of automated tests (unit and integration tests) to ensure that the changes have not introduced new issues into the application.
continuous delivery
Continuous Delivery, after completing the automated process of building in continuous integration and unit testing and integration testing, continuous delivery can automatically release the verified code to the repository (such as GitLab). At this point, the operation and maintenance team can easily and quickly deploy the application to the online environment.
continuous deployment
Continuous Deploy, continuous deployment is the final stage, it can automatically publish the application to the online environment, and record the online record, which is convenient for version retrospection.
CI/CD automates the build, test and deployment pipeline. It has the following advantages:
1. The merger of smaller codes and fast function iterations;
2. Every build, test, and deployment is recorded, which can shorten the time to solve problems;
3. Each code change requires unit testing and integration testing to reduce application problems;
4. By cooperating with source code management platforms such as GitHub or GitLab, the application is easy to maintain and update.
Introduction to CI/CD tools
With the rise of DevOps in recent years, there has been a strong demand for CI/CD tools. Currently, the most popular CI/CD tools in the industry are Jenkins and GitLab CI/CD. In addition, GitHub also launched GitHub Actions in October 2018 to support CI/CD. All three can automate the application from source code to launch, but each has its own focus.
GitLab is developed by GitLab Inc, a fully integrated software development platform based on Git. Its community edition is free and provides features such as Git repository management, issue tracking, code review, and CI/CD. These functions basically wipe out all the operations involved in the development cycle of an application. In fact, GitHub also has these functions. The only disadvantage may be that it does not support privatized deployment. After all, the source code of projects in an enterprise is the most important asset, and it is taboo to put it on the public network. So this article mainly focuses on GitLab CI/CD to introduce its principles and practical applications.
principle
When it comes to GitLab CI/CD, it is inevitable to talk about the GitLab Runner project, which is an open source project used to execute tasks and transmit the execution results back to GitLab. Runner can be installed on a physical machine, in a virtual machine, or through Docker (recommended). It runs as a daemon/service.
How does the Runner interact with GitLab? We need to register and initialize the Runner. The required information is the link (mark 3) and token (mark 4) in the figure below, and select an executor to execute the .gitlab-ci.yml file commands in (docker is recommended to ensure a clean and lightweight system environment).
The principle of GitLab CI/CD is that the GitLab Runner service starts an executor to run the script commands in each stage in .gitlab-ci.yml, and returns the running results to GitLab.
configuration
To use the functions of GitLab CI/CD, in addition to setting up the running environment GitLab Runner, you also need to tell the executor how to execute. This involves the configuration of .gitlab-ci.yml. Just put the file in the root directory of the warehouse, and GitLab CI/CD will automatically parse the file. For details on the configuration of the .gitlab-ci.yml file, please refer to the official documentation.
Show results
After configuring .gitlab-ci.yml, submit it to the GitLab warehouse. Whenever the code is updated, a new version of the pipeline task will be generated in CI/CD -> Pipelines, and each stage will be triggered in turn in the Stages column. The script to go through the process.
A sample is shown in the figure below:
