概念
1.持续集成（Continuous Integration，简称CI）
持续集成 (CI) 是一种 DevOps 做法，旨在帮助开发团队更高效地工作和更可靠地交付软件。 使用 CI，每次合并更改时，CI 服务器都会自动构建和测试您的代码，为您的工作提供快速反馈。 这种快速可靠的反馈周期可以帮助您更频繁地发布更改，同时减少进入生产的 bug 数量。
2.持续部署（Continuous Deployment，简称CD）
对于自动执行构建、测试和部署步骤的 DevOps 做法，持续部署可以将其逻辑发挥到极致。 当代码更改成功通过管道的每个阶段时，更改将自动部署到生产中，无需任何手动干预。 采用持续部署意味着您可以在不影响产品质量的情况下，尽快向用户提供新功能。
3.持续交付（Continuous Delivery，简称CD）
是一种软件工程实践，通过自动化构建、测试和部署流程，使软件保持随时可发布状态，核心目标是降低开发成本与风险并加速交付效率。
持续交付和持续部署之间的区别在于发布到生产的最后阶段。采用持续交付，将构建工件发布到生产时需要手动输入。 发布流程通常完全自动化，但必须有人决定是否以及何时发布具体版本。 采用持续部署，每次完成流程的先前阶段时，构建都会自动发布到生产中。
环境
系统环境：麒麟V10
部署服务：Jenkins 2.528.1和Gitlab
配置方法.
1.在Jenkins里为执行任务的账号创建Token，Gitlab访问jJob需要有访问权限
2.查看Job路径：http://192.168.1.32:8081/job/test-project/api/json
- 192.168.1.32:8081是Jenkins地址
- test-project是项文件夹名称
- 截图内url信息就是Jobbers路径，后面加build就是触发构建任务，请求一次就会触发一次构建任务，比如：http://192.168.1.32:8081/job/test-project/job/test-pipline-job/build，后面Gitlab里面就是请求这个地址触发构建任务
3.登录Gitlib，进入项目，点击Settings->Webhooks->Add new webhook增加webhook配置
4.配置webhook - URL填写job路径，在多次实践后使用"http://Jenkins用户名:Token@Jenkins地址/job/项文件夹名称/job/任务名称/build"格式可以正常访问到Jenkins。Gitlab使用其它方式请求会一直报403，这个和Jenkins版本有关，如果你安装的是新版Jenkins，直接用这种方式就行了
- Tirgger选择Push events
- 由于是内网环境，去掉SSL verification配置
- 点击Test,选择Push events触发一次任务，测试是否成功
- 最后点击Add webhook完成添加
测试效果
1.向gitlab提交代码
2.查看Jenkins是否自动构建任务
文档完善中