usb协议架构及驱动架构_测试驱动的基础架构

最新推荐文章于 2024-09-09 00:00:00 发布

cuxiong8996

最新推荐文章于 2024-09-09 00:00:00 发布

阅读量128

点赞数

文章标签：编程语言 python linux java 大数据

原文链接：https://www.ibm.com/developerworks/opensource/library/a-devops5/index.html

版权

usb协议架构及驱动架构

在配置环境时，大多数组织都会应用反模式，这些反模式会降低创建这些环境的可靠性和可重复性：

一些团队手动安装和配置创建环境所需的资源。问题在于，通常需要几天，几周或几个月的时间才能使环境达到所需的状态。在这段时间里，团队成员可能会来去去去或忘记精确的步骤，从而使任何人都无法按预期重新创建环境。
其他团队尝试记录供应环境的每个步骤。尽管这是一项高尚的工作，并且比不记录该过程要好得多，但是该文档很快过时，不正确或未按照指定的顺序运行（即，人为错误）。由于这些及其他原因，我不建议将文档作为创建环境的记录源（尽管，正如您将在下一节中看到的那样，这可能是系统地配置和测试环境的第一步）。
以前的团队手动安装或记录了所有内容，从而使某些团队“被烧死”。决心从错误中吸取教训，他们使用一系列脚本使基础架构配置自动化。几个月后，他们陷入了无数的自定义外壳和其他脚本的困境中，他们认为环境证明很难成功实现自动化。

关于本系列

开发人员可以从操作中学到很多，操作可以从开发人员中学到很多。本系列文章致力于探索将操作思维方式应用于开发（反之亦然）的实际用途，以及将软件产品视为可以以比以往任何时候都更高的敏捷性和频率提供的整体实体。

相比之下，一些团队在阅读了有关采用DevOps的公司后，从手动配置，文档驱动的配置以及不连续的脚本的收集中吸取了教训。他们将测试驱动的方法与成熟的基础架构自动化工具结合使用，从而逃避了这些反模式，这是单条生产路径的一部分。正如我在本系列文章“ 基础架构自动化 ”中提到的那样，这些团队将基础架构视为代码。在本文中，您将学习如何采用测试驱动的方法来定义基础结构。

原则与实践

在很多场合，我都写了一个五步启发式方法（请参阅参考资料），这是使流程连续的五个关键步骤。它们是：文档，测试，脚本，版本和（使过程连续）。我将在基础结构的上下文中更详细地描述每个步骤，在此基础上所有步骤都可以协同工作：

文件：记录执行流程的步骤。对于基础架构，您将记录组件的类型和版本，例如操作系统，应用程序和Web服务器以及数据库。您还将详细描述如何安装，配置和运行这些基础结构组件。使用这种方法时，关键是要使文档自动化，因为最终您将处置该文档。
测试：编写描述预期结果的自动化测试。对于基础结构，您可以定义功能或预期的结果，例如在特定位置运行的服务器或特定文件或目录的存在。
脚本：对流程的所有动作进行脚本编写。对于基础结构，您将使用Chef或Puppet之类的工具根据上一步中指定的测试来定义这些环境。
版本：版本源文件。对于基础结构，这些源文件在基础结构自动化脚本中定义，例如使用Puppet或Chef创建的脚本。
连续的 ：该过程必须被编写脚本，使其可以无头运行—无需人工来运行命令。对于基础架构，团队将配置持续集成（CI）服务器，以运行基础架构自动化脚本和脚本化环境测试，作为CI作业的一部分-意味着将在每次源文件更改时重建基础架构。

参与其中

developerWorks 敏捷转型提供新闻，讨论和培训，以帮助您和您的组织在敏捷开发原则上打基础。

基础结构测试的显着特征是执行顺序。尽管您仍然可以使用“测试优先”的方法，但是基础结构脚本会应用整个基础结构。然后，运行测试以验证基础架构自动化的有效性。此顺序与应用程序代码单元测试相反，在应用程序代码单元测试中，先运行测试，然后执行特定方法或方法集。从本质上讲，测试驱动的基础架构不涉及原子性-创建整个环境，然后针对新配置的环境运行测试套件。

应用测试驱动的基础结构的最常见方法是从记录配置基础结构的步骤开始。根据该文档，工程师编写了一些自动化测试，以描述基础结构的预期结果。这些测试可能包括团队在完全配置环境后期望安装的内容。然后，工程师编写脚本并将其提交到版本控制系统。最后，脚本和自动测试作为CI系统的一部分运行。这些步骤的某种组合（即使通常不是我设计的“教科书”顺序过程）也可以确保构建一个强大的测试驱动基础结构，从而为所有团队成员提供快速反馈。

这个怎么运作

实施测试驱动的基础结构的许多方法之一是使用行为驱动的开发（BDD）方法。使用BDD时，您可以在称为功能文件的同一文件中定义需求和测试。接下来，我将向您展示一些使用Cucumber和Gherkin域特定语言（DSL）编写的功能文件的示例。

清单1显示了一个Cucumber功能文件（称为production.feature），该文件描述了功能，其背景和场景：

清单1.在Cucumber和Gherkin中定义可执行文件规范

Feature: Scripted Provisioning of Target Environment
As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario: Is the proper version of Postgresql installed?
When I run "/usr/bin/postgres --version"
Then I should see "8.4"

Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

Scenario: Is the proper version of Java installed?
When I run "java -version"
Then I should see "1.6"

Scenario: Is the proper version of perl installed?
When I run "perl -version"
Then I should see "perl, v5.10.1"

Scenario: Is the proper version of make installed?
When I run "make -version"
Then I should see "GNU Make 3.81"

Scenario: Is the proper version of Ruby installed?
When I run "ruby -v"
Then I should see "ruby 1.9.3"

Scenario: Is the proper version of GCC installed?
When I run "gcc -v"
Then I should see "4.4.6"

Feature ， Background ， Given ， Scenario ， When和Then都是Cucumber特定的单词，它们是其DSL的一部分，用于定义功能文件。清单1中的Scripted Provisioning of Target Environment的Scripted Provisioning of Target Environment功能以一种普遍存在的语言描述了预期的结果，所有团队成员（业务分析师，开发人员，测试人员，运营等）都在组织中使用该语言。 /usr/bin/postgres --version类的特定操作利用Gherkin（一种在安装Cucumber时安装的依赖工具）。这种BDD方法提供了一种定义可执行规范的方法，该规范可以通过自动化工具运行。

清单2显示了一个Cucumber功能文件，该文件描述了一种指定安装工具的特定主要版本的方法。在这种方法下，如果基础结构脚本遇到该工具的任何主要版本，都不会失败。

清单2.Cucumber功能检查主要工具版本

Feature: Scripted Provisioning of Target Environment
As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario: Is Tomcat installed?
When I check the version of Tomcat installed
Then the major version should be 6

在清单3中， Example关键字之后的行指示该场景中描述的行为具有多个成功的结果：

清单3.描述Cucumber和小Cucumber中的例子

Feature: Scripted Provisioning of Target Environment

As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario Outline: Is the proper version of libxml2-devel installed?
When I run "sudo yum info libxml2-devel"
Then I should see "<output>"

Examples: output I should see
| output |
| Installed Packages |
| 2.7.6 |

联轴器松动

测试和基础架构之间的耦合并不像单元测试（例如，用JUnit编写的测试）和应用程序代码之间的耦合那么紧密。例如（并提醒您如何编写环境脚本），清单4是使用Puppet基础设施自动化工具的脚本（或清单）的示例：

清单4.木偶清单描述了一个名为`httpd`的httpd服务器

class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

注意，与应用程序代码单元测试不同，清单1中的测试不会执行此Puppet清单。取而代之的是，首先将清单中定义的配置（以及许多其他配置）应用于基础架构以创建环境。然后，像那些在编目定义测试套件1 ， 2 ，和3运行，以验证该环境是在期望的状态，这些测试所定义的。

静态分析

在撰写本文时，用于基础架构自动化的静态分析工具的生态系统还很稀疏。您可以使用一些与应用程序代码静态分析相同的工具，但其他工具还不能满足基础结构脚本的特殊要求-主要是因为基础结构脚本本质上不是过程性的或面向对象的。大多数都是声明性的，这意味着开发人员可以确定脚本中环境的定义方式。该脚本负责使用基础结构实际应用配置的方式。

Simian之类的工具对于识别相似代码的部分很有用。 foodcritic是用于开源基础结构自动化工具Chef的类似于lint的工具。对于覆盖率-因为诸如Chef和Puppet之类的工具不使用过程语言或面向对象的语言-一种有效的方法是使用诸如Cucumber之类的BDD工具而不是您可能应用于应用程序的传统代码覆盖率工具来定义“需求覆盖率”码。

测试驱动一切

在本文中，您了解了可以像应用程序代码或软件系统的任何其他部分一样测试基础结构。您看到了使用Cucumber和支持Gherkin BDD语言实现测试驱动的基础结构的示例。最后，您了解到-尽管对基础结构的静态分析与对应用程序代码的静态分析有所不同，但是您可以使用一些静态分析工具来帮助您改进基础结构自动化代码。

在下一篇文章中，您将了解有关对软件系统的所有组件进行版本控制的信息：基础结构，应用程序代码，配置和数据。

翻译自: https://www.ibm.com/developerworks/opensource/library/a-devops5/index.html