[持续交付实践] pipeline使用：Multibranch Pipeline

前言

在探讨multiBranch Pipeline以前，颇有必要先探讨下如何制定有效的代码分支管理规范，使用高效的版本控制系统，并对构建产物及其依赖进行管理。
咱们首先要强调，须要进行版本控制的不只是源代码，还有测试代码、数据库脚本、构建和部署脚本、依赖的库文件等，而且对构建产物的版本控制也一样重要。只有这些内容都归入版本控制了，才可以确保全部的开发、测试、运维活动可以正常开展，系统可以被完整的搭建。
制定有效的分支管理策略对达成持续交付的目标很是重要。看过《持续交付》这本书的同窗都知道，持续交付建议的方式是基于主干的开发（Trunk Based Development，TBD）模式，全部开发者在主干上频繁的提交代码，而后经过持续集成的机制，对修改触发快速的自动化验证和反馈，Google就在坚持使用主干开发模式，全部人的全部更改直接提交到Trunk上。那持续交付为何这样建议呢，实际应用中又是否可以适用？

常见分支管理策略

1.基于主干的开发
前面已经介绍过了《持续交付》更倾向使用基于主干的开发模式，全部项目成员把代码都提交到主干上，提交后自动触发持续集成进行验证和快速反馈，经过频繁的集成和验证，在保证质量的同时提高效率。主干开发模式很是强调代码提交习惯，包括频繁、有规律的代码提交（好比每人天天提交一次），而提交前须要进行充分的本地验证和预测试，以保证提交质量，下降污染主干代码的几率。

 

优势：
相比于分支开发，主干开发模式有不少优点。首先是代码提交到主干，能够作到真正的持续集成，在冲突造成的早期发现和解决问题，避免后期的”合并地狱”，这样的总体成本才是最低的。
对持续集成来讲，具体实施也将会变的很是简单，只须要维护一条pipeline交付流水线，在有新代码提交后，经过git的hook机制，当有新代码提交的时候就会触发pipeline的执行并反馈结果，若是有问题代码提交人员必需要实时去解决。
难点：
主干开发模式有不少优点，但具体实施过程当中会发现，当一个项目开发者多了之后，若是没有强力的制度约束和相关意识，推进起来会碰到很多的困难，好比：

 

• 主干上功能开发完成时间有先有后，若是遇到有未完成的功能但又须要发布时，就须要一种方法屏蔽掉未完成功能，才能进行安全的发布；
• 主干上功能开发完成后，若是须要比较长的时间进行验收测试，那么此时为了确保发布功能的稳定性且全部功能是通过验证的，可能会限制新功能的提交，有的团队采用的封版、冻结主干的作法就是这种状况，这样的确会影响开发效率；
• 若是修改的功能很是复杂，或者要进行架构上的大范围重构，以上问题就更加明显和难以解决了；
• 若是团队规模比较大，同时工做在主干上的开发人员比较多，那么冲突的几率会比较大，持续集成的失败率可能比较高； 这些问题并非无解，好比经过功能拆解合理规划需求进行增量开发；经过配置隐藏未完成功能；以微服务的思想对大的架构进行拆分组件，每一个组件独立开发和部署等。前提是咱们的系统要有良好的架构设计，以及咱们的开发者要有良好编码协做习惯。

2.基于分支的开发

 

这正是不少团队常常默认使用的模式，具体表现为接到需求后拉出分支，后面的开发都在分支上提交，每一个分支生命周期较长，而且可能有多个并行分支，直到快要上线时或者上线后才合并到主干。
优势：
多个功能能够彻底并行开发，互不干扰。还能够按每一个功能特性拉出分支，那么每次提交都是完整的功能特性，分支划分明确、版本控制的记录也会比较清晰易懂。而且因为不一样需求的开发进度不一样，能够选择某个先开发完成的功能特性进行合并、发布，而不会被其它分支上未完成的功能特性阻塞。
缺点：
引用电影《无间道》中的一句话，“出来混，总有一天要还的”，由于虽然使用分支暂时隔离了不一样功能的代码，但系统的多个功能或者多个组成部分最终仍是要集成在一块儿工做的。若是不一样分支代码之间有交互，合并时可能会有大量冲突须要解决。
在实际项目中，进行代码合并时一般很容易出错，解决冲突也很是耗时，特别是到代码合并时基本都已经到了项目后期，常常出现合并错误甚至遗漏合并的问题，对于QA来讲，每一个分支经过测试后，合并代码之后又须要系统的从新测试一次，工做量巨大不说还很容易致使一些合并形成的bug遗漏到线上，经历过的同窗都能体会倒这种方式的痛苦。
对于持续交付来讲，每条分支咱们都须要搭建一条完整的pipeline与之对应，这意味着须要更多的部署环境和更多的重复测试，在合并代码后全部的过程还须要从新来一遍以免各类代码合并错误。

 

3.权衡和建议
在某些状况下，有时无可奈何要采用分支开发的模式，好比并行需求太多且相互干扰，好比开发团队的习惯没法驱动改变，拉出分支其实意味着已经在持续集成/持续交付上作出了妥协，那么咱们建议至少要使用一些折中的方案。

• 尽可能缩短分支的周期，最长也不要超过迭代周期；
• 每一个分支上运行单独的测试流水线，保证质量。虽然这种方式浪费资源，并且其实也没进行”真正的“集成；
• 分支只与主干合并代码，分支彼此之间尽可能不作合并；
• 分支按期合并主干上的变动 具体到Jenkins Pipeline的实施，我的认为主干开发模式，或者分支比较少的分支开发模式，原来的普通pipeline模式已经足够。但若是是并行分支比较多的分支开发模式，以我的实践经验，单条pipeline使用时冲突会变的比较严重，虽然pipeline也能够经过参数化的方式去适配多个分支使用，但这种方式的缺点是每一个分支的结果可视化会变的比较糟糕，这种状况下咱们更推荐使用MultiBranch Pipeline。

MultiBranch Pipeline

前面啰嗦了这么多，终于到了重点要介绍的multiBranch Pipeline部份内容，但理解持续交付的分支管理策略确实对咱们pipeline的具体使用很是重要。
以前已经介绍过了，Pipeline as Code是2.0的精髓所在。multiBranch Pipeline的使用首先须要在每一个分支代码的根目录下存放Jenkinsfile（Pipeline的定义文件），咱们能够理解下maven的pom.xml文件，Jenkinsfile做为pipeline的管理文件也须要在源代码中进行直接的配置管理。这就要求devops工程师（QA、运维等）首先要有代码库的权限，或者至少赋能给dev工程师jenkinsfile的设计能力。
1.新建multibranch pipeline job
对代码地址和jenkinsfile路径进行配置以下

 

2.自动为每一个branch生成job
在multibranch pipeline job保存后，jenkins自动地检查全部的branch，且自动地为全部的branch建立job,固然前提是存在jenkinsfile文件
例如上面的job，自动地生成了文件夹pipeline_expertPatient_multiBranch，且在此文件夹下自动地为trunk和branch生成了job。若是在代码库上某个branch分支被删除，multibranch pipeline也会自动检测变化并删除相应的job。

 

3.Scan Multibranch Pipeline Now
第一次生成Multibranch Pipeline时，会自动扫描pipeline配置文件并创建相应的job,后续若是jenkinsfile文件有变动，也能够手动触发扫描，日志输出以下

 

这样一个完整的MultiBranch Pipeline就创建完成，你能够根据不一样的分支定制不一样的pipeline策略，固然也能够采用参数化的方式使用通用的jenkinsfile文件。

 

结语

MultiBranch Pipeline能够理解为是针对某个工程全部分支代码的pipeline集合，jenkins会自动发现源代码中的jenkinsfile配置文件生成对应的分支job。而MultiBranch Pipeline要求jenkinsfile配置文件存放在源代码的方式，也是符合Pipeline as Code的理念。虽然这也会给一些没有代码提交权限的devops工程师带来困扰。