devops [DevTestOps]-持续集成和持续交付的方式 (CI/CD)

rocl · 2018年01月03日 · 2792 次阅读

在过去的十年中, 竞争不断发展, 需要更快的进入市场, 更好的客户体验和不断的进化。随着现代软件经济逐渐偏向于不断加快市场需求的创新产品, 技术主导产品吸引了早期的使用者和小众市场, 他们寻求最新的技术发展。由于这一点, 许多公司采取了第一次失败和快速的态度, 作为他们的软件开发过程的一部分。因此, 瀑布模型让位给敏捷能让项目在任何阶段包含迭代获得快速周转时间

连续的反馈和连续的迭代催生了持续集成和持续交付。利用 CI\CD 主导的流程, 公司施加了影响力。

  • 更短的研发周期
  • 更快的发布周期
  • 在每个阶段持续的反馈
  • 频繁发布
  • 加快上市时间

虽然开发和 Ops 是产品开发过程的关键阶段, 但另一个重要阶段是测试。此前, 公司为每个功能开发和变更创建了手动测试套件, 以防出现错误。这花了大约 5-6 天, 随着情况发生变化, 在一个特定特征的开发之后, 它将被集成入构建。测试是在一侧完成的, 而且一旦完成, 测试人员就会快速地将交付交给 Ops 团队部署到生产。

DevTestOps-是什么?

随着 CI/CD 的持续使用,另一个称为持续验证的迭代阶段出现了。本阶段的重点是将自动化测试套件作为软件交付 Pipeline 的一部分执行, 以获得有关软件发布的漏洞、bugs 和风险的即时反馈, 以及它是否是一个很棒的产品。这意味着在开发过程的所有可能阶段进行测试, 评估风险并记录软件的反馈。连续测试集成了测试代码的连续能力, 这意味着弥合测试团队、开发团队和运维团队之间的差距。DevTestOps 是关键的一个成功的 CI 交付模式。

持续集成: 在软件产品开发和交付方面, 持续集成是一个被广泛采用的模型, 其主要目的是最大限度地减少集成时间以加快上市速度。它可以更快地交付高质量的软件, 但是, 如果没有运行速度快, 有良好的覆盖率,没有错误的结果的自动测试,它的放大的影响无法实现, 也不可能有成功的持续集成或持续发布。

持续测试\验证: 连续测试集成了自动化测试套件, 在大多数情况下是全面和回归测试, 并为每个功能生成自动化程度的报告。在成功的情况下, 该范围报告可以进一步集成并验证成功的构建。在其他情况下, 它会显示出漏洞\错误或缺陷, 并帮助确定生成的功能是否存在阻断。在每个检查点的自动反馈的作用是自动触发传递 Pipeline 中的下一个步骤, 以便在反馈向前移动时启动。如果反馈不向前移动, 则会立即暂停开发, 采取纠正措施, 然后进行开发。连续集成 (CI) 工具, 如Jenkins(在成功构建完成后执行自动测试), 可以集成自动化单元、回归和功能测试, 以便为每个成功的构建运行。

当某个功能成功添加到编译时, 它们的检查将作为该范围报告的一部分添加到测试自动化套件中。

持续交付: 它的目标是通过利用自动化的方法将成功的构建交付到预先的目标环境中 (如 QA、UAT 和生产)。部署可以预先配置为预定义的时间或按需进行, 作为敏捷交付的最佳实践。

为什么持续测试在 DevTestOps 中很重要?

连续测试通过降低资源调配成本和简化测试环境创建过程来减少瓶颈。实施连续测试也有助于开发平衡质量和速度。它为操作提供了很大的价值, 使它们能够直观地显示所创建的环境功能, 以及它们将如何支持应用程序, 从而使团队需要进行必要的更改。在早期阶段, 软件产品对生产类环境是可见的, 最好是在开发过程开始时使用可重复的交付过程进行产品测试和验证。

DevTestOps 确保所涉及的开发或产品团队能够访问所需的测试基础结构、平台和框架, 而不必花费大量的时间在配置上, 然后再进行测试。如果 QA 流程由于 QA 团队的设置和配置需要几天才能完成, 那么从 CI 系统获得的基本价值将会丢失。

连续测试应集成到 Pipeline 中, 使用 Jenkins、TeamCity 等工具。让我们先了解一下需要考虑的因素, 然后再开始 DevTestOps 之旅。

  • 通过自动化所有可能的测试来自动化测试周期
  • 与开发团队合作, 建立自动化测试(也许是阈测试) 标准, 以促进从开发到测试
  • 与开发团队一起建立自动化的构建和部署流程
  • 定义和自动化开发团队和 QA 团队之间的交接
  • 在准备自动环境资源调配时创建测试环境配置文件
  • 利用云或其他虚拟技术根据需要建立测试环境
  • 将自动化测试能力与开发团队的持续集成能力集成在一起, 以建立持续测试

DevTestOps 将如何影响敏捷公司?

对于敏捷公司来说, 它的核心是持续的规划、连续的测试、持续的集成是关键主题。DevTestOps 模型对于敏捷公司来说至关重要, 因为它确保了整个团队的重点是质量, 并且所进行的所有开发都需要无缝和可靠。此模型给敏捷公司带来的进一步好处是:

  • 增强的、无 bug 的构建和软件产品 -- 无 bug 的策略实质上意味着, 在团队冲刺 (sprint) 期间任何时候在生产系统上引发的任何 bug 都必须在最短的时间内进行评估、处理和关闭, 而不会影响客户或以不太有价值的功能为代价。
  • 持续的反馈将确保运行业务的实时更改
  • 从构建系统到测试系统的连接是自动的, 为测试做准备。没有人为干预的启动功能测试是必需的。
  • 在开发过程中, 随着市场技术趋势的进步而采取变化
  • 由于迭代方法, 加快了上市时间
  • 由于更快的发布和没有部署后的更改而降低了成本

将软件生命周期的三个主要阶段结合在一起, 不会解决与典型开发相关的所有挑战, 也不能优化开发周期。开发周期的重大优化将会发生,通过实施自动化的最佳实践, 通过共享知识和凝聚力的团队合作。因此, 可以很容易地说, 采用 DevTestOps 将导致加速软件交付, 但是, 不同的团队一起工作以了解项目需求, 提供几乎没有 bug 的短期版本。

尽管敏捷公司在产品及其交付方面将会有很大的收益, 但在采用 DevTestOps 时, 团队成员的运作将会有不同的视角。对于某些角色, 这些界限可能会开始模糊, 有些则可能是扩展, 但是, 对于所有角色, 将会有一个进化来扩展他们的知识和技能。

参考文档:
http://www.tothenew.com/blog/dev-test-ops-the-way-forward-for-continuous-integration-continuous-delivery-cicd/

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 0 条回复 时间 点赞
rocl [DevTestOps]---开篇综述 中提及了此贴 01月03日 16:17
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册