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 支持在列表与甘特图之间随时切换查看里程碑,在里程碑详情页面你可以清晰的看到整个计划的完成度、是否超时,每项任务的完成情况,完成进度,持续天数。

相关推荐