5.7针对运行而设计

5.7 针对运行而设计

很多组织都要面对的一个典型问题就是复杂性，即把设计的系统转移到部署的数据中心的复杂性。开发团队与运行团队通常有着不同的词汇表、不同的成员、不同的物理位置（有时还是不同的大陆或不同的公司）。开发与运行之间的信息流通常令人非常不满意，并且往往还不准确和不完全。

特别是对于分布式的系统，有多个部件要部署在多个服务器上，每个部件都有自己的配置需求。例如，有些在测试环境可以运行的应用不能在生产环境中运行，因为这些应用违反了某些开发人员不知道的政策。在这种情况下，为了保持应用的一致，有时要求变更架构设计；或者相反，需要应用向数据中心提出需求，比如特定的版本或补丁包。这些运行需求可能会与现已部署的其他应用相矛盾。这些沟通不匹配的结果可能就是：实际部署应用的运行就绪时间会比架构师、开发人员和测试人员所宣称的部署就绪时间延迟了几周或几个月。

在接纳变更和激活了业务敏捷性的价值增加的方法中，这些延迟就是巨大的障碍。VSTS开始通过激活针对运行而设计（Design for Operations）来消除这类障碍。这一原则很简单。不用一直等到应用实现之后才能尝试部署，VSTS在设计期间就能够测试应用的部署能力。然后，解决方案的架构师和基础设施的架构师就能够在实际部署之前解决应用需求与数据中心的约束之间的任何不兼容性，这样就显著地降低了成功部署所需的时间。

系统定义模型(System Definition Model，SDM)使得针对运行而设计成为了可能：

SDM的心脏是一个系统的构想。在它最基本的形式中，系统是一个独立的可部署的资源配置。对于软件系统，资源本质上就是目录和文件，比如二进制文件、XML文件、配置文件、SQL脚本文件等。对于图形系统、主板、网卡和电源之类的硬件系统，资源可能包括板子、处理器芯片、内存芯片、风扇和其他低层的构件。

如果系统允许对其资源的访问，或者如果它的资源访问了由其他系统中的资源提供的服务，它就通过端点（endpoint）来暴露这些资源。例如，主板可能为外设提供了一个IDE端点；应用使用Web服务的端点来暴露或消费Web服务；服务器利用HTTP端点来支持使用HTTP协议对其进行访问。

SDM在部署设计器（参见图5-6）中是图形化的。它结合了应用设计（通常来自解决方案架构师）和逻辑数据中心设计（来自基础设施架构师）。你可以直接在这个图上验证架构，也就是说，你能够确定所设计的应用是否可以部署到所配置的数据中心中。如果需要的话，任何异常都会直接在图上显示为带符号的警告（参见图5-7）。

图5-7 部署设计器的验证能够识别所设计的应用与所配置的数据中心之间的冲突。在本例中，应用所要求的是Windows Server 2003，但是它却要部署在一个装了更早版本OS的服务器上

SDM定义了一个系统的模型和一个数据中心的模型，并且使得部署能够被定义和验证。模型允许对设计的验证，甚至是在编码开始之前。在应用部署之后，当为了解决错误而修改应用的配置时，应用配置的变更也会直接与源代码和配置文件同步。模型反映真实源代码这一事实对于部署的验证是非常重要的。模型还描述了怎样可以覆盖配置。

除了在设计时能够验证之外，VSTS还能在虚拟机中运行测试（这将在第7章中讨论），这两种方式都简化了测试时的确认。