一、前置准备
·git
·nodejs
·yarn
·docker（仅本地构建与运行此应用需要）
·CODING 项目
·Docker 制品仓库，权限需设置为公开，制品仓库命名为 build
二、初始化
在创建代码仓库时选择导入外部仓库，粘贴示例仓库地址。
导入成功后，将代码拉取至本地中。
接下来可以运行 yarn install 命令并在本地安装依赖。
安装完成后运行 ./build.sh –local 命令进行本地构建。应用开发完成后还需要进行容器化，以方便应用传播与测试。每次开发后都会生成一个新的制品，若要手动重复打包再上传至制品仓库，此过程未免过于繁琐。借助持续集成工具，能够在每次开发后自动触发构建并上传至制品仓库，解放生产力。并且在构建的过程中还能够配置通知机制，及时获得构建反馈。
三、创建构建计划
进入任一项目后，单击左侧菜单栏的持续集成，新建构建计划时选择自定义过程模板。
跳转至配置详情后参考以下 Jenkinsfile 修改构建过程。
Jenkinsfile：
pipeline { agent any stages { stage('检出') { steps { checkout([$class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[ url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID ]]]) } } stage('构建') { steps { echo '显示环境变量' sh 'printenv' echo '构建中…' sh 'docker version' sh './build.sh' echo '构建完成.' } } stage('推送到 CODING Docker 制品库') { steps { script { docker.withRegistry( "${CCI_CURRENT_WEB_PROTOCOL}://${env.CODING_DOCKER_REG_HOST}", "${env.CODING_ARTIFACTS_CREDENTIALS_ID}" ) { docker.image("${env.CODING_DOCKER_IMAGE_NAME}:${env.GIT_COMMIT}").push() } } } } } environment { CODING_DOCKER_REG_HOST = "${env.CCI_CURRENT_TEAM}-docker.pkg.${env.CCI_CURRENT_DOMAIN}" CODING_DOCKER_IMAGE_NAME = "${env.PROJECT_NAME.toLowerCase()}/${env.DOCKER_REPO_NAME}/${env.DOCKER_IMAGE_NAME}" }}
此流水线脚本大致分为三个阶段，检出阶段为拉取代码，构建阶段为运行构建脚本，推送阶段为把 docker 制品推送到制品库。构建阶段主要运行脚这篇件 build.sh 主要内如下：
#!/bin/bash docker build -t compiler -f Dockerfile.compile . if [ "$1" = "–local" ]then docker build -t logo-reg .else docker build -f $DOCKERFILE_PATH -t $CODING_DOCKER_IMAGE_NAME:$GIT_COMMIT $DOCKER_BUILD_CONTEXTfi
此脚本的设计思路为分阶段构建方案。以 Dockerfile.compile 作为构建基础镜像的构建文件、Dockerfile 作为实际运行镜像的构建文件。使用这种方法可以使得实际运行的镜像不包含构建应用所需要的环境，大大减少镜像体积，构建后的镜像仅为 149 Mb。此外，此脚本还可以通过 –push 参数来灵活的区分云上构建环境与本地构建环境。
四、配置触发规则
持续集成支持多种触发方式，例如代码源触发、定时触发、API 触发及手动触发。其中代码源触发又可配置为推送到指定分支或标签触发，触发方式多样，可满足绝大部分场景需要。
如前言中所说，我们希望把更多的精力放在代码开发上，尽量减少构建所带来的干扰。因此可以设置触发规则，例如通过配置如下正则表达式，当分支名满足规则后即可自动触发构建。
^refs/(heads/(release|release-.*|build-.*|feat-.*|fix-.*|test-.*|mr/.*))
五、设置变量与缓存
持续集成过程中，我们总会将一些配置（例如：账号密码/版本号等）信息以环境变量的形式注入到构建过程中。
所涉及的环境变量如下：
| 变量名 | 默认值 |
| DOCKER_IMAGE_NAME | logo-reg |
| DOCKER_BUILD_CONTEXT | . |
| DOCKERFILE_PATH | Dockerfile |
| DOCKER_IMAGE_VERSION | ${GIT_LOCAL_BRANCH:-branch}-${GIT_COMMIT} |
| DOCKER_REPO_NAME | build |
六、执行构建
触发持续集成后，你可以在构建过程中看到各步骤的运行情况。
七、下载制品
构建完成后，可以看到在 build 制品仓库中已有新的制品，可以根据操作指引拉取至本地中。
八、运行应用
使用以下命令，运行已拉取的制品，即可开始通过机器学习以辨别 CODING、GitHub、GitLab Logo。
# 将命令中的仓库地址替换为自己制品仓库的地址。 docker run -p 8080:80 StrayBirds-docker.pkg.coding.net/demo/build/logo-reg:340275df1ecf1b2e7800a237ebceb10ceee7161c
浏览器打开 http://127.0.0.1:8080，等待数分钟后，右下角训练损失几乎将为 0 即为训练完毕（若不为 0 ，说明训练过程收到不可逆干扰，请刷新页面即可重新训练）。上传任一 CODING、GitHub、GibLab 的图标文件，此应用可准确的预测出图片属于哪个 logo。
预测 CODING logo：
预测 GitLab logo：
可以看出，此应用具有相当高的准确率！
九、总结
这篇通过一个基于 Tensorflow.js 开发的 AI 应用项目讲解了如何使用持续集成与制品仓库。借用 CODING DevOps 平台的这些功能， 我们解放本地算力，省去了人为的不必要劳动， 提高了生产力。
除此之外，持续集成可以构建任何应用（无论是终端、后端、甚至机器学习应用）。部署与构建不再是编程中的烦恼，专注于代码，专注于业务，繁琐之事皆可放行交由平台。