敏捷中的自动化

IT 中的自动化可以定义为一组程序/步骤，这些程序/步骤可以独立执行以实现所需的功能，并导致减少人工工作并提高代码质量。自动化重复程序可以为使用敏捷方法执行的项目提供真正的价值。

自动化是保持敏捷性的重要组成部分，它是整个团队的重中之重，正如已定义的实践/学科和对持续改进的承诺所看到的那样。自动化以多种方式使用，包括持续集成/构建、单元、功能和集成测试，以及持续/自动化部署。

通过减少人工工作，软件设计和测试的自动化消除了与人为错误相关的风险。它使开发人员和测试人员免于重复性活动，并使他们能够专注于系统质量的更关键方面，从而提高构建和测试效率以及运营效率。构建和测试自动化还确保了可重用性和可扩展性，进而转化为显着的成本节约。

自动化可以发挥重要作用的一些领域是：

• 代码构建和部署
• 单元测试执行
• 生成代码覆盖率报告
• 功能和性能测试执行
• 生成代码质量指标报告
• 生成编码约定报告

确定流程后，建议团队调查如何自动化流程并确定可以帮助自动化的工具。此外，团队需要根据手动程序的总成本和风险来估计实施自动化所需的工作量。在大多数情况下，决策归结为成本与收益分析。该模块涵盖了自动化的总体概念以及可以在敏捷项目中与相关工具一起实施自动化的领域。

关键概念：

遵循敏捷方法的关键原则和好处之一是更快的反馈。此反馈包括来自客户、产品负责人和交付团队成员的反馈。通常使用“快速失败”一词来强调最好早点失败，以便可以根据反馈纠正障碍。

敏捷项目通常会有更短的发布周期，以便获得客户的早期反馈。尽管交付的功能较少，但交付正确的功能更为重要。从交付的角度来看，团队（开发人员和测试人员）应该能够更快地交付是很重要的。任何重复的手动任务都必须自动化。这将释放团队成员在这些重复性任务上花费的时间，并专注于为用户提供更多价值（可能是另一回事）。

涉及多个分支机构和多个项目的典型企业应用程序开发和部署过程的复杂性为组织增加了巨大的成本开销和风险。

下面列出了在这些情况下使用自动化的一些好处：

S.No.	Typical Manual process	Automated process
01.	A tight control is needed on individual components for monitoring the overall process	A Transparent process as the progress on all components are more visible and risks can be identified more easily
02.	Higher repetitive efforts during deployment	Reduced efforts during deployment
03.	The Risk of manual execution error is high	Once standardized, the errors are avoided
04.	Could run into quality issues	Once standardized, a high level of quality is maintained
05.	Inconsistent results as the process are dependent on the persons involved	It gives standard results always.

一些典型的现实生活实例：

• 场景 1：开发人员应该对现有功能进行更改。完成开发后，开发人员必须测试所做的更改。现在，如果没有现有的单元测试用例，开发人员必须再次对整个功能执行单元测试。这反过来会增加更改所需的时间。如果使用 x Unit 通过各种单元测试框架自动化测试用例，则可以快速运行测试用例并立即进行验证。开发人员可以只专注于测试更改并围绕这些更改创建单元测试用例。
• 场景 2：在完成单元和集成测试后，开发人员必须推动对 QA/测试环境的更改，以供 QA 团队进一步测试。如果升级到 QA 环境涉及对基础架构团队的多个请求和几个小时的延迟，这将造成瓶颈。这将成为整个团队的障碍，因为可能有多个故事需要提升到 QA 环境。

敏捷中自动化的使用：

1. 开发中的自动化：

• 单元测试套件：单元测试是持续集成的基本构建块之一。开发人员可以将他们的一系列测试作为简单的单元测试自动化，并与他们的版本化代码库一起提供。这些测试应该是实时测试套件，即它们应该在任何时间点运行到成功。每当更改代码模块时，也应更新相应的单元测试并确保通过测试用例。自动化单元测试是第一道防线，也是“快速失败”方法的关键部分。可用的各种单元测试框架包括 - JUnit（用于Java）、NUnit（用于 DotNet）、utPlSql（用于 Oracle PL/SQL）。
• 代码质量分析：需要执行静态代码分析来识别和量化代码质量指标，例如标准、安全风险和对最佳实践的遵守情况。作为开发实践的一部分，应该运行代码质量检查。只有在达到令人满意的质量指标后，才应将代码检查到版本控制工具中。静态代码分析的一些关键工具是 CAST、SONAR。请注意，开发人员可以利用这些工具的 IDE（集成开发环境）集成功能将静态代码分析集成到他们的开发过程中。

2. 构建自动化：

持续集成 (CI)：实践持续集成的目的是维护一个能够生成“生产就绪”构建的构建环境。作为这种做法的一部分，将执行以下操作：

• 分析代码的质量
• 构建代码
• 执行单元测试用例
• 上传构建工件
• 构建后和测试结果
• 用结果提醒团队

这可以通过自动化有效地实现。有关 CI 实践的更多详细信息，请参阅本课程“持续集成和相关工具”的学习资料。

为了帮助这种做法，需要以下支持系统：

• 源代码版本控制工具：通过“挂钩”（当有新的代码更改时主动通知其他工具）或“轮询”（其他工具必须轮询版本控制工具以确定是否进行了新的代码更改），任何新的代码更改都应该由版本控制工具确定并传达给其他工具。示例——Git、ClearCase、SVN
• 构建工具：一个强大的工具/框架，有助于更轻松地维护和代码构建。示例 – Maven、ANT。
• 静态代码分析工具：如上节所述，这些工具用于检查代码质量。示例 – CAST、SONAR。
• 构建存储库：一个强大的存储库，用于维护可以轻松上传/下载/搜索的构建。示例 – Nexus（用于 Maven 构建）
• CI 服务器：与上述所有组件交互并执行应用程序的实际构建以及自动或只需单击按钮即可执行测试。示例——Jenkins、哈德森。

3. 部署自动化：

持续部署 (CD)：成熟的敏捷团队扩展了持续集成实践，因此应用程序也可以自动并定期部署到多个环境中（实际上是较低的环境，如 DEV 和 QA）。这是维护“生产可部署”构建所必需的。作为此过程的一部分，还将验证任何部署问题。这称为持续部署。

典型的 CD 流程包括：

• 所有持续集成步骤
• 部署到所需的环境
• 执行冒烟测试
• 发布部署结果
• 用结果提醒团队

通常，企业应用程序将遵循包含多种技术的多层架构（例如 - 带有 Oracle 后端的 J2EE 应用程序）。因此，为了在多层架构中实现部署自动化，应该有一个自动化的编排。

对于自动化部署，交付团队可以有一个自定义脚本或使用像 uDeploy 这样的自动化框架。像Jenkins/Hudson 这样的 CI 构建服务器也可以配置为执行 CD 活动。

4. 测试自动化：

由于敏捷方法的性质，迭代开发的软件将作为系统集成测试或回归测试的一部分进行多次测试。因此，必须尽可能地自动化测试执行。有各种可用的测试自动化框架，如Cucumber、FitNesse、QTP 等，可帮助编写和执行测试用例。建议从 Sprint 执行开始就与用户故事开发并行创建自动化测试用例。

一旦测试用例被自动化，它们可以被安排为构建服务器的一部分以自动触发。这将确保测试经常运行并尽早报告故障。以下是可以自动化的各个阶段：

• 冒烟测试
• 系统测试
• 回归测试
• 验收测试

新兴趋势：

今天，自动化是技术组织的一个令人兴奋的重点领域，并且其中出现了许多技术和工具。

• LiquiBase：这是一个跟踪对数据库所做更改的工具。对数据库的更改以 XML 形式维护。这有助于后续的更改回滚或将一个环境中的更改应用于另一个环境。这可用于为单元测试用例创建/回滚测试数据或将更改从 DEV 环境移动到更高的环境。
• Chef：这是一个自动化基础设施部署和管理的工具。使用此工具，基础设施被视为与应用程序代码类似的版本化、可测试和可重复。

自动化的挑战：

在敏捷项目中实施自动化存在许多障碍。这些是：

• 来自产品负责人的压力：产品负责人希望推出他们的工作产品，并且可能不愿意让团队将时间花在可能长期受益的自动化框架上。所有利益相关者都必须对自动化的好处充满信心。投资回报率 (ROI) 可以根据自动化的采用进行计算并用于表达。
• 自动化脚本的维护：自动化脚本与生产代码一起得到很好的维护是很重要的。向团队提供足够的支持，以确保自动化脚本维护的更改与业务优先级一起被采用。随着自动化测试总数的增加，构建和执行测试所花费的时间往往会增加。团队应决定与构建一起执行的测试的优先级，并确保尽可能对自动化脚本进行必要的重构以进行改进。
• 缺乏跟进：尽管交付团队在开发过程的早期就采用了最佳实践，但团队可能会忽视愿景，并可能在自动化活动上妥协。交付负责人或团队的任何成员应不断提醒团队，以防出现任何偏差。
• 敏捷成熟度：开发团队可能有优先考虑代码而不是自动化脚本或框架的心理构成。团队应该接受适当的培训，并在开发过程中灌输创建自动化测试的实践，以实现应用程序的可持续维护。
• 自动化的时机：在项目快结束时自动化构建过程，几乎没有什么好处。但是，一旦开发/测试开始，自动化就可以节省数十甚至数百小时。