进入BB 之前，总以为自己持续集成已经大牛了，毕竟经过百度、七牛。可是进入BB之后，才发现自己小巫见大巫、井底之蛙了。以前总说百度的qa自动化多么多么牛逼，反正没用过jenkinsfile，所以还是质疑了一下，是百度落伍还是BB落后？（主要是一直被灌输的思想这家公司很老牌，东西技术都很陈旧），交流过后，觉得jenkinsfile 相较Jenkins UI 是对pipeline更深层次的理解。
一句话更自动化。进入外企，发现老美做事慢，但确实有深度、严谨。学习~~ 以下是我的mentor给我的解释，很专业有木有 thanks a lot Fred A few reasons:
We can manage configuration via Git and have a history of changes. easy for new projects to copy and get started. more visible than Web UI - bundled with project for all to seecan use powerful groovy tools more easily than in UIand as you said easier to import to any JenkinsPerhaps most importantly it generates jobs for each feature branchNo manual workjenkins UI适用于小团队、产品初期 jenkins file 才能反应到pipeline的精髓 ，适用于复杂产品、产品稳定期。 也确实国内的互联网，最久的BAT也才十几年，每个产品更是更新换代飞速，从我的经历，在BAIDU 两年多的时间，经历了两个产品，都是在做1.0 。而现在BB的learn 已经9.1了，所以适者生存，确切的也不能算是进步，而是不同产品阶段采用不同技术去服务产品。对于个人，学习到深层次的技术终究不是坏事。
一，触发方式 1，scm（bitbucket/github）主动触发pipeline，pipeline被动触发 2， pipeline配置主动定时扫描SCM 每个repo的每个分支代码变更，timestampt plugin 定时器触发 二，运行流程（以2为例，定时间隔 1min，scm-bitbucket） 1，定时器每隔1min触发pipeline job运行 2，pipeline job将根据自身配置的过滤条件（也可能没有），check 配置的repo中符合条件的 所有分支的changelog（即git log 中commit的 “SHA-1 校验和 ”字段），发现哪个分支changelog变化，则触发哪个分支的job rebuild or new create。 Git changelog机制—每次 git commit操作都会在changelog中生成一个唯一的 ”SHA-1校验和“ 值 3，有变化的分支对应的独立job执行，返回结果给scm, 决定新的变更code是否能被merge
三，pipeline理论tips 1，所以每个jenkinsfile 应该是属于每个分支的属性。 2，每个分支对应一个独立job ，在job的日志中可以看到 整个 jenkinsfile中描述的所有脚本执行过程。 3，每个pipeline对应一个pipeline job，pipeline job日志中只有扫描changelog的信息。 4，每次pipeline job运行，只触发 有代码变更的分支job 运行或新建。
—————— [1].http://blog.csdn.net/gw569453350game/article/details/51911179
