实现Devops的目标意味着开发和运维行为和方法的一些基本变化。资深架构师Dan阐述了实现DevOps需要高频率的交付和全局视角，同时分析了一个有效的交付系统应该具备的特质。

关于高频率的问题，Dan指出，为了实现DevOps目标，最明显的变化之一是我们假设把新的软件功能交到用户手中才能让软件更有价值。这个假设意味着越早发布新的软件功能越好，因为这意味着新的软件功能所带来的价值实现的更快。但是绝大多数的开发团队，以前都以用很长的时间开发很大的软件为导向。

这种短周期、高频率的开发假设才正是软件开发定义转变的根本所在。DevOps摒弃了原来那种一年当中将开发进程暂停很多次而去做很大的软件整合和组装的想法，取而代之的是一个开发系统应该能持续运行，并且擅长连续不断地开发大量小的增量。关键点是替代。传统的以大的开发为导向的系统通常都很笨拙，所以很难高速运转来支持DevOps。“用旧方法做，就是尽量快点”的企图常常会失败，因为创造旧方法的假设从来不是为了支持高频率的活动。这不是好与不好，这只是一个需要解决的工程问题。

鉴于这种新的交付过程变成了从软件投资中获取价值的固有的一部分，这种过程理所当然也就成为了整个系统新的扩展。它成为了评价研发投资最基本的方式。于是，这也形成了管理交付进程的效率和效果对整个系统来说有着直接且可计量的商业价值的假设。这个假设所暗含的意思是忽略维持交付能力所产生成本是不可行的。

而DevOps研发另外一个特点是它着眼于完整的系统而不是简单的能实现软件功能的代码变化。Dan指出：

DevOps严谨地认为应用程序代码依靠服务器、网络和数据库等基础设施来实现它的价值。因此，DevOps部署方法同等地对待系统组成部分的所有变化，以同样的方式追踪记录这些变化。一些基础设施的变化，比如一个谨慎的网络交换机升级或者存储设备的增加，会被视为性能的增强（系统的新功能），即便这些变化可能会不太容易察觉。同样的，网络服务器的或者SAN固件补丁可能会被认为是修复补丁或者缺陷。不论一个开发团队如何将事物分类，关键是他们能够用同样的严谨态度去对待其他部分，来保证整个系统的持续稳定。
在DevOps环境下，将全局系统的视角运用到一个高层次的模型中，Dan认为将会产生下面四种将被交付的核心变化：

• 应用——应用是系统中编写代码的真正特性。它是驱动整个核心业务进程的具有高度可见性的功能。它的这种可见性使它获得了很多的注意，但是这种关注几乎没有给支持它的环境带来任何主动式的价值考虑。
• 操作系统服务——操作系统服务适用于所有的机器（虚拟的或是真实的）、操作系统服务、程序库和能让应用运行的中间软件。所有环境下配置的协调性，从测试一直到生产，都是应用稳定性和质量的关键驱动因素。
• 网络服务——网络服务将所有的网络设备和配置集中在应用的周围。这些配置显然影响运行和可用性，但是也能影响应用行为和体系结构。例如，应用和负载均衡器必须就在其他事物中就session处理达成一致。
• 数据库——应用中的数据库包含应用使用和产生的关键数据。在应用的整个生命周期中，数据库和应用必须在数据规划结构方面完美地保持同步。

Dan认为，DevOps部署需要一种很严格缜密的方法将各种变化传递到这种部署所支持的软件系统。系统需要承受的异常、变化或者是特殊的事件越多，系统开发尤其是维护就会越昂贵。控制交付过程的复杂程度就要理解并控制将被交付的对象以及它们是怎样被交付的。这要求开发团队必须商定一套构成每个交付单元的已定义的程序包和一个能和谐地将程序部署到所需要的环境中的系统。

以“定义好的程序包”为例，Dan指出：

一个有效的交付系统要求被交付的项目符合一定的标准。现实世界中的集装箱就是一个很好的例子。这种标准的集装箱能够被标准的设备通过极其复杂的物流网运输。这个物流网络包括很多不同的交通方式，如火车、货船和货车。在起重机和追踪系统的帮助下，我们能将任何东西运送到任何地方，只要它能够被装在一个集装箱中。将这些集装行标准化是世界商品运输和贸易史上的一次革命。

好消息是我们没必要制定一个国际化的标准来将变化交付到一个软件系统中。许多开发团队已经通过一些活动拓展实现了这个目标。许多开发团队正在通过持续集成或者其他的计划以稳定的速度开发软件内部版本。这些内部版本拥有或者应该拥有一些独特的身份标识，能让使用它们的人，比如测试者，预期软件的性能和特点等。

这种方法能给开发团队提供一条理解其他三大组件中变化组群的基准。如果这四大构成中的每一种都有一种标准方式去识别变化，那么通过独有的变化指示器去追踪这四大构成的组合就会变得相对直接简便。对应用的内部版本号、配置服务器以及数据库的模式版本等的组合就能够被记录并且被部署到任何测试或者使用环境中。

交付系统不像集装箱，Dan指出，可部署数据包系统不一定和水力学和柴油燃料有关。相反，它涉及一组工具和程序，它们能让开发团队以同样的方式操控他们的开发环境、测试环境以及生产环境并且任何时候都能将数据包部署到任何一个环境中。这些工具和程序涉及环境中的各种函数。这些函数包含不同领域的专业知识，并且根据组件中出现的问题以不同的方式运用。考虑到各种函数复杂性，根据它们的作用建立一个框架来将它们形象化并分成不同的种类将会很有帮助。