无论您正在运行何种类型的 IT 应用程序，将功能、修复或更改成功交付到生产中，对于更多组织而言，仍然是一个痛苦缓慢、容易出错且代价高昂的过程。随着越来越多的这些应用程序从内部“支持服务”转变为面向客户的存在，因此这个问题从内部效率问题转变为竞争日益激烈的企业生存问题之一。
这种转变在很大程度上推动了敏捷、 devops 和 持续交付 的采用迅速增加。我经常误以为这些举措背后的技术和原则主要或仅适用于内部开发的自定义应用程序，但它们实际上同样适用于其他类型的应用程序。
在这里，我想谈谈我们如何将敏捷、devops 和持续交付的一些原则也应用于商业现成 (cots) 应用程序……并获得许多好处。
婴儿床挑战
在出现任何误解之前：使用 cots 系统更快地交付功能、修复和更改 并不 容易。与您通常具有很大影响力的内部应用程序不同，COTS 应用程序通常“接受或放弃”，并且安装和配置通常非常复杂且耗时。
因此，公司通常只有几个运行 cots 堆栈的环境：可能是一个或两个测试环境，一个 qa/uat 环境，也许还有一个用于预生产（以及，显然，prod 本身）。这些通常是“在黎明时分”手动设置的——由不再在组织工作的人设置的情况并不少见——而且通常不可能准确地重现它们的配置。当然不会很快或自动！
多个团队等待环境可用时的瓶颈，查找和修复错误配置的时间损失，环境之间行为的莫名其妙的差异等几乎可以保证。
为什么“自下而上”的自动化是错误的方法
显然，管理 cots 应用程序的团队很清楚这个问题，我们采访过的许多人都在尝试自动化他们的 cots 堆栈的配置，以给他们更大的灵活性。
当我们与这样的团队交谈时，很常见的是听到他们对问题采取“自下而上”的观点： 首先 创建虚拟机， 然后 配置操作系统， 然后 安装任何先决条件， 然后是 cots 应用程序， 然后 才添加任何标准的公司特定配置， 最后 部署一些业务逻辑和相关配置。
如果您将整个 cots 堆栈视为“一大块代码和配置”，这是一种足够自然的方法，但如果您试图专注于最大化 业务 ，这通常不是最有效的思考方式 价值 。
考虑以下三个观察结果：
- “顶层” ——特定于应用程序的业务逻辑和配置，以及在较小程度上共享的特定于公司的配置—— 是大部分业务价值所在
- 顶层由 一个或多个 组 贡献，这些组通常 不同于管理 堆栈 “底部”的组
- 顶层将独立于堆栈的底部更改 ，并且比 堆栈的底部 更频繁
使用 xl deploy 加速业务价值层
为了从针对 COT 的敏捷、DevOps 和持续交付计划中获得最大的加速和业务价值，您需要专注于使 COT 堆栈 顶层 的自动化——这实际上使您的公司与竞争对手区分开来的部分，您的客户与之交互并从中获取价值的部分 – 便携。这正是 xl deploy 和类似工具的设计目的。
引入像 xl deploy 这样的部署自动化工具来管理 cots 应用程序的业务价值层允许您执行以下操作：
-
Cots infra 团队可以专注于“堆栈的底部”：提供一个健壮的、版本化的标准安装，可以在虚拟或云环境中自动配置。
在任何给定时间都应该只需要支持极少数此类“标准安装”，从而使 cots infra 团队能够专注于更重要的任务，例如优化面向客户的生产安装。 - 堆栈底部的自定义程度越低，您将需要将部分甚至全部或您的环境移动到 saas 提供商或其他外部托管选项的选项就越多。
- 这将使您更轻松地为在业务价值层上工作的团队启动尽可能多的环境，从而消除资源冲突、配置“错误搜索”和其他当前痛点。
结果
结果？在当今的 cots 环境中困扰功能/修复/变更交付的瓶颈已基本消除，从而使业务逻辑团队能够更有效地工作。
任何类型的自动化都会对此有所帮助，但是引入专门针对业务价值层的工具会增加一个关键的额外好处：通过将顶层与堆栈的商品部分分开，您可以测试和开发功能、修复和更改很多， 快多了。 修改 cots 堆栈的顶层 比从头开始提供整个环境要 快得多 。