持续集成简介与落地阶段

持续集成能帮助你不破坏构建，在你的同事发现你的错误之前捕捉到错误。即使搭建一个基本的持续集成，也能为你的团队的流程改进起到积极的作用。持续集成是现代软件开发技术的基础。它从根本上改变一个团队对于整个软件开发过程的思考方式，启动和触发一系列增量式的过程改进，从简单的、有计划的、自动化的构建逐渐改进为可以持续交付投入生产中。一个好的持续集成基础设施可以简化开发过程直至部署，可以帮助开发人员更快地检测和修复缺陷，为所有开发和非开发人员提供一个有用的项目仪表盘，最后帮助团队交付更真实的业务价值给最终用户。

在持续集成之前那些充满瀑布和甘特图的日子里，开发团队的时间和精力都花在发布一个版本之前的那段时间里，也就是所谓的集成阶段。有时甚至仅集成一些有冲突的变更都会消耗数月之久的时间。不仅很难预期会突然出现什么类型的问题，更难的是去修复它们，因为它会使你不得不去重写之前写了几周甚至几个月的代码。这个过程不仅痛苦，而且充满了风险和危险，且往往会导致延迟交付、额外开销的后果，最终引来客户的不满。持续集成的出现就是为了定位和解决这些问题

持续集成，就其简单的形式来说，就是一个能监控你版本控制系统变化的工具。无论任何时候，只要检测到有变化，这个工具就会自动编译和测试你的应用程序。如果出现问题，它马上通知开发人员，以便他们能立即着手解决这个问题。

持续集成能密切监视你代码库的健康，自动监控代码质量和代码覆盖率度量，帮助你降低技术债务和减少维护成本。这些公开可见的代码质量度量可以使得开发人员为自己开发的高质量代码而自豪，并且激励他们继续努力去改善。结合自动化的端到端的验收测试，持续集成也可以作为一种沟通工具，清晰地发布与展现总体开发工作的当前状态。通过构建自动化部署过程，持续集成能大大简化和加速你的交付过程，自动化和一键部署应用程序的最新版本。

持续集成是通过提供更快的反馈来降低风险的。它被设计成能更快地识别和修复集成和回归相关的问题。通过更好地为技术和非技术团队提供项目状态的可视化，
持续集成打开并改善了团队成员间的沟通渠道，同时鼓励他们协作解决问题和过程改进。

持续集成，特别是持续部署和持续交付，就是为了更快地给最终用户提供价值。你的团队从一个小的代码改动到投入生产需要多长时间?这个过程涉及到多少个可以提早修复的问题?你了解任何一个团队成员作出的代码修改吗?会让劳动密集型的手工测试团队花费多少时间?会涉及到多少个手工部署的步骤?持续集成可以帮助你简化这些问题。

持续集成也是一种思维工具。你的项目必须有一个可靠的、可重复的、自动化的构建过程，并且不涉及人工干预。要保证先修复有问题的构建，而不是不管不顾。部署过程应当是自动化的，不应当有任何人工的干预。团队需要设计强健的、高质量的测试。

把持续集成引进一个公司需要几个不同的发展阶段。这些阶段涉及对技术基础设施的不断改善，更重要的是对开发团队本身的相关实践和团队文化的改善。

阶段1:无构建服务器。软件是在开发人员的机器上手工触发构建的。源代码可能存储在一个中央代码库，但开发人员无需定期提交代码。在计划发布一个新版本之前的那段时间里，开发人员手工集成他们的代码改动，这个过程异常痛苦。

阶段2:夜间构建。团队有一个构建部署，并且会每晚定期触发自动化构建过程。这种构建只是简单的代码编译，没有可靠的可重复的单元测试。自动化测试也不是强制作为构建过程的一部分。开发人员每天结束前定期提交代码。假如有代码冲突，构建服务器会在第二天早上通过邮件向团队发送报警。但问题不一定会被立即修复。

阶段3:夜间构建加自动化测试。团队开始认真对待持续集成和自动化测试。无论何时，只要有代码更新提交到版本控制系统，构建服务器就会触发一个构建。团队成员可以轻易地看到是哪些代码触发了这个特定的构建。构建运行脚本去编译应用程序并运行一系列的自动化单元测试和集成测试。运行失败的构建可以很快得到修复。

阶段4:加入度量指标。构建中会运行自动化的代码质量和代码覆盖率检查，来评估代码库的质量和测试的相关性与有效性。团队会建立构建展示器，可以放在屏幕的一个突出位置让所有团队成员看到。

阶段5:更认真地对待测试。如果构建阶段测试通过了的话，它会被自动部署到一个应用服务器上进行更全面的端到端测试和性能测试。

阶段6:自动化验收测试和自动化部署。这个阶段的开发工作是由验收测试驱动的。用非开发人员都能理解的业务术语发布测试结果报告。

阶段7:持续部署。团队对于自动化的单元、集成和验收测试已经非常有信心了，完成上述步骤后直接推送到生产中。

​