GitLab CI/CD工作流
来源：GitLab官方文档
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。
基本概念
▎持续集成（Continuous Integration ）
开发人员提交新代码或者修复补丁之后自动的进行构建、测试。持续集成是让产品可以快速迭代，同时还能保持高质量。它的核心措施是代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。持续集成过程中很重视自动化测试验证结果，对可能出现的一些问题进行预警，以保障最终合并的代码没有问题。
持续集成来源：mindtheproducthttps://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/
▎持续交付（Continuous Delivery )
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续「手动部署」到生产环境中。
持续交付来源：mindtheproduct
▎持续部署（Continuous Deployment )
持续部署则是在持续交付的基础上，把部署到生产环境的过程「自动化」，与持续交付的区别是产品部署自动化。
持续部署来源：mindtheproduct
GitLab实践
▎实现原理
- 在项目根目录配置.gitlab-ci.yml，GitLab会自动扫描到.gitlab-ci.yml文件的存在，并据此处理CI流程
- 每次push/merge会触发CI流程
- GitLab-CI提供了指定CI运行平台的机制：GitLab-Runner，通过注册Runner指定绑定到项目(URL+TOKEN)
▎GitLab作业流程
Step 1: 在dev分支根目录添加.gitlab-ci.yml文件
demo-job:
tags:
- d3
script:
- echo "hello gitlab-ci"
Step 2: 获取GitLab地址与Token
Step 3: 注册GitLab-Runner
Step 4: 当dev发生push或者merge时，.gitlab-ci.yml自动在runner中执行
▎入坑提示
a. GitLab-runner所在containner可能会找不到GitLab
fatal: unable to access 'http://2fdc651ae7f0/root/helloworld.git/': Could not resolve host: 2fdc651ae7f0在gitlab containner中查看/etc/hostname内容为：2fdc651ae7f0，也就是gitlab的主机名是2fdc651ae7f0（GitLab IP为172.17.0.2）需要在gitlab-runner container的/etc/hosts中添加一行
2fdc651ae7f0 172.17.0.2
在容器启动时添加
docker run --add-host=2fdc651ae7f0:172.17.0.2 -d --name gitlab-runner --restart always \ -v /Users/Shared/gitlab-runner/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latestb. runner注册时要指定tag, 在.gitlab-ci.yml 中要指定相应的tags，不然会找不到runner（报错是超时）
关于issue追踪和看板
GitLab提供了丰富的issue追踪功能，结合标签，看板可以容易的进行问题、任务管理。
可在路径Project -> Project information -> Labels下任意添加、配置需要的标签
应用开发的看板示例
一个典型的看板建立流程：
- 将issue定义为各类任务，模块
- 建立标签，并在看板中为标签建立列表
- 将issue在列表之间移动进行项目管理，协调沟通
