Coding 如何使用 Coding 开发 Coding

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› 轻量级社交

› 开源项目广场

› 使用帮助

› 意见反馈

这是一个创建于 3034 天前的主题，其中的信息可能已经有所发展或是发生改变。

Coding Anytime Anywhere

Coding 团队有 70 多人，分布在全国各地（深圳，北京，上海，成都），我们使用 Coding 作为云端办公室，以云端协作的方式管理事务，文件等，我们的日常工作（包括但不限于产品，研发，市场）都是在其上完成的。 Coding 的全平台支持让大家可以随时随地进行同步与协作，我们一直在践行 “ Coding Anytime Anywhere ”。

我们使用 Coding 团队功能管理团队成员和私有项目，只需要在 Coding 创建一个团队，选择迁入私有项目并添加人员，即可完成对成员，团队与项目的管理。（项目内也可以设置不同成员的权限）

Push Everytime ， Review Everything

Coding 的工作流（从需求到产品原型到开发）都是在项目内进行的：我们使用讨论和任务功能管理需求，使用文件功能管理产品原型，使用代码功能进行开发，这也便于每个人随时 Follow 或 Review 任务，文件或代码。

需求

我们使用 Coding 的公开项目讨论功能收集用户反馈，提炼核心需求并定期 Review 进行取舍。

为什么要 Review 产品需求？软件缺陷并不只是在开发阶段才产生，需求和设计阶段同样可能会产生缺陷。

产品

当产品研究决定我们要实现某功能时，我们会以任务形式发布该需求，然后进行技术评审（如果是重大新功能还需要进行设计评审），评审完成且结果为肯定时我们会继续细化（修改）该任务，进行产品设计及排期。

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

开发

Coding 的开发方式，更像是一个大型的开源项目协作。当需求及产品原型以任务形式确定后，开发人员就开始基于自己的功能分支进行开发，其后的代码评审是也是通过项目内提交 MR （合并请求）进行的。

我们使用了 Feature Branch Workflow ，即团队成员共用一个私有项目仓库进行管理协作，开发者在各自的 feature-branch 中进行开发，开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支（ master 分支是可部署到 staging/生产环境的分支）。

工作流（ Workflow ），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。合理选择并使用一套工作流可以让技术团队开发更高效，更简单！

Workflow 没有银弹，如果你的：

生产环境有多个版本，需要持续支持旧版本的软件服务如操作系统，自定义应用程序等，可使用 Gitflow
生产环境只有一个版本，如网站，网络服务等，可使用 Feature Branch Workflow
生产环境只有一个版本但软件很复杂，需要 CI/CD 后才能进入生产环境的如 Gmail ， Twitter 等，可使用 Gitlab-flow

测试与上线

当开发人员 push 代码后会触发 Webhook，我们的 Jenkins 会自动编译并测试该 commit 。

你的部署工具应该支持你部署分支是很重要的。一旦你确认你的性能没有波动，没有稳定性问题，功能可用性在预期内，你就可以 merge 它了。这么做的原因不是为了确保事情可行，而是防止事情不可行。当其出错时，你的解决方案应该是单调，直接且无压力的：重新部署 master 分支即可。就是这样，你回到了“没问题”的状态。—— 《如何部署软件》

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