Coding 如何使用 Coding 开发 Coding

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，若是存在问题或缺陷，咱们会新建一个任务进行修复，确保功能及设计细节的正确性。

若是经测试新功能确认没问题后，咱们会开放该 Feature Flags，将该功能开放给全体用户。

结语

Coding 始终认为开发工具应该足够简单，开发人员的生成力应该被解放出来，咱们使用 Coding 这个开发工具进行开发，旨在不断优化提高 Coding 的体验，让开发更简单。固然，若是你有任何需求或建议，请不要忘了 提交给咱们 ；）

Happy Coding!

感谢 @summer ，@rexskz Review 了本文并提出修改意见，感谢 @tankxu 设计的图片（How Coding uses Coding to build Coding）