# introduction_gitlab_ci

**Repository Path**: xiaolixi/introduction_gitlab_ci

## Basic Information

- **Project Name**: introduction_gitlab_ci
- **Description**: No description available
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2024-10-02
- **Last Updated**: 2024-10-03

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# introduction_gitlab_ci 

https://blog.csdn.net/weixin_44749269/article/details/129321440


## 1. 简介`gitlab ci`

## 名词解释
### 持续集成（Continuous Integration）、持续交付（Continuous Delivery）、持续部署（Continuous Deployment）
我是没有看过理论上的CI/CD知识点，都是在网络上看看的。因此总结的或许不对。  
从下面这个图来看，持续交付包含了持续集成、持续部署包含了持续交付。   
![CI/CD](https://foruda.gitee.com/images/1727846435947081530/e3a3c2b4_5347690.png)

1. 持续集成（Continuous Integration）  
简单的讲就是程序员提交代码后会自动的进行编译、打包和测试      
2. 持续交付（Continuous Delivery）  
持续交付的目标是拥有一个可随时部署到生产环境的代码库，部署到生产环境往往是需要手动的。
3. 持续部署（Continuous Deployment）
对于一个成熟的 CI/CD 流程来说，最后的阶段是持续部署。   
作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。     

### 开发环境、测试环境、Staging环境、生成环境

1. Staging环境  
可以理解我准生成环境，做上线前的验证。  


## 2. [gitlab ci/cd官网文档](https://docs.gitlab.com/ee/topics/build_your_application.html)

![输入图片说明](image.png)

### 免费的[在线gitlab](https://gitlab.com/)
### 2.1 Get started with GitLab CI/CD
CI/CD is a continuous method of software development, where you continuously build, test, deploy, and monitor iterative code changes.   
This process is part of a larger workflow:   
![输入图片说明](https://docs.gitlab.com/ee/ci/img/get_started_cicd_v16_11.png)

#### Step 1: Create a `.gitlab-ci.yml` file

You can name this file anything you want, but `.gitlab-ci.yml` is the most common name, and the product documentation refers to it as the `.gitlab-ci.yml` file or the CI/CD configuration file.

#### Step 2: Find or create runners
Runners are the agents that run your jobs. These agents can run on physical machines or virtual instances. In your .gitlab-ci.yml file, you can specify a container image you want to use when running the job. The runner loads the image, clones your project, and runs the job either locally or in the container.


####  Step 3: Define your pipelines
![输入图片说明](Snipaste_2024-10-03_16-06-24.png)
####  Step 4: Use CI/CD variables as part of jobs
GitLab CI/CD variables are key-value pairs you use to store and pass configuration settings and sensitive information, like passwords or API keys, to jobs in a pipeline.
####  Step 5: Use CI/CD components
A CI/CD component is a reusable pipeline configuration unit. Use a CI/CD component to compose an entire pipeline configuration or a small part of a larger pipeline.




### pipelines
#### pipeline的介绍
- Pipelines are the top-level component of continuous integration, delivery, and deployment.  
- Pipelines comprise:   
  - Jobs, which define what to do. For example, jobs that compile or test code.   
  - Stages, which define when to run the jobs. For example, stages that run tests after stages that compile the code.   

1. If all jobs in a stage succeed, the pipeline moves on to the next stage.
2. If any job in a stage fails, the next stage is not (usually) executed and the pipeline ends early.
3. In general, pipelines are executed automatically and require no intervention once created. However, there are also times when you can manually interact with a pipeline.

#### pipeline的类型
Pipelines can be configured in many different ways:   
- Basic pipelines run everything in each stage concurrently, followed by the next stage.
- Pipelines that use the needs keyword run based on dependencies between jobs and can run more quickly than basic pipelines.
- Merge request pipelines run for merge requests only (rather than for every commit).
- Merged results pipelines are merge request pipelines that act as though the changes from the source branch have already been merged into the target branch.
- Merge trains use merged results pipelines to queue merges one after the other.
- Parent-child pipelines break down complex pipelines into one parent pipeline that can trigger multiple child sub-pipelines, which all run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos.
- Multi-project pipelines combine pipelines for different projects together.