CODING如何使用CODING研发管理系统来敏捷开发

Z时代
2024-01-10
分类：综合

coding

之前我们分享过《CODING 如何使用 CODING 开发 CODING》的文章，时过境迁，现在 CODING 研发管理系统已经上线了如持续集成、缺陷管理、测试管理等 DevOps 中的重要功能，并增加了对 SVN 的支持。借此机会我们以自身的研发流程为例，来展示一下 How CODING uses CODING to build CODING 2.0。

企业级一站式软件研发协作平台

CODING 现在的团队有 100 多人，分布在全球各地（深圳、北京、成都、西雅图等），均使用 CODING 研发管理系统作为云端协作平台。在 CODING，不仅研发相关的团队使用 CODING 来进行研发管理，市场、运营、行政的部门也同样使用 CODING 进行任务分配与追踪、文件分享等日常工作。

同时通过 CODING 的企业微信/微信小程序，还能实现随时随地同步与协同任务，小程序可以直接查看任务详情、评论任务，还能实现代码合并（MR）等功能，真正做到 Coding Anytime Anywhere。

CODING 研发管理系统是基于项目进行的，我们依据组织架构建立了相关项目并使用【成员管理】添加相应部门的人员。通过项目这种扁平化的管理形式，帮助企业加快反应速度，提高自身敏捷性。

下周即将上线的 CODING 权限管理功能，可以帮助项目管理员方便地根据项目成员角色来分配相应的权限，减少误操作带来的安全隐患。同时支持自定义用户组，增加研发管理的灵活性。

Push Everything,Review Everything,CI Everything

workflow

CODING 研发部门的工作流都是在项目内进行：我们使用任务功能来管理需求，使用文件来保存产品原型，使用代码功能进行开发，使用持续集成来进行自动化测试，使用缺陷管理来收集反馈，同时还使用 wiki 模块对知识进行储存与共享。通过在任务中添加关注者的方式来方便相关同事随时 follow 和 review 任务动态。

CODING 强大的任务系统支持标签、跨项目引用、版本控制等多项功能，并会实时记录用户的每一次操作。同时 CODING 需求管理功能也即将上线，将在任务系统之外为用户提供更细分更场景化的使用方式。

产品

CODING 的产品经理在正常的产品功能排期之外，会定期在缺陷管理中查看用户的使用反馈并对相关问题的修复进行排期。

当产品经理研究决定我们要实现某一个功能/修复缺陷时，会以任务的形式发布该需求。但是在发布需求之前有几件事情需要先做。

给任务定性

产品经理会把任务放入“需求反馈池”看板，并给任务定性：

纯技术问题（含纯技术 Bug），则指派给研发负责人进行跟进。

纯设计问题，则指派给设计负责人进行跟进。

（真）产品问题，则准备与发任务的源头沟通分析此问题。

问题分析

伪需求，或者反馈方理解有误，则直接在相关任务中回复，并关闭任务即可。

真需求，则完善对应的背景信息，并将任务拖入“已分析需求池”。

Bug 类，可以内部请测试人员来尝试复现此问题。如果可复现，则给此任务打上“Bug 池”、“已确认”标签，再将任务放入“已分析需求池”。

分析完需求后即可创建任务，如该任务涉及大型产品改动，则会由相应产品经理撰写完整的产品说明文档和必要的原型图等文件；方案完成之后，产品经理会根据任务的紧急程度给任务设定优先级，方便后续设计和开发的同事更方便的安排工作。

在产品设计过程中，我们使用 CODING 的文件管理功能对产品进行原型管理和版本管理。

功能开发完成后，产品经理还会配合研发进行 Staging 环境的验收。如在 Staging 环境中发现问题，则需要与发布负责人协商回退或是重新发版，成功完成验收则通知运维上生产环节。

开发

在产品经理完成原型图和产品说明后，便会把任务移交给研发负责人，进行评估和排期，完成排期后研发负责人会根据任务情况安排里程碑。

开发人员开始基于自己的里程碑任务进行开发，其后的代码评审也是通过项目内提交 MR （合并请求）进行的。

CODING 使用了 Feature Branch Workflow，即团队成员共用一个私有项目仓库进行管理协作，开发者在各自的 feature-branch 中进行开发。

Code Review

开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支（master 分支是可部署到 staging/生产环境的分支）。

持续集成

当开发人员 push 代码时，将会自动触发已设置好的持续集成，CODING 的持续集成会自动编译并测试该 commit。CODING 持续集成支持在任意阶段触发并支持 cvm 模式。

当测试通过后，我们会更新代码到 Staging 环境。

测试

更新 Staging 的代码后，测试人员开始进行相关测试。现在 CODING 的测试管理功能由 18 年收购的专业测试工具飞蛾（ FEIE.WORK）承载，已实现了企业账号打通，可直接在测试管理中点击跳转到飞蛾的工作界面。

接到测试任务后，测试的同时会先在飞蛾中制定相应的测试计划。

制定好测试计划后，即可开始编写相关测试用例并开始执行测试计划。

Staging 环境测试无问题后，该功能会以 Feature Flags（内部测试新功能）的形式发布其到生产环境，通知相关的产品或设计人员开启 Feature Flags 进行内部 Review，如果存在问题或缺陷，我们会新建一个任务进行产品反馈，确保功能及设计细节的正确性。

运营

产品正式上线后，CODING 的运营同事会开始收集用户反馈，通过各个渠道反馈的问题都会在 CODING 缺陷管理功能中以创建缺陷的方式进行归纳。

运营会定期将收集来的缺陷进行分析，将 Bug 类的缺陷转给产品经理进行排期。如在生产环节发现重大 Bug 则会立即和产品经理沟通并通知运维，协商回退版本或者临时修复。

市场

在确认功能顺利上线后，产品经理会在 CODING Wiki 中更新 Roadmap，提示功能已经上线。方便市场部进行 Campaign 的计划。

市场部的同事使用 CODING 任务管理中的讨论功能，可以实时讨论和跟踪项目进度。

让开发更简单

工欲善其事，必先利其器，在现在数字化的商业环境中，企业对于软件的依赖已经达到了前所未有的高度。如何选择一套适合中国软件研发团队的开发工具和高效的研发流程，以解放开发人员的效能，打造更好的产品，已经成为每个企业必须要思考的问题。逆水行舟，不进则退，我们自身使用 CODING 进行开发，旨在不断完善 CODING 的功能，优化提升 CODING 的使用体验，让 CODING 成为最适合中国式敏捷的研发管理系统，真正做到让中国的软件研发团队开发更简单！

同时我们也欢迎各种反馈，如果你有任何需求或建议，请不要忘了提交给我们 :D