Devops工具链
DevOps实际是一种文化上的变迁，代表了开发、运维、测试等环节之间的协作，因此DevOps工具是非常多种多样的，甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别，并可体现出软件开发和交付过程的不同阶段：
- 编码：代码开发和审阅，版本控制工具、代码合并工具
- 构建：持续集成工具、构建状态统计工具
- 测试：通过测试和结果确定绩效的工具
- 打包：成品仓库、应用程序部署前暂存
- 发布：变更管理、发布审批、发布自动化
- 配置：基础架构配置和部署，基础架构即代码工具
- 监视：应用程序性能监视、最终用户体验
虽然可用工具有很多，但其中一些环节是组织内部应用DevOps工具链不可或缺的。
诸如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等常用、广泛使用的工具都是2016年的DevOps热门工具。
基础架构组件的版本控制、持续集成和自动化测试
基础架构的版本控制能力（而非基础架构的构建脚本或配置文件）及对其进行自动化测试的能力极其重要。
DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。
此外基础架构元素应该能向软件交付物一样进行持续集成。
收益
DevOps的收益有很多，包括但不限于：
可重复性与可靠性：时至今日，构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机，只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然，随着各种变更或软件开发、持续集成，并自动测试，这套构建脚本或机制也会进行持续集成。
最终幸亏有了XP或敏捷，我们在软件开发端所使用的同一套实践也能让运维端获益。
生产力：一键部署，一键供应，一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时，但在这过程中运维人员可以从事其他更有趣的工作，而无需等待一条命令执行完毕后继续输入下一条命令，毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间！：一键点击即可恢复生产环境，就是这么简单。
确保基础架构的同质：彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异，这是确保基础架构绝对同质（Homogeneous）并且可再现的唯一可行方法。以此为基础，通过对脚本或Puppet配置文件使用版本控制机制，我们甚至可以重建出与上周、上个月，或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准：基础架构标准甚至可以不复存在，代码本身就是标准。
让开发者自行完成大部分工作：如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境，他们也就可以自行完成很多与生产环境有关的任务，例如更好地理解生产失败，提供更恰当的配置，实现部署脚本等。
这只是我个人感觉IaC可提供的部分收益，相信还有很多其他收益。
