Gitlab CICD 构建流程

比起君子讷于言而敏于行，我更喜欢君子善于言且敏于行。

目录

一、CICD是什么？

二、Jenkins & Gitlab

1. Jenkins

2. Gitlab

三、Gitlab CICD的原理

四、Gitlab Runner

五、.gitlab-ci.yaml语法

1. job    

2. before_script    

3. script

4. after_script      

5. stages          

6. .pre            

7. .post          

8. stage        

9. variables   变量

总结

---

一、CICD是什么？

传统应用发布：开发团队提交---运维人员部署---测试人员测试---通过后部署到生产环境

在此期间遇到了一些问题：错误发现不及时，人员等待效率较低，开发运维思想对立。所以有了CICD模式来解决问题

CI：持续集成。一天内多次提交和验证代码。可以尽快发现问题。

CD：连续交付。自动化测试。持续部署，自动将更改推送到生产环境中。

二、Jenkins & Gitlab

1. Jenkins

优点：可扩展自动化服务器，安装配置简单，插件库丰富，支持分布式架构，支持所有平台（所有的项目都能统一管理起来），可视化管理页面

2. Gitlab

优点：既是代码库又是CICD，完整的端到端的实现，多角色管理项目，代码在线预览，开源，易于学习（官方文档很详细），机器可以任意扩展，更快运展多个作业可以并行运行在多台机器上

三、Gitlab CICD的原理

•   将代码托管在gitlab上
•   在项目根目录创建.gitlab-ci.yaml，在文件中指定运行的每个步骤
•    提交代码时会检测是否有yaml文件，按照指定的runner去执行yaml

四、Gitlab Runner

• 由gitlab服务器+gitlab runner服务器一起组成的CICD的架构。
• gitlab runner 是一个独立的项目，和gitlab是分开的，进行独立部署。建议部署到不同服务器上。但是建议版本保持一致，防止出现版本差异化
• 支持多种系统，linux、mac、windows。
• docker、k8s部署都可以，docker版本最小为1.13.0以上
• 可以并行运行多个作业
• 运行环境：docker容器或ssh到服务器上都可以。支持bash、windows Powershell、windows Batch
• 自动重新加载配置文件，无需重启
• 易于安装

五、.gitlab-ci.yaml语法

1. job    

一条流水线（yaml文件）包含了至少一个job（作业），每个job至少要包含一个script。job名称是唯一的且不能使用关键字。

2. before_script    

 先运行此命令然后运行script。是全局的。

3. script

以上两个运行在同一个shell里，一个失败，作业就失败

4. after_script      

运行完script后运行此命令。是一个新的shell，如果它失败了，job的状态不会失败。是全局的

5. stages          

指定同一阶段的作业并指定顺序。就是pipeline的一个个小圈圈
eg: stages:
    - build
    - test
    - deploy

6. .pre            

整个管道的第一个运行阶段

7. .post          

整个管道的最后一个运行阶段
如果管道只有.pre  .post，则不会创建管道
中间才是我们可以控制的script stage等等

8. stage        

依赖于全局定义的stages并行的运行。每个job里面去指定。 
如过发现阶段并没有并行，那可能是两个阶段在同一个runner运行，需要修改runner每次运行的作业数量，默认为1，修改为10
vim /etc/gitlab-runner/config.toml   #更改后自动加载无需重启
concurrent = 10

9. variables   变量

---

总结

暂时先到这里叭~后续再补补