主干分支开发

正向流程

基于我们版本稳定，代码质量的目标形式如下

 

解释

sonar检测会扫描代码中不规范的情况，按照代码规约不同，会有不同的级别，包括 WARNING, MAJOR, CRITICAL, BLOCKER 四种级别，基于不同级别可以设置拦截规则，如果代码不符合设定的拦截规则，将不予 merge

代码评审会触发代码评审邀请，可以根据设定，邀请组内研发，leader，或者测试人员参与代码评审，通过设定规则，如果代码评审通过，才允许 merge

现在自动进行 maven 打包和单元测试工作，如果单元测试不通过，将不予 merge

流水线会自动将单元测试通过的 jar 包发布到测试环境进行部署，部署完成后自动调取线上自动化测试流程，只有所有接口通过自动化测试，才允许 merge

优点：

• 分支模型简单高效，开发人员易于掌握不容易出现错误操作
• 避免了分支合并、冲突解决的困扰
• 随时拥有可发布的版本
• 有利于持续集成和持续交付
• 简洁性：简单明了，易于遵循，适用于小型团队和采用持续交付实践的项目。

缺点：

• 基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关；
• 自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能在获得快速和可靠的质量反馈；
• 最好有代码评审：若代码质量要求高，需要配套代码评审（CR）机制，在代码提交到主干时，触发 CR，通过 Peer Review 后才能正式合入；
• 最好有特性开关：主干开发频发合入主干的情况下，特性拆分得很小，可能是半成品特性，需要配套特性开关（Feature Toggle），只有当特性整体开发完才通过灰度发布等手段逐步打开；