CODING：小白都会用的代码协作工具

经常来我站的朋友有很多从事软件开发、UI/UX 设计、产品设计等职业的，大家在各自的领域都会用到垂直领域内的协同工具，这里就不再赘述有哪些代表者，但这些工具也好，服务也好，就好像一座座孤岛，彼此之间的沟通协作并不能成为一个整体，对于出具规模的研发团队来说，如果提高团队的工作效率，协同沟通效率显然已成为当今互联网产品大生产场景下的刚性需求。
痛点
早年间我曾在一家专为企业级路由器系统研发公司担任测试工程师，当时还没有像 CODING 这样覆盖“产品→开发→测试”三大环节的研发管理系统，三个部门的人各自为营，沟通方式基本靠开会，研发组写完的代码灌入设备后给测试组，测试用例完全靠人肉文档，一遍又一遍，反馈给研发后，那边又不重视我们的报告，漏洞百出得不到有效记录，又被产品经理每天雪花般的新需求搞的想砍人；同时产品、研发、测试三方就需求设计、功能实现、产品可用性的探讨，甚至可以说是争执，已经严重占用了大部分的生产时间，最后还是得加班完成各自的任务。我一直在想，当时要是有 CODING 这样的平台就好了，严谨而科学的版本控制、代码质量管理、清晰的任务需求管理都可以帮助大家省去许多重复劳动和时间成本、健康成本。

CODING 是什么？

使用 CODING 除了能克服上述问题，还能帮助一个研发团队从分支管理到代码评审，从任务分派到里程碑制定，再到文件系统和 Wiki 沉淀等诸多方面，诸多细节去帮助开发者更加高效地协作。

CODING 企业版（后面简称 CODING）是面向开发团队的WEB软件研发管理系统，整个团队成员可以在里面进行代码管理（重中之重）、需求管理、持续集成、测试管理、缺陷管理、任务分配等功能，适用于传统模式和敏捷模式的软件研发项目和产品运营，是一款真正意义上的 DevOps 全流程应用。下面我们就来一一介绍 CODING 包含的各项核心功能，在正文展开前，大家先看一下 CODING 后台管理界面左侧的工具栏，一共 14 个项目，其中最核心的服务放在了中间，这么多的功能当然是面向不同工种的同事了，下面来看看这个 list：
各项目针对的使用人群及联系
项目 leader 负责在迭代、工作管理、任务管理等模块负责整个项目的进度、数据分析等工作；

产品经理负责在 Wiki、需求管理、文件系统中提供明确的产品需求；

研发工程师负责在代码仓库生产、维护代码，进行持续集成、环境部署等工作；

测试工程师负责在缺陷管理、测试管理中修 bug；

设计师负责在文件里上传设计文件。

当然，这里面有些项目不是专属于哪类人群，有些是大家共同进行协作沟通的地方，比如任务看板、Wiki、文件系统、工作管理等等。

产品经理在 CODING 里能做什么
我们知道，作为产品经理，他的日常任务就是搜集用户需求、编写产品功能书，设计产品原型，并在用户反馈、UI/UX 设计、功能研发三个阵地来回穿梭，协调，最后给用户呈现一个令其满意的产品。CODING 里涉及到产品经理用的较多的应该是 Wiki、需求管理、任务看板

CODING 支持将其他平台的项目直接导入其中使用

Wiki

不得不说 CODING 的 WEB 界面做的简洁而不失高效，Wiki 好似 Typora 的 Markdown 编辑界面，事实上这里也是支持 MD 语言编写文档的，产品经理可以在这里为工程师、设计师提供尽可能完善的产品交互原型、产品解析文档等等。
需求管理
需求管理客观讲不光适用于产品经理，工程师的技术需求、其他部门人员的运营需求都可以提出来，然后由 leader 将此需求分配给对应负责人，这里就涉及到创建工作或关联工作了。

看下，举例，产品经理根据用户使用情况记录并新建了一个需求，这个需求默认状态是“未激活”，而 leader 看到需求后邀请研发、设计的同事进来关注，经过讨论沟通，认为可以执行添加此需求，则 leader 可以将需求状态改为“已计划”，设计侧的同事接手开始干后标记为“设计中”、然后交付给研发同事，状态标记为“研发中”，以此类推，直到需求被实现标记为“已关闭”，在这个过程中，团队成员可以随时看到需求实现状态，看到活动日志以及关联的各种附件、里程碑、任务、合并请求。
研发工程师的好伙伴：Git 代码管理
CODING 的核心服务对象是研发工程师，关于对代码库的维护能力当然是 CODING 最关注的地方，Git 也是这套系统里的重中之重，代码的浏览、分支管理、发布管理、版本对比、合并请求当然都不在话下。

在介绍代码管理的几个子功能前还是跟大家科普一下 Git 这套分布式代码管理系统的基本原理。

传统的代码管理都是点对点的同步部署，也就是你和你的同事在各自的本地机器编译完传输（或者也叫同步吧）到远程服务器或者直接发给架构师/leader，然后由架构师/leader将你们的代码揉在一起，但这个过程很容易出问题，而 Git 则是由主开发者将代码上传到服务器后，其他开发者可以从服务器get到完整的代码然后根据任务开发功能后创建为一个分支版本，并从自己本地机器测试后将生成的代码推送回服务器。在这个过程中，主开发者可以发起代码评审、处理代码合并请求、有效控制产品版本，各个分支版本之间的代码冲突也可以获得有效避免。
代码浏览
代码浏览是最基础的功能模块，包括默认分支 master 在内的所有分支版本，主开发者（leader）都可以在这里看到，当然也可以操作代码的浏览、新建、上传、下载；代码支持在线编辑、路径复制、按行查看等功能。

我们可以通过左上角的隐藏菜单切换到各个分支版本进行代码预览。
分支管理
接下来是分支管理，一个代码仓库建立后会自动生成一个默认分支 master，但一般情况都不会在这上面进行代码修改，就像前文我们提到的，团队成员会按照 leader 分解的任务去实现对应的功能模块，而这个模块都会有自己的分支版本，这样各个功能在合并前都会自行演进，互不干扰。

在你的代码完成后可以进行推送到服务器上，发起合并请求
合并请求
Leader 可以在接到你的合并请求时，可以在对应界面添加代码评审者，标签、关注者，这些人会是架构师、测试工程师、产品经理。

同时你可以在合并请求里看到代码的改动具体情况，代码变动部分会用绿色背景标注。你可以关联里程碑、任务、合并请求等，或者最底部留言输入评论内容，比如“小李这功能做得好，这代码不错等等等…”

在创建合并请求时你会遇到“版本对比”，在“版本对比”界面选择或输入两个不同的分支、标签、修订版本号进行对比，查看差异；版本对比可对代码进行审查与评论，系统会检测比较版本能否自动合并。
发布管理
当完成一个里程碑的所有任务开发之后，你就可以在某个节点将此时的默认分支标记为一个版本，并发布这个版本。

除了上传代码，你需要详细的记录每个版本的“更新日期”、“改动说明”、“版本对比”、“版本规划”等内容，CODING 支持预发布版本标记。

关于持续集成

持续集成的概念诞生自 1991 年，就像我开头提到的传统协作方式遇到的诸多弊端，持续集成的推出就是为了解决开发团队每天大量的重复性编译、测试工作，提高交付效率，在枯燥的电脑前，人类创造了像 Jenkins 这样的自动化集成系统，它可以帮助人类完成每次版本诞生前枯燥的编译、部署、自动化测试工作，让工程师们专注于开发

CODING项目可直接集成到腾讯云平台上，同时支持多种运行环境
在创建持续集成时你需要“代码更新触发”还是“手动触发”，选择推送到某个指定分支时触发，以及用常规模式or云服务器模式进行集成的执行，云服务模式就是允许用户可以将执行环境部署到云端服务器，并且自行创建容器来执行集成的构建。

CODING 的持续集成是完全基于 Jenkins 的，兼容 Jenkinsfile 配置文件。

项目 leader 统筹规划靠这些功能
除了工程师、产品经理会频繁用到代码维护、Wiki、文件系统外，项目 leader 也可以使用 CODING 里的任务系统和工作管理两个模块。
任务系统
在任务系统里核心当然是“里程碑”了，这个开发人员都很熟悉，CODING 支持在列表与甘特图之间随时切换查看里程碑，在里程碑详情页面你可以清晰的看到整个计划的完成度、是否超时，每项任务的完成情况，完成进度，持续天数。