代码管理_代码管理：核心技术及实践，微服务架构下的代码管理

今天我们来读一读《代码管理：核心技术及实践》这本书。

微服务架构下代码管理需要考虑以下三方面的挑战：

1、跨团队的代码协作和共享

如何建立有效的分布式代码管理过程从而保证多个团队在代码修改层面的协作和共识？

2、跨服务的代码重构及维护

跨服务的变更要求在多个代码库中同时进行操作，如果没有建立相应的自动化机制，那么这样的跨服务(代码库)的改变是不可能完成的。

3、多代码库的版本策略

微服务架构带来的一个显著优势就是每个服务可以持续快速地进行更新和发布，而服务之间不可避免地存在集成调用关系，理论上每个服务升级都不应该破坏之前已经存在的调用。但每个服务都有可能因为自身的升级出现不可预期的问题，这时需要有快速的自动化回滚能力，回滚的版本需要根据既定的代码版本策略来决定。

针对微服务体系下的代码管理，一般建议采用分支开发主干发布模式：

模式特点：所有的代码提交都在分支上操作，随着时间的演进，需要构建Release版本时，需要将代码提交到主干上面，平常开发都是在分支上进行，好处可保证主干代码始终可用。

操作权限：该种方式开发人员只具有开发分支权限，无master权限，代码的merge只能由项目经理或有权人完成；

适用场景：该种模式适用于多功能并行开发，按照业务特性或模块进行在分支进行开发，然后在进行合并后进行Release构建发布，业务场景较复杂，且人员素质层次不齐，需要代码review。

代码管理规范

原则上代码的开发提交，必须通过创建分支进行开发，特殊情况除外(bug)，review同事有责任进行检查其他同事是否遵循分支规范；

代码提交前，必须先进行更新代码(gitpull)，对于有冲突的文件，必须要进行对比，确认素有修改都是自己修改的，然后在进行提交，防止代码回溯(即别人的代码被覆盖)；

review同事遇到代码删除情况，必须与开发确认，是否为开发同事自己删除，如果不是，很可能就是代码回溯；

在代码开发阶段，代码的提交尽量独立化，也就是功能模块尽量细分，每个开发负责一个模块，尽量不要修改其他成员模块代码；

多人协作时，需要创建一个远程分支，然后一起在远程分支里协作开发，防止代码回溯。禁止各自开发，然后线下发送文件合并；

代码提交前，必须进行git pull，且进行git diff进行比对代码，确保提交代码为自己修改内容，防止出现代码回溯；

代码出现冲突时，必须 要与冲突代码提交者进行确认冲突内容，双方确认无误方可处理；

主分支(master)为生产环境分支，除特殊情况(修复bug)，禁止在master分支上进行开发；

代码提交时，必须描述清楚做了什么，提交动作有add、update、remove，提交格式为[动作]+[操作的模块信息，尽量详细到具体的类名方法名]+[操作描述信息]，例如：git commit –m ‘update aa.java findByName 将精确查询修改为模糊查询’，每次提交尽量一个动作，多个动作请多次提交；

在git中，默认空目录不会提交，如果某个空目录想提交到版本库，需要在该目录下新建一个deleteme.txt的空白文件；

开发分支(developer)为开发分支，一般作为主要的代码提交分支；

修复分支为修复bug分支，命名格式为bugfix-{date}，修复分支用于主要分支的bug修复工作；

功能分支为新增功能分支，命名格式为feature-{message}，可合并到developer分支；

其他分支，为特殊情况建立的分支，命名应带有分支相关信息；

推荐阅读：

《代码审计企业级Web代码安全架构》，为什么需要代码审计？

《发布！软件的设计与部署》，如何保持系统稳定运行？

不尽读天下之书，不能相天下之士。

——汤显祖