持续集成交付

设计起因

2022 年 3 月操作手模拟器联赛期间，我们使用人工将服务端软件上传服务器并启动的方式进行部署。这样的效率非常低，面对多台服务器时，逐个上传并重启简直是一种噩梦。

前期实现 Git+ 脚本

Shell 脚本

同月，我们使用 Shell 编写了第一版的自动部署脚本。它会每隔 1 分钟查询一次仓库是否有更新，如果有更新则自动拉取后重启服务器。这样的脚本极其简易，往往只有十几行。

Python 脚本

Shell 在易编码方面不及 Python，我们使用 Python 重新设计了一版自动部署脚本。该脚本的核心思路还是轮询 Git 仓库检查有无更新，但可以通过配置 yaml 文件更加方便地管理多个自动部署工程，易用性大大提高。以下是我们真实的部署配置 YAML 文件：

common:
  rootPath: /var/www
  logPath: /var/www/dev_log

application:
  center: # 内容略
  web:
    path: /var/www/SimulatorXWeb
    deploy:
      branch: master
    mode:
      default: "@build"
      build: npm run build
      install: npm install
  admin: # 内容略
  intro: # 内容略
  sub:
    path: /var/www/SimulatorXSubServerDeploy
    deploy:
      branch: master
    mode:
      default: "@restart"
      start: python3 ./run_sub.py start
      stop: python3 ./run_sub.py stop
      restart: "@stop; @start"

其中 application 中的各个部署格式大同小异。碍于篇幅原因，省略了部分内容并使用注释占位。这样的部署脚本进一步帮助我们减去了无意义的重复劳动，节约了宝贵的时间。

后期实现 TeamCity

上述脚本已经解决了自动部署的问题，但是还有改进的空间。按照上述的思路，需要将 SimulatorX 在本地编译打包后放到 Git 仓库中，再进行 push。但是这个过程实际上也是重复无意义的工作。如果开发者能在 push 源代码后交由系统自动编译打包和部署，那整套流程会更加优雅。因此，我们引入了现在很流行的持续集成(Continuous Integration)和持续交付(Continuous Delivery)，简称 CI/CD。

技术选型

市面上已经实现的 CI/CD 有很多，例如阿里云的云效 Codeup 流水线、基于 Java 的 Jenkins、非常轻量的 Drone CI 等等，我们选择了 Jetbrains 的 TeamCity。

TeamCity 官网 https://www.jetbrains.com/teamcity/

技术实现

我们使用了一台 Linux 服务器作为 TeamCity 的 Server，其上运行了 Agent，并在另一台 Windows 服务器上也运行了 Agent。至此，有 2 个 Agent 组成的 TeamCity 小型集群就完成了。

大部分工作都交由那台 Linux Agent 进行构建，但基于 Unity 的 SimulatorX 对于 Linux 电脑兼容很差，这部分内容交由 Windows 电脑构建。这台云电脑的性能很低，无缓存情况下构建 SimulatorX 往往需要 1 个多小时，在有缓存的情况下这个过程会缩短到可以接受的 7 分钟。后续如果我们有钱了会考虑换一台性能更好的服务器作为构建 SimulatorX 的 Agent。

至此，我们将模拟器组所有自动构建的工作都放在了 TeamCity 上完成。

实现效果

CI/CD 网站 https://ci.sim.scutbot.cn/

理论上各位无法查看这个站点的全部内容，因为需要用户名和密码。

这部分内容的开放存在非常大的风险，恕无法给各位浏览，请参考如下的截图。