持续集成
利用更快速的反馈提高团队敏捷性。因为只有测试得够快，您前进得才能更快。
开始使用免费的 DevOps 模板
在该可自定义模板内，采用开放式工具方法开发、部署并管理应用。
Key Takeaways
Continuous integration (CI) is an Agile/DevOps practice of frequently integrating and testing code changes for fast feedback.
CI relies on automated builds and tests to protect quality and accelerate delivery.
Teams must address build failures promptly and use branching strategies to maintain code health.
Implement CI to improve code quality, reduce technical debt, and enable rapid, reliable releases.
没有什么能像团队对持续集成 (CI) 的承诺一样，建立或破坏敏捷性。这听起来可能不是好事（尤其是如果您的团队尚未接受 CI），但也有好消息。无论团队使用哪种技术，都有可能有适合其代码库的持续集成和自动化测试框架。
什么是持续集成？
持续集成是一种敏捷和 DevOps 最佳实践，可以尽可能早、尽可能频繁地将代码变更整合到资源库的主分支中并实施变更测试。理想情况下，开发人员至少每天要整合一次代码，有的还要一天整合多次。
持续集成的优势
投资 CI 可以快速获得关于代码更改的反馈。快到“几分钟内”即可获得。主要依赖手动测试的团队也许可以在几个小时内获得反馈，但实际上，全面的测试反馈要在代码更改后一天甚至几天后才能获得反馈。到那时，很多方面都已改变，由此导致错误修复如考古探险般艰难，开发人员需要挖掘好几层代码才能找出问题的根源。
这显然不够快。
通过持续构建和测试自动化来保障质量
我们有多少人下载了最新源代码，但发现其并没有编译或存在严重错误？真是太影响生产力了！
为解决这一状况，可采取一下两种实践：
持续构建：变更后立即构建项目。理想情况下，每次构建之间的增量都是一个变更集。
测试自动化：验证软件编程，以保障质量。测试可以从用户界面（稍后会详细介绍）或从后端服务层启动软件中的操作。
可以将这两种实践视为花生酱和果酱：单独品味已然很棒，一起享用味道更佳！持续集成将持续构建与测试自动化相结合，以确保在每次构建的同时还能评估代码库的质量。
请注意：要想充分实现这些优势，团队还必须有暂停开发和立即处理故障的纪律。如果任由构建在故障状态下徘徊，那么团队在编写测试和配置自动化方面所投入的精力（别误会：这是一项投资）就会付之东流。保护对 CI 的投资与保护代码库的质量其实是一回事。
持续集成中的测试：单元、API 和功能测试
CI 运行主要分为两个阶段。第一步是确保对代码编译。（或者，对于解释型语言，只需将所有部分整合到一起。）第二步是确保代码按照设计运行。最可靠的办法是通过一系列自动化测试对产品的各个级别进行验证。
单元测试
单元测试非常靠近代码中的核心组件。这些测试是保障质量的第一道防线。
优点：易于编写，运行速度快，可以紧密模拟代码库的架构。
缺点：单元测试仅验证软件的核心组件；不能反映通常涉及多个组件协同工作的用户工作流。
由于单元测试解释了代码的正确运行方式，所以开发人员可通过查看单元测试了解该代码区域的最新情况。
API 测试
好的软件都是模块化的，可在多个应用之间明确分工。API 是不同模块相互通信的端点，API 测试通过从一个模块调用另一个模块来实施验证。
优点：通常易于编写，运行速度快，并且可轻松示范应用之间的交互方式。
缺点：在代码的简单区域，API 测试可能与一些单元测试相似。
由于 API 是应用各部分之间的接口，因此在准备发布时特别有用。如果候选发布版本通过了所有 API 测试，团队就更有信心将其交付给客户。
功能测试
功能测试适用于更大范围的代码库，并可示范用户工作流。例如，在 Web 应用中，HTTPUnit 和 Selenium 均可直接与用户界面交互，以进行产品测试。
优点：更容易发现错误，因其会模拟用户操作，并测试多个组件的互操作性。
缺点：速度比单元测试更慢，有时会因为网络延迟或技术堆栈中某个地方的暂时中断而报告假阴性。
团队经常发现，因为更接近实际的用户工作流，所以自动化测试的运行速度会降低。HTTPUnit 的速度更快，因其不是一个成熟的 Web 浏览器。Selenium 在运行时只能达到 Web 浏览器的速度，但具有跨多个 Web 浏览器并行运行的优势。尽管存在这些注意事项，但功能测试仍然具有很高的价值，并且相比人工测试，可以更快提供反馈。
说到这里...
有些测试人员会将自动化测试视为一种存在性威胁。这种想法比较短视，与事实相去甚远。测试人员从繁琐的重复测试任务中解脱出来后，可以将时间花在风险分析、测试规划和培养其他技能（如学习编程）上！
快速实现持续集成
在 Atlassian，我们会激励开发人员持续创新，并确保我们的代码库正常运行。我们非常重视收紧开发人员的“内部反馈循环”，即构建变更和获得测试结果所需的时间。
运行自动化测试可以快速累积并计算出构建持续时间。一种策略是跨多个服务器或“构建代理”并行执行自动化测试。这样一来，CI 服务器实际上可以同时运行 2 个、20 个甚至 200 个测试。借助云技术，随着测试套件的增多，CPU 可以轻松扩展，以满足开发团队的需求。但 CPU 并不是无限的。完整测试代码的每个区域，但不要冗余。冗余测试会延长构建的持续时间（并浪费 CPU）。工程师们获得许可的速度越快，就能越快转至待办事项中的下一个项目。
建立分支与持续集成：天作之合！
很多团队会因为合并很痛苦而避免建立分支。不过，有了 Git 之类的版本控制新技术，建立分支与合并也都不是什么难事了。为确保主代码行（在 Git 术语中为”主线“）始终运行良好，需确保在所有开发和稳定版本分支上运行同级别的持续集成。在分支上构建传递时，团队要有信心在上游合并代码。
借助分支、持续集成和测试自动化，团队可在保障代码质量的同时提高工作效率和创新精神。如果您已准备好采取后续步骤，请查阅我们的 CI 入门分步指南。
敏捷开发可实现的最佳效果为：定期交付工作软件，尽量减少技术债务，同时又不影响独创性。