DevOps介绍
DevOps一词是由development和operation两个单词组合而来，代表着研发和交付运营的一体化。DevOps在2009年就被提出，但在学术界和工业界还没有一个广泛认可的定义，一些有代表性的总结，比如John Willis从文化、自动化、度量和分享的四个特征来对DevOps的含义进行描述，Lwakatare等提出可以从协作、自动化、度量、监控四个维度来对DevOps来进行描述。DevOps的很多思想与精益、敏捷是一致的，是这两种思想的一种延伸，其中敏捷主要围绕产品研发环节，通过以人为本、开放协作、持续改进来实现价值交付，而DevOps不仅关注产品研发，将交付运维也纳入迭代优化的闭环，打破研发和交付运维之间的隔阂，覆盖从需求研发到业务上线再到运维的整个端到端的价值链。
一些研究显示了DevOps的有益效果。国外AWS、Google等公司通过应用DevOps实现分钟级的需求交付能力；取决于不同的场景，应用DevOps之后可以降低10%～30%的部署周期，节省20%的成本。DevOps在国内的应用也在持续增长，从某个调查问卷的统计分析来看，应用了DevOps的企业其效能更高。
DevOps运动发源于既拥有研发部门又拥有运维部门的企业，目前的实践也大多围绕在这个场景中，像JezHumble在其书中描述的持续交付，适用于互联网等自研自营的模式，但其他场景无法直接应用。例如，如果软件采购自供应商，软件研发和交付运维之间不仅仅存在“部门墙”，而且通过合同来建立的协作边界，中间涉及责任主体的切换。跨国软件交付除了少数互联网企业之外，大部分是软件供应商模式，并且还增加了时间和空间上的距离，因此，探索这种模式下的DevOps实践具有现实意义。
企业中，由于业务场景的不同，不同团队对于代码分支模型的应用也会有所不同，通常来说，会由对代码管控的强/弱程度、应用发布的高低频率为主要考虑因素来决定团队的代码分支模型。
场景1：强管控、低发布
该类型的开发常见于大型项目或者传统瀑布模式。比如，在众多大型企业中仍在执行的按季发布的方式。这一类型的场景，对于源代码的提交、源代码合并往往需要执行严格的人工Code Review，从而会有明显的多分支特征。基于该类场景，可采用Git flow的分支模型，有利于实现对源代码的强管控。
场景2：强管控、高发布
该类型的开发常见于直接面向客户的互联网项目，比如互联网金融、移动App等，由于业务的重要性，需要进行源代码更新的强管控，同时，又由于业务具有互联网属性，所以，需要经常性的发布。该场景下可选用Gitlab flow，既可以满足高频发布，又可以实现针对任一历史版本的修复。
场景3：弱管控、高发布
该类型的开发也常见于直接面向客户的互联网项目，和场景2的业务所不同的是，该场景下的业务的重要性较弱，比如一些娱乐性的产品。
场景的弱管控是指减少人工code review，取而代之的是采用源代码扫描工具进行检测，以工具检测自动化在代码提交前完成相关质量检测。基于该前提，可采用Github flow、Gitlab flow、TBD等分支模型，尤其是在团队成熟度高的情况下，可优先考虑TBD模型，将发布频率提升至极限。
场景4：弱管控、低发布
该类场景为理论场景，如现实工作中存在该场景，可采用Git flow模型。
总结
在选择分支模型中，除了业务要求对代码管控的强弱以及业务的发布频率外，往往还会遇到业务需求是否要发布、团队成熟度、研发过程自动化工具支撑程度等问题影响。
随着DevOps在企业中的普及，以产品化为思路的持续交付模型在各企业内先后建立，借助DevOps平台自动化的能力，企业可将提交检测、合并检测等工作常态化，用自动化的代码检测方式替代人工Code review，降低人工成本的同时，提升交付效率。
同时，企业可根据自身的业务特征基于上述代码分支模型，规约企业特有的分支模型，其核心思想是在满足业务、管理、效率、质量、安全的多方诉求。JNPF就是为企业数字化转型提供了一大“硬件”，方便企业在数字化转型过程中，最大限度降低企业的试错成本，提高转型效率。大家也可以前往官网www.jnpfsoft.com试用体验。
{{o.name}}
{{m.name}}