持续集成的几条实践原则

搭 Jenkins 流水线之前,先理清持续集成到底要解决什么。这几条是反复验证过的老规矩,顺序大致也是落地优先级。

让构建自带测试

传统意义的「构建」就是编译、链接,把程序弄到能跑。但能跑不等于做对了事。静态类型语言能拦住一部分 bug,漏网的更多。把自动化测试塞进构建过程,是更快抓 bug 的办法——测试不完美,但能抓住的那部分已经够有用了。

每天都往主干提交

集成的本质是沟通:让其他人知道你改了什么。提交频繁,大家就能尽早感知到变化在往哪个方向走;攒一大坨再合,冲突和惊吓都是成倍的。

保持构建够快

持续集成的全部意义是快速反馈。最拖后腿的就是一次构建要等很久——反馈慢了,这套机制的价值就被抽干了。

每次提交都在集成机上构建主干

要保证主干会在专门的集成机上定期构建,只有这次集成构建通过,这次提交才算真正完成。提交的人有责任盯着主干构建,挂了就去修。推论是:别在主干构建通过前下班,尤其是临下班才提的那批改动。

构建挂了立刻修

主干构建一挂就得马上修。持续集成的前提是你始终在一个已知稳定的基线上开发。主干偶尔挂不是坏事;但如果总挂,说明提交前大家没认真在本地更新+构建。一旦挂了,最重要的是尽快修好,而不是放着让别人踩。