基础架构即代码和TDD
作为代码的基础架构告诉我们使用自动化构建的工具。大。像工具ansible，厨师，木偶，盐栈以及其他推动我们写作基础设施长相怎么样，而解决分歧。 在Salt Stack中，这些位称为状态。如果状态与现实不符，该工具将为我们解决。换句话说-我们正在为基础架构编写测试，如果测试失败，该工具将自行修复。至少那是主意。 XP教我们如何使用TDD，问题是它是否适用于基础架构？工具表明确实如此。 我可以想象几种非常有用的测试类型。 我们编写与部署的服务捆绑在一起的冒烟测试，以确保端到端的部署服务正常运行。这将是一个API调用或/和systemctl检查，以确保我们刚刚部署的内容能够正常工作。由于诸如ansible之类的工具具有确保服务正在运行的状态，因此许多功能都可以在相同的状态下涵盖。 有一个项目Molecule允许针对docker或另一个临时虚拟化引擎运行单独的角色（如Ansible所说的那样）。这迫使角色分离，并允许在处理角色时将其与剧本隔离地执行。测试通常允许模拟该角色应该使用的变量。但是，其他示例似乎是ansible引擎的副本（声明文件属于用户...）。 ThoughtWorks的高科技雷达，现在推崇一样的工具INSPEC，serverspec或戈斯用于验证服务器是否满足规范。但是我们正在编写规范，不是吗？ 如果我们以状态/角色描述基础架构，那么进一步测试基础架构是否有意义？我想这可能会在较大的组织（由一个团队提供规范并遵循其他规范）中变得更加必要，或者如果有大量角色，也许您想运行其中一部分并从测试中获得快速收益？我很努力地想知道，如果您对相同的问题有一个角色/状态，为什么还要编写测试。