CODING 最佳实践：快课网研发效能提升之路

快课企业移动学习平台是上海快微网络科技有限公司自主研发的企业级 SaaS 平台，提供移动学习、考试练习、培训管理、知识分享、统计分析等学习和培训功能，为员工、经销商及客户等全价值链合作伙伴提供全面的知识服务。
本文将详细介绍快课网的研发团队是如何使用 CODING 研发管理系统提高研发效能。

为什么选择 CODING

快课网从创立至今已有 4 年多，作为一个规模比较小的创业团队，我们一直在寻找和尝试各种能提升研发效能的管理方案，这样能够帮助团队节省时间，更加专注于业务。

第一步就是上云，我们一开始使用的是阿里云，通过容器化、弹性计算和可视化管理帮助我们节省了不少运维成本。但是仅有这些还不够，要开发还需要搭建很多服务，例如 BUG 跟踪管理、代码版本管理和同步、npm 私服、maven 私服、docker 私服等等。虽然后台团队通过使用 docker 让搭建服务方便了不少，但是我们还不满足。大量的服务为研发团队带来了极高的管理成本。再加上不菲的服务器成本、所使用的开源项目更新较慢等原因导致很多问题短时间内都解决不了，同时很多管理方案还不支持中文。所以我们决定寻找一个集成度比较高的国内的商业平台来帮助我们进行研发流程管理。当时的想法很简单，只要功能齐全，收费能够弹性一些就好。在尝试了很多平台之后，我们最后决定使用 CODING，主要是看中 CODING 的网络连接速度比较快，界面简洁，交互比较友好，功能齐全，反馈处理也非常及时，可以很好地帮我们解决代码托管和 BUG 管理等研发流程问题。

我们最开始使用的是 CODING 个人版的团队功能，在 CODING 推出企业版之后我们团队很快迁移到了企业版，相对于个人版来说企业版功能更完善，管理起来也更方便，后续还有持续集成和部署相关功能升级，这些功能正是我们团队所需要的。目前快微团队的整个开发是在 CODING 和阿里云上完成的，CODING 主要用来管理代码、里程碑和持续集成等研发流程。

版本规划与任务流程

里程碑是我们使用比较多的功能之一。最初，我们使用 CODING 的里程碑来规划版本，比如 1.0 版本对应的里程碑就叫做 1.0，每个任务都是版本中的功能点。后来由于新版本的重构采用了分布式服务化开发，由多个子项目组成。由于各个子项目地版本相对独立导致粒度太细不方便产品的规划，便做了一些调整。目前里程碑主要是用来做长周期的规划，每一个任务都是一个小的项目，由一个或多个人来完成，比如将课件服务 1.1 版本分就单独为一个任务。

快课技术团队目前的绩效考核也是基于 CODING 的任务管理和里程碑实现的：

1. 由产品发布相关版本的产品说明书，包含原型图和功能点文档部分。
2. 创建任务，分派给项目负责人，项目负责人需要评估任务的工作量。工作量给定的有参考标准，将最简单的帐号密码登录接口的工作量定为 1，最小为 1。评估工作量之后进行审核，确定起止时间和奖金。
3. 进入开发阶段，开始倒计时。
4. 开发完成之后进行验收，由技术审查代码（每次发起合并请求也有审查），产品检查 UI 交互，顺利完成验收则关闭任务，将工作量的值作为绩效值。对于不能按期完成的任务，进行惩罚措施，每逾期一天扣 10% 绩效。

对于工作量比较大的任务，可以由一个人主要负责，多人完成，负责人需要为每个人安排详细的工作内容，最终由负责人按贡献比例分配绩效和奖金。这样累计下来，每半年或一年可以根据绩效进行一次评定，给表现好的员工涨薪。

分支管理

快课目前的分支管理方案与 CODING 文档中的最佳实践比较接近，master 作为主分支只发布正式版本，新增一个 dev 分支作为开发中的分支，并且同时对这两个分支设置保护，禁止直接推送代码到这两个分支上。

快课的每个子项目都在项目配置文件里写有明确的版本号，后端 maven 项目写在 pom.xml 中，前端 node 项目写在 package.json 中。开发中的版本号一律带有 SNAPSHOT 后缀，以表示这是快照版本，会不断发生变化，不能在生产环境使用。比如正在开发 1.1 版本，此时 master 分支的版本号是 1.0.0 （随着补丁的增加，最后一位也会不断增加，比如版本号有可能为 1.0.9 ），dev 分支的版本号是 1.1.0-SNAOSHOT。

当需要开发一个新版本的时候，首先基于 dev 分支新起一个分支，可以根据实际情况来命名新分支，比如可以叫 dev-v1.1 或者 dev-tom 等等，没有限制。在新分支上完成开发之后，在 CODING 上发起合并请求申请合并到 dev，此时合并请求的标题和内容必须写的详细一些，审核之后进行合并，合并的同时删除原分支，只在 CODING 上保留 master 和 dev 两个分支。

最终所有新开发内容都完整合并到 dev 分支后，测试通过，再从 dev 分支新起一个分支，更改版本号为正式版本号，进行推送并新建合并请求，合并到 master 分支上。

对于已经上线的版本，如果有 bug 需要修改，则从 master 分支新起分支进行修改，完成后将版本号最后一位 +1，然后推送并新建合并请求合并到 master。

持续集成

我们团队很有幸获得了 CODING 持续集成功能的内测资格，之前也有尝试过自建 Jenkins 服务，对持续集成有一定积累能很快上手，于是我们便开始转向 CODING，毕竟一站式的 DevOps 工具链服务更方便，可以给研发团队节省很多精力。

CODING 对 Jenkins 进行了封装，只需要在项目根目录下创建一个 Jenkinsfile 文件，配置好之后推送上去，推送完成之后在后台开启持续集成即可。持续集成主要用在后端 maven 项目上，来做规范检查（ checkstyle 插件）、单元测试和代码质量检查（ spotBugs 插件），这样当团队成员在创建合并请求时，管理者可以看一下代码是否规范并跑通了必要的测试，在 CODING 上构建成功后才能继续对修改进行审查。

自动化构建为研发提供了很大的便利，避免了一些人为的不稳定因素，也为项目管理者节省了不少时间。

目前快课的项目都是直接发布到 docker 私服上的，推送成功之后修改 k8s 中的镜像版本来完成自动部署。我们也期待 CODING 未来会上线的部署管理功能，能支持在目前的构建基础之上自动发布 docker 镜像，然后再自动更新 k8s 相关配置的镜像版本，补充 CI/CD 功能，这样的话就能更好的实现研发流程的自动化了。

点击立即体验一站式 DevOps 工具链