持续集成利器-pipeline(一)

进入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 see
• can use powerful groovy tools more easily than in UI
• and as you said easier to import to any Jenkins
• Perhaps most importantly it generates jobs for each feature branch
• No manual work

jenkins UI适用于小团队、产品初期
jenkins file 才能反应到pipeline的精髓 ，适用于复杂产品、产品稳定期。
也确实国内的互联网，最久的BAT也才十几年，每个产品更是更新换代飞速，从我的经历，在BAIDU 两年多的时间，经历了两个产品，都是在做1.0 。而现在BB的learn 已经9.1了，所以适者生存，确切的也不能算是进步，而是不同产品阶段采用不同技术去服务产品。对于个人，学习到深层次的技术终究不是坏事。

PIPELINE -通过实验总结

一，触发方式
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