持续集成与自动测试和敏捷开发的关系

持续集成的原因和价值在于：从应用开发的角度而言，因为在项目开始时需求是不明确的，或者说什么是当前的环境、背景（业务人员、企业资源、业务流程及其可变更性、组织结构及其可变更性、业务诉求、战略期许、信息技术系统资源等决定的）所能最终确定的业务模型、系统逻辑模型、领域模型，是不可能直接得到最合理、精化的成果的。因而要在后续的开发、试错、复盘中不断的改善，而这种行为一般不可能是一个单独的自然人完成，而是由一个或者多个团队来构成，因此，必然面对模型（及其实现）在“完善”“修复”过程中，所可能承受的负面效应，也就是新模型（及其实现）的错误、或者修改带来的没有预期到的连锁反应，以及分支版本问题等等。因而，最合理的做法就是及时提交、高频率合并，及时测试来发现问题，固定有效版本（基线），并且在找不到问题原因、没有办法及时解决的时候够回退、回溯。

其中，测试，需要用自动测试来保证效率，说白了，就是替代原来一般手段的单纯的端到端手动回归测试。只有尽量大概率覆盖的自动测试，才能确保及时的、底成本的发现持续集成可能带来的问题。降低持续集成的成本，使得高频的持续集成成为实践中的可能，而不仅仅是理想。

而持续集成，也给了敏捷开发以手段和条件。使得不断复盘，找当下低风险主要矛盾以驱动项目工作的逻辑可以在有限的时间内（每个冲刺期），低成本的不断落地。动不动就卡住、慢速的、磕磕绊绊的集成，将使得敏捷开发文化所讲究的冲刺成为笑话，将项目团队的精力消耗殆尽。