概述
持续集成 (Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。
1. 环境准备
本次试验是基于Centos 7.3, docker 17.03.2-ce环境下的。docker的安装这里就不赘述了，提供了官方链接吧: Get Docker CE for CentOS
1.1. docker启动gitlab
启动命令如下：
port，hostname, volume根据具体情况具体设置
1.2. docker启动gitlab-runner
启动命令如下：
volume根据具体情况具体设置
1.3. 用于集成部署的镜像制作
我们的集成和部署都需要放在一个容器里面进行，所以，需要制作一个镜像并安装一些必要的工具，用于集成和部署相关操作。目前我们的项目都是基于golang 1.9.2的，这里也就基于golang:1.9.2的镜像制定一个特定的镜像。
Dockerfile内容如下：
其中golint是用于golang代码风格检查的工具。docker是由于需要在容器里面使用宿主的docker命令，这里就需要安装一个docker的可执行文件，然后在启动容器的时候，将宿主的 /var/run/docker.sock 文件挂载到容器内的同样位置。expect是用于ssh自动登录远程服务器的工具，这里安装改工具是为了可以实现远程服务器端部署应用
另外，在安装golint的时候，是需要去golang.org下载源码的，由于墙的关系，go get命令是执行不了的。为了处理这个问题，首先通过其他渠道先下载好相关源码，放到指定的路径下，然后copy到镜像里，并执行安装即可。
下面有段脚本是用于生成镜像的：
生成镜像后，推送到镜像仓库，并在gitlab-runner的服务器上拉取该镜像
本次试验的gitlab和gitlab-runner是运行在同一服务器的docker下的。
2. runner注册及配置2.1 注册
环境准备好后，在服务器上执行以下命令，注册runner：
docker exec -it gitlab-runner gitlab-ci-multi-runner register
按照提示输入相关信息
成功后，可以看到gitlab->你的项目->settings -> CI/CD ->Runners settings 页面下面有以下内容：
2.2. 配置
注册成功之后，还需要在原有的配置上做一些特定的配置，如下：
这里先解释下gitlab-runner的流程吧，gitlab-runner在执行的时候，会根据上面的配置启动一个容器，即配置中的go-tools:1.9.2，b其中所有的启动参数都会在[runners.docker]节点下配置好，包括挂载啊，网络啊之类的。容器启动成功之后，会使用这个容器去gitlab上pull代码，然后根据自己定义的规则进行检验，全部检测成功之后便是部署了。
volumes: 是为了在容器中可以执行宿主机的docker命令。
extra_hosts: 给gitlab添加个host映射，映射到127.0.0.1
network_mode: 令容器的网络与宿主机一致，只有这样才能通过127.0.0.1访问到gitlab。
pull_policy: 当指定的镜像不存在的话gitlab命令，则通过docker pull拉取
3. 定义规则
在gitlab项目根目录创建.gitlab-ci.yml文件，填写runner规则，具体语法课参考官方文档：
3.1. go集成命令
下面介绍几个golang常见的集成命令1.包列表正如在官方文档中所描述的那样，go项目是包的集合。下面介绍的大多数工具都将使用这些包，因此我们需要的第一个命令是列出包的方法。我们可以用go list子命令来完成
go list ./…
请注意，如果我们要避免将我们的工具应用于外部资源，并将其限制在我们的代码中。 那么我们需要去除vendor 目录，命令如下：
go list ./… | grep -v /vendor/
2.单元测试这些是您可以在代码中运行的最常见的测试。每个.go文件需要一个能支持单元测试的_test.go文件。可以使用以下命令运行所有包的测试:
go test -short $(go list ./… | grep -v /vendor/)
3.数据竞争这通常是一个难以逃避解决的问题，go工具默认具有(但只能在linux / amd64、freebsd / amd64、darwin / amd64和windows / amd64上使用)
go test -race -short $(go list . /…| grep – v /vendor/)
4.代码覆盖这是评估代码的质量的必备工具，并能显示哪部分代码进行了单元测试，哪部分没有。要计算代码覆盖率，需要运行以下脚本：
如果我们想要获得HTML格式的覆盖率报告，我们需要添加以下命令：
go tool cover -html=cover/coverage.cov -o coverage.html
5.构建最后一旦代码经过了完全测试，我们要对代码进行编译，从而构建可以执行的二进制文件。
go build .
6.linter这是我们在代码中使用的第一个工具:linter。它的作用是检查代码风格/错误。这听起来像是一个可选的工具，或者至少是一个“不错”的工具，但它确实有助于在项目上保持一致的代码风格。linter并不是go本身的一部分，所以如果要使用，你需要手动安装它(之前的go-tools镜像我们已经安装过了)。使用方法相当简单:只需在代码包上运行它(也可以指向. go文件):
$ golint -set_exit_status $(go list ./… | grep -v /vendor/)
注意-set_exit_status选项。 默认情况下，golint仅输出样式问题，并带有返回值（带有0返回码），所以CI不认为是出错。 如果指定了-set_exit_status，则在遇到任何样式问题时，golint的返回码将不为0。
3.2. Makefile
如果我们不想在.gitlab-ci.yml文件中写的太复杂，那么我们可以把持续集成环境中使用的所有工具，全部打包在Makefile中，并用统一的方式调用它们。
这样的话，.gitlab-ci.yml文件就会更加简洁了。当然了，Makefile同样也可以调用*.sh脚本文件
3.3. 配置示例3.3.1. .gitlab-ci.yml
3.3.2. Makefile
3.3.3. coverage.sh
3.3.4. buildDockerImage.sh
3.3.5. automationDeployment.sh
3.3.6. Dockerfile
3.3.7. run_application.sh
4. 结果
原文链接：
本年度最后一场重要的大会， DevOps 国际峰会（DOIS）2018 · 深圳站，大会覆盖企业级DevOps，精益/敏捷，持续交付/自动化测试gitlab命令，微服务，技术运营，高可用架构等议题！
———END———
限 时 特 惠：本站每日持续更新海量各大内部创业教程，一年会员只需128元，全站资源免费下载点击查看详情
站 长 微 信：cscs1155
×