引言
- 最近在搞基于GitLab的自动化部署的相关实践，经过几天的摸索，终于有些门道了。
- 相比于Github的Actions，GitLab的CI/CD功能感觉更加灵活一些，同时也更加强大，这也就意味着门槛变高了。
- 之前搞过基于Github Actions的自动化部署发版到pypi，相比于GitLab CI，Github的Actions的确省去很多麻烦的事情，大大减少人为出错的概率。
- 关于Github Actions的用法可以去参考之前写过的博客：setup.py简单编写生成whl并Github Actions自动部署
GitLab CI/CD组成部分介绍
- 图来源：Gitlab-CI持续集成之Runner配置和CI脚本
- 这里截取上述链接中关于CI和Runner的关系说法，讲得比较清楚：
安装gitlab-ci-multi-runner服务器，相当于一个劳务公司的创办，它管理Runner工人，外包各种项目Project。
注册的目的是把项目和Runner连接起来，因为部分项目的Runner可能需要定制。
Runner好比是一个工人，在劳务中心（gitlab-ci-multi-runner）登记合同，供职于我们的Project（但是当他比较闲的时候，也可以去其他公司兼职）。
但是对应的RunnerService相当于Runner工人的管理层，一个管理层可以管理一个甚至多个工人。
劳务公司默认有一个公用的管理层，服务名就是上面所说的gitlab-runner，如果我们不指定管理层，那么劳务公司所有工人都被gitlab-runner管理运行。这个管理人员比较弱，一次只能管理一个项目，其他项目会等待。
搭建环境介绍
- 由于gitlab是一个开源的项目可以用于本地部署，而github则不是开源的。
- 因此，公司中的版本控制系统大都是基于gitlab项目自行搭建的。
- 本次实践是由于公司某些业务需求涉及到自动化部署，也有了这次实践。在这里，简单地做一个记录。
- gitlab服务器：公司内部搭建
- 运行runner服务器：自己日常使用的服务器，操作系统是CentOS 7
具体搭建步骤说明
- 这一部分主要是参见搭建一个自己的 Gitlab CI Runner，
- 我这里文章只是一个抛砖引玉的过程，同时我这里也就不造轮子了，小伙伴移步这个链接去详细部署吧!
- 部署有啥具体问题，欢迎在评论区留言！