敏捷开发中的持续集成应该如何做？

　　在过去十年或更长的时间中，软件开发团队一直受益于敏捷开发方法。他们采用这些迭代和增量开发实践，通过协作式开发推动解决方案的发展。传统的、非敏捷的软件创建方法通常依赖于一个更严格管制的开发流。瀑布流程就是这方面的一个示例，其中需求、设计、开发和测试的每个活动都是连续执行的。

　　虽然瀑布式开发多年来一直是大型的复杂系统开发的标准，但它有几个明显的缺陷。首先，即使需求会随时间而变化是众所周知的，但开发人员仍会努力在设计前完成文档，在编写代码前完成设计，其中有大量工作被浪费。另一个缺陷是，将测试和集成一直延迟到项目结束时才执行，问题往往发现得太晚，如果要解决问题，则有可能导致错过最后期限。这两个因素结合起来，在以较慢速度发展的世界中，也许可以容忍。但是，随着创建创新系统的压力的增加，这种方法的满足组织需求的能力在下降。

　　虽然敏捷实践是由开发 IT 系统的团队推广的，但它们同样适用于产品开发，其中的产品包括硬件、电子和软件。嵌入式软件开发与 IT 应用程序开发的主要区别在于部署目标资源(如处理器性能和内存)的有限可用性。嵌入式软件往往要在这些约束条件中执行复杂的实时操作。想像一下计算机控制的系统，例如汽车里的安全气囊。您需要他们立即部署，但需要的是可靠的部署。敏捷方法最初专为不受管制的行业中的在同一地点工作的较小型项目团队而设计。我们花了很多年对它们进行扩展，使敏捷方法可以容纳更大、更复杂的开发项目。

　　当应用为基于架构的方法的一部分时，持续集成(CI)和测试驱动的开发(TDD)扩展了基本敏捷实践，使之足以同时提供高品质和项目灵活性。本文将探讨在嵌入式软件开发的上下文中如何采用敏捷方法、CI、TDD。本文还说明了这个组合的好处。

　　如何将持续集成和测试驱动的开发融入敏捷实践中

　　现在，大多数人可能都已经听说过敏捷方法。它们带给软件开发的概念改变了团队组织的工作方式、适应不断变化的需求的方式以及发布软件的方式。持续集成(CI)是为敏捷开发而创建的，所以敏捷方法是任何 CI 讨论的背景。它将开发组织为功能性用户故事(user story)。这些故事按优先级分成较小的工作组，也称为冲刺(sprint)。

　　这里的思路是不要提前尝试解决每一个问题，相反，专注于您已经知道的东西。因此，团队设计、构建和测试他们对预期功能所知道的内容。这将在完整产品需求的一个子集的基础上创建一个工作产品。然后，团队继续到下一个最高优先级的需求集，并重复上述过程。当然，这是一个高度简化的视图，这个过程中有许多变化，但核心是：以增量方式构建您的产品，并尝试在过程中做一些改进。

　　根据 ThoughtWorks 的 Martin Fowler 的观点，持续集成(continuous integration)是一种软件开发实践，要求团队成员经常集成他们的工作。每个人至少每天集成一次，这导致每天有多个集成。集成是通过自动化的构建进行验证的，这些构建运行回归测试，以尽快检测集成错误。团队发现，这种方法会导致集成问题大幅减少，更快地实现有凝聚力的软件开发。

　　这导致 CI 流程的成功执行的最终细节。如果持续集成的思路是为了快速发现问题，从而向每个开发人员提供工作反馈，则必须以某种方式快速评估其工作。测试驱动的开发填补了这项空白。利用 TDD，您可以构建测试，然后等代码通过测试后再开发功能。随着每一个新代码的添加，可以将它的测试添加到在构建集成工作时运行的测试套件中。这将确保新增内容不会破坏之前出现的运作中的工作，并且事实上 “破坏了构建” 的代码的开发人员可以迅速获得通知。在图 1 中显示了持续集成和测试驱动的开发的典型组合。

　　图 1. 使用持续集成和测试驱动开发的敏捷实践

　　回页首

　　受益于持续集成的项目类型

　　少于 50 人，处理不太复杂的项目的团队绝对是敏捷开发和 CI 的试验场。但因为产品已变得 “更智能”，其复杂性也会明显增加。

　　进入传统产品的嵌入式软件的数量是惊人的。如今，一辆新汽车已较少以其马力作为卖点，而是以其嵌入式软件技术(例如，自动泊车、先进的安全警告、燃油效率、信息娱乐系统)作为卖点。为创建一辆新汽车而编写的代码行数多于为 F16 战斗机所编写的代码行数。

　　产品复杂性的增加，同时加速了新产品的上市时间。嵌入式软件的普及，结合更严格的最后期限，这些将敏捷实践和 CI 带到了嵌入式开发人员的面前。

　　回页首

　　使用敏捷方法实现嵌入式系统开发

　　敏捷方法让软件和系统团队能够快速响应变化。敏捷方法减少了与传统的软件工程相关联的时间进度风险，在传统方法中，组件的集成被视为后期阶段的工作。后期阶段的集成会引起对设计规范的误解，在发现问题时，对于要解决该问题同时又要满足其最后期限的团队而言，已经为时已晚。

　　然而，系统团队要生成的不仅仅是软件组件，他们对敏捷方法的某些方面持怀疑态度。他们说，删除过多的早期规划，最后就会获得糟糕的软件和硬件集成。如果没有早期的、经常的检查点来根据架构蓝图验证进度，团队可能无法生成可在更广泛的系统中正常运作的组件。此外，对于正在寻求设计的可重用性和可扩展至较大型项目需求的复杂系统的开发人员来说，敏捷方法看起来可能存在局限性。

　　这些担心是可以理解的，因为建模和架构不是敏捷技术的特点。但系统开发的 CI 方法对纯敏捷方法提供了多项改进。CI 帮助系统开发团队变得敏捷，并且能够响应快速的业务变化，在同一时间确保正在开发的实际硬件和软件都在不断同步。CI 使得团队成员能够在自己的领域组中有效地工作，集中精力于他们最擅长的任务。在每天结束时，他们知道，他们对项目的贡献被集成，并且各组件可以一起工作。如果有哪个组件无法集成，该组件很快就会被发现。

　　让我们来考虑复杂系统开发和交付的一些必不可少的组成部分，并探讨 CI 如何有助于迎接挑战。

　　架构

　　当您正在构建复杂系统时，如果没有蓝图，就无法不断添加新的特性。如果没有蓝图，那么在利用额外的迭代时，就会遭遇更多返工的情况。不管您将它称为蓝图、模型还是架构，它都提供一个开始迭代过程的坚实基础。

原文转自：http://www.ibm.com/developerworks/cn/rational/continuous-integration-agile-development/