Development team : Complete software development in the development environment, unit test, pass the test, and submit to the code version management library.
Operation and maintenance team : Deploy the application to the test environment for the QA team to test, and deploy the production environment after the test passes.
QA team : test, and notify the deployer to release to the production environment after the test passes.

question

Failure to find errors in time : Many errors may exist in the early stages of the project, and the problems are not discovered until the final integration.
Human error occurs : Critical activities in product and service delivery are all manual.
Inefficient team work : You need to wait for others' work to be completed before you can do your own work.
Development, operation and maintenance confrontation: developers want to update quickly, and operation and maintenance personnel pursue stability, and each targets different directions.

After the above problems we need to make changes, how to change?

1.2 Continuous Integration and Continuous Delivery

The continuous approach to software development is based on automating the execution of scripts to minimize the chances of introducing errors while developing applications. They go from developing new code to deploying it with little to no human intervention.

It involves continually building, testing, and deploying code changes in each small iteration, reducing the chances of developing new code based on buggy or failing previous versions.

There are three main approaches to this approach, each of which will be applied depending on what works best for your strategy.

Continuous Integration (CI)

The practice of continuously merging all the code that developers are writing. Merges and code commits are often done multiple times a day, with builds and automated testing from the repository or production to ensure there are no integration issues and to catch any early.

When developers submit codes, they generally test and verify locally first. As long as developers submit codes to the version control system, a submission pipeline will be triggered to verify the submission.

Continuous Delivery (CD)

Continuous delivery is a step beyond continuous integration. Not only will every code change pushed to the codebase be built and tested, but, as an additional step, it can be deployed continuously even if the deployment is triggered manually . This approach ensures that code is checked automatically, but requires human intervention to strategically manually trigger the deployment of changes.

Continuous Deployment (CD)

Software can often be released to production at any time by automatically pushing changes to the release system. Continuous deployment goes a step further and automatically pushes changes to production. Similar to continuous delivery, continuous deployment is another step beyond continuous integration. The difference is that instead of deploying it manually, you can set it to deploy automatically . Deploying your application requires no human intervention at all.

1.3 The value of CI/CD

Feedback early and find bugs early.
Reduce integration problems, solve problems every time they are found, and avoid problem accumulation.
Every change is successfully released, reducing the risk of releases.
Deliver value more frequently, customer feedback.

1.4 Recommend common CI/CD tools

Jenkins

Professional CI tool, scalable automation server, simple installation and configuration, rich plug-in library, distributed architecture design, support for all platforms, and visual management page.

GitLab

End-to-end DevOps tools, common functions: code review, issue tracking, dynamic subscription, easy to expand, project wiki, multi-role project management, project code online compilation preview, CI tool integration.

Submit and merge code integration: operate through git push or operate on the GitLab Web page.
Publish the application to the server: Obtain the application in the product library, and then use salt and ansible to publish and deploy it to the server.
Fully automated: submit code -> build deployment -> release

2. GitLab CI/CD Function Introduction

2.1 GitLab built-in continuous integration function

Continuous Integration (CI)

Integrate the code submitted by each developer in the team into the code repository.
Developers merge and pull new code in Merge or Pull requests.
A pipeline of builds, tests, and validation of new code is triggered before committing or merging changes into the code repository.
CI helps you find and reduce bugs early in the development cycle.

Continuous Delivery (CD)

A structured deployment pipeline ensures delivery of CI-validated code to your application.
CD can move verified code to your application faster.

Together, CI/CD can accelerate the speed at which teams can deliver results for customers and stakeholders. CI and CD must work together seamlessly to enable your teams to build quickly and efficiently, and are critical to ensuring fully optimized development practices.

2.2 Advantages of GitLab CI/CD

Open Source: CI/CD is part of the open source GitLab Community Edition and the proprietary GitLab Enterprise Edition.
Easy to learn: Has detailed getting started documentation.
Seamless integration: GitLab CI/CD is part of GitLab, supporting from planning to deployment with an excellent user experience.
Scalable: Tests can be run distributed on individual computers, and as many computers as needed can be added.
Faster results: Each build can be split into multiple jobs, which can be run in parallel on multiple machines.
Optimized for delivery: multiple stages, manual deployments, environments and variables.

2.3 Features of GitLab CI/CD

Multi-platform: Execute builds on Unix, Windows, macOS and any other platform that supports Go.
Multilingual: Build scripts are command line driven and can be used with Java, PHP, Ruby, C and any other language.
Stable builds: builds run on a separate machine from GitLab.
Parallel builds: GitLab CI/CD splits builds across multiple machines for fast execution.
Live Logging: A link in a merge request takes you to a dynamically updated log of the current build.
Flexible pipelines: you can define multiple parallel jobs per stage, and additional builds can be triggered.
Release pipeline: A .gitlab-ci.yml file containing your tests, steps through the process, enabling everyone to contribute changes and ensuring each branch gets the pipeline it needs.
Autoscaling: You can automatically scale your build machines to ensure your builds are processed immediately and with minimal cost.
Build Artifacts: You can upload binaries and other build artifacts to GitLab and browse and download them.
Docker Support: You can use custom Docker images, start services as part of testing, build new Docker images, and even run them on Kubernetes.
Container Registry: Built-in container registry for storing, sharing and using container images.
Protected Variables: Use per-environment protected variables to securely store and use secrets during deployment.
Environments: Define multiple environments.

2.4 GitLab CI/CD Architecture

GitLab CI/CD

Part of GitLab, GitLab is a web application with an API that stores its state in a database. In addition to all the features of GitLab, it also manages projects/builds and provides a nice user interface.

GitLab Runner

is an application that handles building. It can be deployed standalone and used with GitLab CI/CD via API.

.gitlab-ci.yml

Defines the pipeline job run, located in the root directory of the application project.

In order to run the tests, we will need at least a GitLab instance, a GitLab Runner, and a gitlab-ci file later.

2.5 How GitLab CI/CD works

Host the code to a Git repository.
Create a ci file in the project root directory .gitlab-ci.yml, specify the build, test and deployment scripts in the file.
GitLab will detect it and run the script using a tool called GitLab Runner.
Scripts are grouped into jobs , which together form a pipeline .

The pipeline status is also displayed by GitLab:

Finally, if anything goes wrong, all changes can be easily rolled back:

三、GitLabCI VS Jenkins

JenkinswebIt is a visual automation tool widely used in continuous integration . It jenkinscan well support project construction in various languages. It is also fully compatible antwith various third-party construction tools such as . Source code hosting websites, for example , are directly integrated, and there are many plug-ins. After so many years of technology accumulation, they are used by most domestic companies .mavengradlesvngitgithubbitbucketJenkins

gitlab-CIIt is gitlab8.0a continuous integration system that comes with it later. The central idea is that every time pushit arrives gitlab, it will trigger a script execution, and then the content of the script includes a series of custom content such as testing, compiling, and deploying.

gitlab-CIgitlab-runnerThe execution of the script needs to be executed by custom installation . pushAfter the code is detected, webhookthe code change will be triggered gitlab-CIand assigned to each Runnerto run the corresponding script script. Some of these scripts are used for testing projects, and some are used for deployment.

3.1 Comparison of differences

Configurability of branches

With GitLabCI, newly created branches can immediately use defined jobs in CI pipelines without any further configuration.
Jenkins 2 based on gitlab's multi-branch pipeline can be realized. Compared with configuration, gitlab is more convenient.

Scheduled builds

Sometimes it helps to trigger jobs or entire pipelines based on time. For example, regular nightly scheduled builds.

It works out of the box with Jenkins 2. The moment at which a job or pipeline should be executed can be defined in cron-style syntax.
GitLab CI does not have this functionality. However, there is a workaround to achieve this: use a cronjob on the same or another server to trigger jobs and pipelines via WebAPI.

Although this cannot be done with GitLab CI, in fact, if the pipeline is triggered when the code is submitted, there will be no difference when the build was last submitted, which will reduce the waste of timed build resources for uncommitted code.

Pull Request Support

If the repository manager and CI/CD platform are well integrated, you can see the current build status of the request. With this kind of functionality, you can avoid merging code into a master branch that doesn't work or doesn't build correctly.

Jenkins is not further integrated with the source code management system, requiring administrators to write their own code or plug-in implementation.
GitLab's tight integration with its CI platform makes it easy to see the running and completing pipeline for every open and closed pull request.

authority management

Permissions management inherited from the repository manager is useful for large groups of developers or organizations who don't want to set up per-user permissions for each service individually. Most of the time, the permissions are the same in both cases, so they should be configured in one place by default.

Due to the deep integration of GitLab and GitLabCI, permissions can be managed uniformly.
Since Jenkins 2 does not have a built-in repository manager, it cannot directly merge permissions between repository managers and CI/CD platforms.

repository interaction

GitLab CI is a built-in component of GitLab, the Git repository manager, and thus provides a nice interaction between the CI/CD process and repository functionality.
Both Jenkins 2 and the repository manager are loosely coupled, so it is very flexible when it comes to choosing a version control system. Furthermore, just like its predecessor, Jenkins 2 emphasizes support for plugins to further extend or improve the existing functionality of the software.

plugin management

Extending the native functionality of Jenkins is done through plugins. Plugins are expensive to maintain, secure, and upgrade.
GitLab is open, anyone can contribute changes directly to the codebase, and once merged, it will automatically test and maintain each change.

3.2 Advantages and Disadvantages

GitLabCI

Lightweight and does not require complicated means of installation.
The configuration is simple and gitlabcan be directly adapted.
The real-time build log is very clear, and UIthe interactive experience is very good
Use YAMLto configure, anyone can use it very conveniently.
Without a unified management interface, it is impossible to coordinate and manage all projects
The configuration depends on the code warehouse, and the degree of coupling is not Jenkinslow

Jenkins

The compilation service is separated from the code warehouse, and the coupling degree is low
There are many plug-ins and many languages are supported.
There is a unified webmanagement interface.
Plug-ins and their own installation are more complicated.
Large in size, not very suitable for small teams.

3.3 Practical application

GitLabCI helps DevOps personnel, for example, in agile development, development and operation and maintenance are the same person, the most convenient way of development. (small team)
JenkinsCI is suitable for multi-role teams, with clear responsibilities, separation of configuration and code, and rich plug-ins.

4. Install and deploy GitLab service

GitLab official installation method: GitLab download and install_GitLab latest Chinese free version download and install-jihu GitLab

4.1 rpm mode

Tsinghua source address: Index of /gitlab-ce/yum/el7/ | Tsinghua University Open Source Software Mirror Station | Tsinghua Open Source Mirror

# 下载安装包
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm

# 安装
yum install -y curl policycoreutils-python openssh-server perl
rpm -ivh gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm

# 编辑站点地址（服务器节点的 ip）
vim /etc/gitlab/gitlab.rb
external_url 'http://192.168.170.133' 

# 重载配置（过程会比较久，耐心等待）
gitlab-ctl reconfigure  

# GitLab 服务控制
gitlab-ctl start      # 启动服务   
gitlab-ctl status     # 查看状态
gitlab-ctl stop       # 停止服务

Note: The GitLab service installed in this way is a self-starting service.

4.2 Docker way

Refer to the official document: Extreme Fox GitLab Docker Image | Extreme Fox GitLab

4.3 Kubernetes Deployment

Refer to the official document: Install Jihu GitLab using Helm | Jihu GitLab

Next article: [CI/CD practice based on GitLab] 02, gitlab-runner practice_Stars.Sky's Blog-CSDN Blog

[CI/CD practice based on GitLab] 01. Basic concepts of GitLab CI/CD

1. Why do CI/CD?

1.1 Background - traditional application development and release model

question

1.2 Continuous Integration and Continuous Delivery

Continuous Integration (CI)

Continuous Delivery (CD)

Continuous Deployment (CD)

1.3 The value of CI/CD

1.4 Recommend common CI/CD tools

Jenkins

GitLab

2. GitLab CI/CD Function Introduction

2.1 GitLab built-in continuous integration function

Continuous Integration (CI)

Continuous Delivery (CD)

2.2 Advantages of GitLab CI/CD

2.3 Features of GitLab CI/CD

2.4 GitLab CI/CD Architecture

GitLab CI/CD

GitLab Runner

.gitlab-ci.yml

2.5 How GitLab CI/CD works

三、GitLabCI VS Jenkins

3.1 Comparison of differences

Configurability of branches

Scheduled builds

Pull Request Support

authority management

repository interaction

plugin management

3.2 Advantages and Disadvantages

GitLabCI

Jenkins

3.3 Practical application

4. Install and deploy GitLab service

4.1 rpm mode

4.2 Docker way

4.3 Kubernetes Deployment

Guess you like