DevOps如何帮助改进软件托管过程？

Question

考虑软件供应商和该供应商的某些软件的许可客户，在那里，被许可的软件要么是在前提下(在客户的位置)使用，要么是以SaaS解决方案的格式使用(由供应商托管)。但是，客户只能访问使用/运行软件所需的东西(可执行文件和类似的东西)，而不能访问创建可执行文件所需的源组件和任何相关组件。

为了保护客户的业务连续性，在供应商可能出了问题的情况下(例如:破产)，双方可能同意某种类型的软件托管(SE )。“也”)协议(也称为源代码托管)。有了这样的协议，双方同意让第三方参与(=“软件托管代理”)，得到双方的信任。以下是这种SE-协议的要点(=实际SE-流程的规范)：

• 所有软件组件(与授权软件相关的工件)都由软件供应商存放在与SE-agent有关的商定位置。这些存款包括可执行文件，但也包括源组件，以及与创建可执行文件相关的任何内容(甚至文档、指令等用于创建可执行文件)。
• 由于软件供应商可以在软件许可期间创建多个版本，而且客户有权接收此类新版本(根据许可协议)，这种SE-协议的一部分是“与每一个重大的新版本一起”(无论“主要”指的是.)，交付给SE代理的押金也将被更新/刷新。
• 如果满足特定条件(例如:供应商破产)，那么软件托管代理将根据该客户的请求，向许可客户交付已交存的所有内容的副本，以便客户能够继续使用该软件，并在必要时调整源代码，以便继续将其用于客户的业务。

一种常见的做法，这种代理介入，是某种法人/实体，如律师。但要真正“处理SE-存款”(由SE-代理)，所有类型的发布管理和/或软件交付任务都需要由某人或其他人(可怜的SE-agent)执行，他们可能根本不知道授权软件应该做什么.有乐趣保证！

我的问题

如上所述，DevOps如何帮助改进软件托管过程？比如，您建议使用什么样的工具链-tools来实现SE协议的哪一部分？在适当的情况下，使用哪种(最好是开源的)软件解决方案？

Notes

1. 为了不让事情进一步复杂化，只要假设所有相关方都同意，SE代理机构就不必对正在进行的存款进行任何类型的“核查”。也就是说:任何存放的东西都被认为是完整的，最新的，有记录的，等等.
2. 关于“重大新版本”：假设每年有1到3个版本，这意味着许可客户只希望能够(通过SE-代理)访问这些版本。即使有中间交付(如补丁或测试版)给持牌客户，这些类型的交付被认为超出了范围。即使这只是因为：
   • 代理代理收取“由代理处理的每一笔定金”的费用。
   • 获得许可的客户很少更改发布版本，并且只对在事情出错时能够使用SE协议感兴趣，因为他们正在运行的版本在事情出错的时候运行。

Answer 1

但要真正“处理SE-存款”(由SE-代理)，所有类型的发布管理和/或软件交付任务都需要由某人或其他人(可怜的SE-agent)执行，他们可能根本不知道授权软件应该做什么.有乐趣保证！

我不会和SE供应商做生意，这会让这种不幸的情况存在--他们不知道自己在做什么。

如果SE存款是由SE代理以任何方式处理，则需要在协议中充分记录确切和完整的处理过程，这样才能实际使用。

这还应该包括精确的环境规范(或复制它的过程)和用于此类处理的工具链。换句话说，这种选择并不是真正向SE代理单方面开放的。除了实际的存储策略(就我个人而言，我也会在协议规范中包括这个选择，即使选择是由SE代理单方面完成的)。

一个好的SE协议还将确保供应商的每一个SE定金都经过该处理，并且客户总是获得并限定/签署该特定处理的结果，而不是直接来自供应商的另一个结果--以验证该过程本身仍然是up2date，并且对每个SE定金都有效。

否则，在稍后的时间(如果/当需要的话)复制"SE取款“的能力是值得怀疑的，这实际上是空出了整个SE故事。