基于GitLab CI搭建Golang自动构建环境 Golang发布遇到的问题
对于golang的发布，之前一直没有一套规范的发布流程，来看看之前发布流程：
方案一
开发者本地环境需要将环境变量文件改为正式环境配置
编译成可执行文件
发送给运维
（运维）将文件覆盖为线上
（运维）重启进程
（可谓“又臭又长”）
方案二
开发者讲代码commit到gitlab上交给运维同学
（运维）pull代码
（运维）编译成可执行文件
（运维）覆盖线上文件
（运维）重启进程
这种对于运维属于重度依赖，而运维同学又需要去关心代码的编译，增加了运维同学的工作了。
以上两种方案都是之前项目中发生过的，对于发版来说可谓是一种“噩梦”，易出错，流程长，运维要是不在根本无法操作。
解决方案为了解决上面提到的两种发布问题，目前我们做了如下的设计方案：
开发者提交代码到GitLab服务器
添加一个Tag触发构建（.gitlab-ci.yml+makefile）
将构建后的文件打包添加上版本号（1.0.0+）后推送到版本服务器
在Jenkins选择对应的版本号发布到指定Web Server上
发布时，开发只需要编写“.gitlab-ci.yml”以及makefile对项目进行构建，而运维只需要配置jenkins，将文件发布到Web Server上即可，完成了开发和运维的解耦。
什么是GitLab-CIGitLab CI 是 GitLab Continuous Integration （Gitlab 持续集成）的简称。从 GitLab 的 8.0 版本开始，GitLab 就全面集成了 Gitlab-CI,并且对所有项目默认开启。只要在项目仓库的根目录添加 .gitlab-ci.yml 文件，并且配置了 Runner（运行器），那么每此添加新的tag都会触发 CI pipeline。
一些概念在介绍 GitLab CI 之前，我们先看看一些持续集成相关的概念。
一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。 任何提交或者 Merge Request 的合并都可以触发 Pipeline，如下图所示：
+------------------+ +----------------+| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+ Stages
Stages 表示构建阶段，说白了就是上面提到的流程。 我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：
所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败
因此，Stages 和 Pipeline 的关系就是：
+--------------------------------------------------------+| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+ Jobs
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。 我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
相同 Stage 中的 Jobs 会并行执行
相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败