前言
现代软件工程越来越复杂，而开发效率随着软件复杂度增加呈指数型下降。为在提高开发效率的同时也能保证质量，越来越多团队开始践行敏捷开发方法。
持续集成是敏捷开发的重要实践之一。它倡导团队通过自动化构建工具频繁地验证软件可用性，从而尽早发现集成错误并集中精力改善软件质量。
可以看到这个 Web 应用项目的结构非常简单。然而随着项目规模的逐步增大、参与人员的不断增加，构建、测试、发布过程变得越来越复杂。单靠开发人员在本地机器上人工手动进行集成变得愈发困难，既消耗时间也分散精力，团队的协作效率越来越低。而借助持续集成，则可以自动化构建、测试、发布的过程，将开发人员从重复的人力劳动中解放出来，更专注于开发且更快地发现和解决问题。
在继续下面的步骤前，请确保在 CODING 项目中开启了“持续集成”和“制品库”功能。
创建制品库
设置制品库凭证
K8s 集群从制品库拖取镜像需要访问凭证，这里使用 CODING 制品库自动生成的访问令牌。这里要注意的是，访问令牌生成后需要立即复制下来，否则关闭访问令牌的窗口后将无法再次查看。
生成访问令牌后会得到一条 Docker 仓库的登录命令，例如：
docker login -u release-1587202817568 -p 2f4f129287b3319c52f760635fxxxxxxxxxxxxxx coding-public-docker.pkg.coding.net
其中提供了 3 部分信息：
仓库域名：coding-public-docker.pkg.coding.net
用户名：release-1587202817568
密码：2f4f129287b3319c52f760635fxxxxxxxxxxxxxx
在 TKE 的集群中创建 Secret，输入上面获得的仓库访问凭证。
设置集群凭据
要通过 CODING 持续集成触发 K8s 集群部署过程需要在 CODING 中录入集群凭据，以便在 CODING 持续集成中使用 kubectl 命令实现 K8s 集群控制。
在 TKE 控制台中找到“集群APIServer信息”，复制其中的“Kubeconfig”。
创建构建计划
这里选择预置内容较少的“自定义构建过程”模板，之后在这个模板的基础做详细的配置。
配置构建流程
这里把 Ruby + Sinatra 应用持续集成过程分成 6 个阶段：
开始
检出
运行单元测试
构建 Docker 镜像
推送到制品库
部署到 K8s 集群
从模板创建的构建计划已经包含了“开始”和“检出” 2 个阶段。其中“检出”阶段可以不用修改直接使用。
CODING_DOCKER_REG_HOST：制品库主机，用于登录制品库。
DOCKER_IMAGE_NAME：Docker 镜像名称，用于构建和推送镜像。
TKE_CLUSTER_CREDENTIAL_ID：TKE 集群凭据 ID。
上述环境变量的值是根据上面创建的 Docker 制品库来设置的，可以在制品库指引中查看相关信息。注意，页面上的 Docker 镜像名称不完整，需要把 替换成实际的值，如果值为 ruby-sinatra，则镜像名称就是 coding-public-docker.pkg.coding.net/ruby-sinatra/release/ruby-sinatra。
“运行单元测试”阶段
在这个阶段里，将运行代码中已经写好的单元测试代码。整个过程会在 Docker 容器中进行，这样可以节省准备运行环境的时间，也可以与后面构建 Docker 镜像时使用的基础环境保持一致。
首先给对模板创建出来的“3-1 自定义构建过程”删除掉，然后添加名为“运行单元测试”的阶段，之后在这个阶段里添加“执行 Pipeline 脚本”的步骤，并在右边的输入框中输入运行单元测试的脚本。这里使用 Jenkins Pipeline 来调用 docker run 命令来运行单元测试。
docker.image(‘ruby:2.6’).withRun(‘-v $(pwd):/app -w /app’) { c ->
sh ‘bundle install’
sh ‘rake test’
}
其中的镜像名称使用了 1-1 阶段设置的环境变量。而标签则使用内置的环境变量 GIT_BUILD_REF，其值对应“构建对应的 Git 修订版本 ”。内置环境变量的具体说明请见 https://help.coding.net/docs/devops/ci/env.html
“推送到制品库”阶段
这是构建过程的最后一个阶段，和上一个阶段类似，添加名为“推送到制品库”的阶段，在阶段里添加“执行 Pipeline 脚本”的步骤，在脚本输入框中输入脚本。这里使用了 Jenkins Pipeline 来推送镜像到制品库。
docker.withRegistry(“https://${env.CODING_DOCKER_REG_HOST}”, “${env.CODING_ARTIFACTS_CREDENTIALS_ID}”) {
docker.image(“${env.DOCKER_IMAGE_NAME}:${env.GIT_BUILD_REF}”).push()
}
脚本中用到了在 1-1 阶段定义的环境变量：TKE_CLUSTER_CREDENTIAL_ID。
配置完成后别忘了保存！
此时，已经可以通过“立即构建”来手动触发持续集成过程了。
整个流程运行完成后，可以查看每一步的运行日志。
配置触发规则
CODING 持续集成提供了多种触发规则，如果默认配置无法满足需求，还可自行配置所需的规则。
查看部署结果
构建计划运行成功后，可以到 TKE 控制台查看 Deployment 的部署状态。
相关资源：旅行家航旅行程信息打印软件-旅游工具类资源-CSDN文库
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！