水杉在极狐 GitLab 的 DevOps 实践

作者：华东师范大学数据学院 陈烨

如果看图文不过瘾，可以观看视频版

​

背景

项目

我是来自于华东师范大学数据学院的，我们学院一直非常重视计算机和教育之间相结合，水杉就是我们诸多探索的其中之一。跟很多软件的落地一样，我们水杉也是经历过了从几个人的小规模开发到目前的几十个人开发团队这样一个过程。虽然学生们基本都没有相关工程经验和工作经历，但是我们适应的很快。互相之间非常融洽，像什么老生常谈的开发和运维上的文化矛盾，我们也是不会出现的。人数上不会很多，符合中小团队的规模。所有小规模团队所经历的一些痛点我们都碰到，比如需求的管理、开发协作、应用的部署等等。

在项目开发伊始，我们就意识到了云原生的重要性。

云原生

可以说水杉一路走来，都努力朝着云原生的这四个方向去贴近，在项目实现过程中，就可以发现这四个要素之间是相辅相成的

• 现在的水杉已经将应用容器化，部署到集群或者单机服务器上

• 这就需要将模块和模块之间充分解耦，形成微服务的模式

• 随着服务的增多，手动管理就变得困难，这就需要持续交付的自动化流程

• 同样这也需要 DevOps 的有效管理。

GitLab

那么尤其在这个 DevOps 之路的选择上，我们是非常慎重的，我们做了很多的调研，最后才选择了 GitLab ，因为它不仅是一个代码托管仓库，更是 DevOps 集成度非常高的一个统一管理平台，我们可以不必为了实现 DevOps 而去寻找很多不同的工具。那么非常非常荣幸，在近期，极狐跟我们学院达成了一些战略合作，得以使我们从这个 GitLab 的自托管版本能够迁移到他们的 SaaS 版本，这让我们节省了很多维护的精力。

实践

项目管理

这里我就举个简单的例子，项目经理说这两周要美化一下前端，然后前后端一起新增一个功能。假设没有合理的计划管理，大家都只管提交代码，那么从项目经理的角度来看，他完全不清楚开发的进度如何。他可能需要一个个打开代码仓库去看代码提交记录，或者需要拿个共享文档画张进度表。那么我们就需要一种高效的计划管理。

接下来就是我们在 GitLab 上管理这种杂乱信息的方式。

• 里程碑：代表一段时间内需要达成的小目标，和敏捷计划的 Sprint 相对应，可以收集议题和合并请求，可以为史诗定义细节。

• 史诗：往往计划了类似整个网站、整个模块这种较为宏大的目标，时间跨度较长，任务复杂度也很高，但可以慢慢细化。

• 议题：定义下一步需要完成的小任务，类似修一个 bug 的主题。可以和提交、合并请求关联以补充其意义。

• 合并请求：在子仓库/子分支合并代码到主仓库时产生，可以详细地描述此次合并的相关工作以供评审。

我们以前可能会使用某些共享文档做需求的记录，进度的追踪，现在我们可以用 GitLab 做统一的管理，这是所有事情的唯一入口。

• 进度可跟踪。因为议题的打开和关闭分别象征着任务的启动和结束

• 团队管理上也方便了，不同的任务交给不同的角色去做。

• 过程记录充分，每个节点都可以伴随大量的说明信息去阐述具体的工作，我们实际就会利用这些记录在以后去统计学生的工作量，需求的管理等等，从而生成报表

持续交付

CI/CD 工具

我们最终选择在云服务器部署 GitLab 的原生服务——GitLab Runner 实现流水线的运行。

为什么不用强大的 Jenkins 呢，这个我们也有尝试过，但是对我们学生来讲，他的学习成本和维护成本还是比较大的，需要有人专门去做这件事。

迁移之后我们也同时拥有了一定配额的极狐 Group Runner，不过我们还是沿袭了原来的本地化 Runner 习惯。

GitLab 的流水线足够应付我们的项目，学习和维护成本也相对低一点，自然还是选择了原生支持的 Runner 了。

GitLab 流水线模板

这里截取 Test 阶段的执行例做一下示范。

在 Test 阶段我们会并行的发起多个测试任务，他们之间各自没有联系，所以可以并行。我们会对代码、容器、依赖的安全性和单元功能做一系列测试。其中呢，在做代码的相关安全扫描的时候，我们都使用的 GitLab 所提供的流水线模板，相当于我们只需要提供待扫描的代码，它都会自动调用开源分析工具去测试，并且自动生成安全漏洞报告，集成在流水线的结果页面。

总结

无论是水杉、GitLab 还是 DevOps，我们都凝聚了大量的心血在上面。尤其是从理论到落地的过程，即使有了对应的工具，你也不能保证它安装之后就万无一失，不能保证今后项目成长起来就没有坑了，你一定是会花费工具的学习成本和维护成本的。目前看下来 Gitlab 对 DevOps 的支持很不错，在它上面所花费的心血没有白费，现在的效果还是非常好的。

实际上除了技术上的实现以外，DevOps 也不能完全脱离人的范畴。就好比你辛辛苦苦设计了一整套流程，但还是无人遵守，那不就白费功夫，所以我们在实现流程细节的同时也在开发者之间传播着一种 DevOps 的理念和规则。比如开发者要自觉遵守统一的代码规范，合并请求要绑定 issue，对函数功能或者数据库的表有改动时就要对文档进行改动。这也是工程上比较重要的一点。