运维自动化基础建设|代码分枝模型续
运维自动化基础建设|代码分支模型续
这是一个很大的话题, 同时也是一门玄学，每家公司的使用的场景虽然大差不差，但是受限于历史债务以及业务线划分割裂，很难有一个站在公司角度上的统一的代码分枝模型，导致的后果也是
OPS需要在CI/CD这块上面适配多种场景来满足需求，接下来的文档我就和大家一刻聊聊分支模型，以下描述仅代表个人观点感受。
实际场景中可能存在的问题
•是否有强约束(严格要求各组按照标准去执行)•QA回归测试和生产部署分支是否保持一致，不一致的情况下是否会产生重复劳动,比如漏测啊，忘了合并代码啊等问题•大版本(超过2周的功能)迭代遵循的分支模型方式下如何和主干保持一致(特地同时跨部门协作的场景下)•环境和分支是否要绑定或者有一个对应的约定俗成的关系存在•过多的分支如何管理(代码管理平台上是否允许远程分支提交)
我经历过的分支定义的主要分类
•主干分支master, 需要打tag, 只有项目Owner有merge权限,其他人全部走pr•上线分支stable, 需要打tag, 任何人没有提交的权限，仅用于发布，由项目Owner进行merge操作。•feature-*分支，用于大版本更新迭代。•hotfix-*分支，用于紧急修复生产bug的分支定义。•other分支，这个分支是否允许提交到远程仓库，看公司具体的场景而定。
个人的几点感受
原则上来说生产运行时的代码是落后于当前代码仓库的主干的，但是有时候出了hotfix的场景下，需要再从上线分支上拉一个最新的分支进行修复，后续再重新合并回主干的操作可能会把人给绕晕，最起码对git不是玩的很6的人来说，提几点个人理解的小建议吧
•merge的时候尽量删除源分支，要不然日积月累，你会发现CI上分支下拉菜单搞的你头晕•分支命名尽量避免个人姓名和字母缩写的方式，要不然别人merge的时候看着真的是一脸懵逼•跨业务线协同的时候，尽可能的达成共识(pre-commit, code review)等等一系列的约束•要么严格要求强制执行，要么就完全放弃•分支模型的不统一，对后续的code review以及CI中的大部分工作都会变成按需定制• 容器环境下的分支的tag可以直接复用为tag, 见名知意，而且方便跟踪
曾经掉进去的坑
场景一
某个大的功能，从两个业务线临时抽调了三个开发和一个测试来完成工作，张三、李四、王二三人协同开发，这个时候张三和李四的功能开发完毕并提交到了分支feature-demo，王二的工作还在进行中，张三和李四催着马五开始测试，但是在测试的过程中王二提交了代码，恰恰这个代码跟李四的代码是有冲突的，马五测到一半测试不下去了，去找张三、李四，张三和李四排查了下说这个问题导致的原因是王二提交的代码有问题，你去找他，马五摇摇头又去找王二，王二说，我本地测试没问题啊(未合并最新代码)，这个项目的owner是张三，你找他看下，然后。。。。
场景二
某业务线接到产品需求，需要在两天内上线某个新功能，然后张三、李四、王二、马五又开始并肩作战来，在功能提测的时候是在feature-A分支上进行的，一切顺利，马五发起了上线审批，一顿操作猛如虎，线上新功能未生效，会追原因，原来代码并没有合并到主干(也有可能是stable)分支。。。
场景三
还有很多很多，其实你们自己更能感觉到疼。。。
总结
经过上面的讲解我们能够知晓分支模型的选择，以及选择了对应的分支模型之后存在的问题，以及要注意的事项，真实的场景中，在代码提交之前还有很多pre-commit的动作(有些公司用的是post commit)来帮助我们进行code style以及语法检测的动作，避免低级错误，毕竟代码提交到远程之后需要code review， 你也不希望经常因为一些低级错误被同事diss吧。抛开常规错误问题，在后续的CI的过程中会再次进行代码质量检测和安全审计扫描相关的动作，这些都具备条件的场景下才会投递到制品库。后续我们会补上相关文档。