问题描述
在软件供应商与授权客户之间存在一种情况：软件供应商授权客户使用他们的软件，但客户只能获得使用/运行软件所需的部分内容，而无法获得生成可执行文件所需的源代码等相关组件。为了在供应商出现问题（如破产）时保障客户的业务连续性，双方可能会达成一种“软件托管”（Source Code Escrow）协议，即一种受信任的第三方（称为“软件托管代理”）介入的协议。以下是这种协议的主要内容：
- 所有与许可软件相关的软件组件（与许可软件相关的构件）由软件供应商提交给软件托管代理。这些提交包括了可执行文件以及生成可执行文件所需的源代码等所有内容（包括文档、指南等）。
- 鉴于软件供应商可能在软件许可期间发布多个版本，而客户有权获得这些新版本，因此协议的一部分是“每次发布新主要版本”时，提交给软件托管代理的内容也会被更新。
- 如果满足特定条件（例如供应商破产），授权客户可以要求软件托管代理提供存放的所有内容的副本，以便客户能够继续使用软件，甚至根据需要修改源代码，以继续使用软件。
用户的问题是：如何借助DevOps改进上述描述的软件托管程序？推荐哪些工具链工具用于完成软件托管协议的各个部分？在适当的情况下，应使用哪些（最好是开源的）软件解决方案？
解决方案
DevOps可以为软件托管程序提供支持，以下是一些DevOps操作模型的元素，可以支持软件托管：
基础设施即代码：通过在源代码控制中存储和版本化依赖基础设施的可执行规范，有效地记录源代码开发的环境。与文本文件中的静态文档不同，它在软件供应商定期执行构建其自己的环境时，不会过时或受到“位腐化”的影响。当整个开发流水线都在源代码控制中构建和维护时，这将始终保持最有价值。
持续集成：持续集成的目标是定期执行一系列步骤，理想情况下是在每次更改时。通常，这意味着在检入和推送到中央存储库后，将执行一系列测试以验证流程。从软件托管的角度来看，预计这也会将一个工作版本推送到由第三方拥有和操作的备用“备份”存储库中。重要的是要注意，这必须在法律和财务上与软件供应商“解耦”。
持续部署：持续部署的目标是定期交付一个工作状态的软件。从第三方的角度来看，它只是另一个部署目标，用于部署输出，尽管可能不会在第三方的架构上主动启动基础设施。
一些其他需要考虑的因素包括：
- 从静态文档转向基础设施即代码可以显著减少更新说明文档（安装、配置和恢复软件的说明）所需的努力。
- 不要忘记密码管理，如X.509证书、对称密钥、密码和许可密钥，虽然它们可以存储在源代码控制中，但也有自身的缺点。
从工具的角度来看，这将在很大程度上取决于开发环境，尽管没有专门用于软件托管的工具，但可以考虑以下工具：
- .NET开发：GitHub、BitBucket用于源代码控制；AppVeyor、TeamCity、Jenkins用于构建和测试；Ansible、Puppet、Chef用于配置管理；ProGet用于包管理；Octopus Deploy用于部署。
- Java开发和开源平台：CircleCI、TravisCI、TeamCity、Jenkins用于构建和测试；Ansible、Puppet、Chef用于配置管理；JFrog Artifactory、Sonartype Nexus用于包管理；Capistrano用于部署（请注意，对于Java开发，也可以考虑使用其他工具，具体情况取决于开发环境）。
总之，如果能够将基础设施即代码、持续集成和持续部署原则应用于软件包，那么可以用来满足软件托管合同下的义务。