云效使用指南：持续交付：(待迁移)团队开发模式介绍

本章主要包括3种研发交付模式，你可以选择一种模式，加上测试过程，就可以开始频繁的交付啦。
详细内容介绍之前，简要推荐下版本控制工具git，Git分布式的版本控制系统，对于离线开发、多人协作、元数据存储具备非常明显的优势。
git的一个比较重要的理念是”功能驱动式开发”（Feature-drivendevelopment，简称FDD）。它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfixbranch）。完成开发后，该分支就合并到主分支，然后被删除。

<a name="自由模式" class="reference-link">
自由模式


自由模式，顾名思义，您可以使用任何主干或是分支进行打包和发布。
自由模式也包含主干开发模式，主干开发模式是JezHumble推荐的普及的传统模式。您将所有的更改都合并到主干代码版本，并持续运行自动化测试。目标是尽早整合，尽早找到问题，并训练您的团队以避免这些问题。主干开发模式容易设置，可以扩展支持复杂的集中式构建和测试系统。适合团队：固定组合的小团队，每人负责一个或者多个独立应用；优点：自由度高，用户可以采用任何版本进行打包和部署；
缺点：代码的版本控制以及质量需要团队自己保证，风险较高；对于多人协作开发场景支持较弱，管理成本较高；

<a name="分支开发模式" class="reference-link">
分支开发模式


为了适应于业务的快速变化，阿里的分支开发模式，允许每一个需求、任务在单独的分支上进行开发，单元测试和冒烟测试完成后，再与其他分支一起集成，进行集成测试、回归测试、灰度测试、性能测试等过程，最后进行发布。
适用团队：快速成长型小团队：团队并行需求开发较多，需求进度经常调整；优点：功能分支独立开发和测试，互不干扰；版本节奏可灵活控制，出现延期的分支可直接退出，代码可迅速剥离；
缺点：每次部署都是临时release分支，可维护性较差；分支越多，集成越晚，冲突就越多，集成的成本以及测试问题越多，需要控制分支数量；


<a name="git-flow模式" class="reference-link">
git-flow模式


git-flow模式中，代码库存在两个长期分支。主分支master和集成分支develop。主分支（master）：用于存放线上稳定的版本，任何时候在这个分支拿到的，都是稳定的线上版本；集成分支（develop）：用于集成功能分支，用于各功能分支的集成测试和发布，发布完成后再合并回主干master。
其次，项目存在三种短期分支。功能分支（feature branch）补丁分支（hotfix branch）预发分支（release branch）一旦完成开发，它们就会被合并进develop或master，然后被删除。
适用团队：5人以上团队，团队成熟度较高（代码质量较高，有自动化测试能力）；优点：各分支用途明确，较好的满足了功能并行开发与持续集成诉求；分支过程与集成测试过程自动化程度较高，可随时交付。
缺点：要求功能分支的质量达到要求，并且通过代码review后，后方可进入集成，对分支代码质量要求高。