保护客户的业务如果供应商可能出了点问题（例如，破产），则在保持连续性的情况下，双方都可以同意某种形式的软件托管协议（SE ...“ also”）（也称为源代码托管协议）。有了这样的协议，双方都同意让第三方参与（=“软件托管代理”），并得到双方的信任。这些是此类SE协议的重点（=实际SE过程的规范）：
所有软件组件（与许可软件有关的工件）都由该软件存放。供应商，在与SE代理相关的某个商定位置。这些存放的内容包括可执行文件，还包括源组件以及与创建可执行文件有关的任何内容（甚至包括文档，说明等，用于创建可执行文件）。
由于软件供应商可能会在发行期间内创建多个发行版软件许可，并且客户有权接收此类新版本（根据许可协议），此类SE协议的一部分是“随着每个主要新版本的发布”（无论“主要”是什么意思……），交付给SE代理的存款也将被更新/刷新。
如果满足特定条件（例如：供应商破产），则软件托管代理将根据此类客户的要求将已存入的所有内容的副本交付给许可客户，以便客户可以继续使用软件，甚至需要修改源代码以继续将其用于客户的业务。
这种SE代理介入的一种常见做法是某种法人/实体，例如律师。但是要实际（通过SE代理）“处理SE存款”，需要由可能不知道的某人或某人（可怜的SE代理）执行各种发布管理和/或软件交付任务。完全可以保证许可的软件应该做的事情...保证有乐趣！像您会建议使用哪种工具链工具来完成SE协议的哪一部分？并在适当的地方使用哪种（最好是开源的）软件解决方案？
注意：
为了不使事情变得更加复杂，只需假设在涉及的所有各方，SE代理不必对已完成的存款进行任何类型的“验证”。即：假定所存放的内容都是完整的，最新的，有文件记录的。
关于“主要新版本”：假设每年有1-3个，这意味着许可客户只希望能够（通过SE代理）访问这些版本。即使向授权客户进行了中间交付（如修订或Beta版本），这些交付也被认为是超出范围的。即使仅仅是因为：
SE代理收取“对于SE代理要处理的每笔存款”。
许可客户很少更改版本，仅对出现问题时能够使用SE协议感兴趣，因为在出现问题时他们正在运行该版本。
#1 楼
一个非常有趣的问题。假设软件托管过程的目标是允许第三方接管或提名另一方来履行软件供应商的责任，那么我建议支持软件的DevOps操作模型的以下要素托管：Infrastructure-as-code-通过对依赖基础结构的可执行规范进行有效记录，在源代码管理中进行存储和版本控制可为开发源代码提供环境。与静态文档不同在文本文件中，因为它由软件供应商定期执行以构建自己的环境，所以它不会因“位腐烂”而过时。当使用基础结构即代码主体在源代码控制中构建和维护整个开发管道时，这将始终发挥最大价值。定期进行，最好是在每次更改时。通常，这意味着在签入并推送到中央存储库后，会执行一组测试以验证过程。从软件托管角度来看，我希望这还将把工作版本推送到第三方拥有和运营的辅助“备份”存储库中。重要的是要注意，这确实需要与软件供应商在法律上和财务上都没有“联系”。
连续部署-连续部署的目标是经常提供处于工作状态的软件。从这个意义上讲，第三方只是将输出部署到的另一个部署目标，尽管可能不会积极地扩展第三方结构上的基础结构。
将其他因素考虑进方程中是：
从静态文档到基础结构的迁移，因为代码大大减少了更新描述如何安装，配置和恢复软件的文档的工作。
不要忘记秘密管理，例如X.509证书，对称密钥，密码和许可证密钥，它们可以存储在源代码管理中，但这确实有其自身的缺点。
从工具的角度来看，这在很大程度上取决于开发环境，但是我不相信有专门针对软件托管的工具：
.NET开发
用于源代码控制的GitHub或BitBucket
AppVeyor，TeamCity或Jenkins用于构建和测试管道。
Ansible，Puppet或Chef用于管道的配置管理元素。适用于管道的部署方面
Java开发，以及某些扩展的开源平台
CircleCI ，TravisCI，TeamCity或Jenkins用于管道的构建和测试元素。
Ansible，Puppet或Chef用于管道的配置管理元素。 Nexus用于管道的包装管理元素
Capis最后，如果您能够将基础架构即代码，持续集成和持续部署原则运用到开发流程中，那么，trano就可以满足管道的部署方面的需求。
软件包，可用于履行您在软件托管合同下的义务。
#2 楼
但是要真正（通过SE代理）“处理SE存款”，所有的发布管理和/或软件交付任务都必须由某人或某些人执行（可怜的SE代理人）可能
根本不知道许可软件应该做什么...
保证乐趣！
我不会'与SE供应商进行业务往来会导致这种不幸的情况存在-他们不知道自己在做什么。
如果SE存款将由SE以任何方式进行处理代理商需要在协议中充分记录准确而完整的处理程序，以便实际使用。
还应该包括确切的环境规范（或复制过程）以及用于此类处理的工具链。换句话说，选择并不是真正向SE代理单方面开放。除了可能的实际存储策略（我个人也将选择包括在协议规范中，即使选择是由SE代理单方面完成的。）
良好的SE协议也将确保供应商的每笔SE保证金都经过该处理，并且客户始终获得并确认/签署该特定处理的结果，而不是直接来自供应商的替代结果-验证过程本身是否有效对于每笔SE存款。
否则，在以后的时间（如果/需要时）重现“ SE取款”的能力将受到质疑，这实际上会使整个SE故事无效。
评论
Merci Dan给出了这个答案。我确实同意您的大部分内容，但是似乎您没有考虑我的“注释1”。您在这里的答案似乎与一个（新的）问题有关，例如“ SE协议中提供的典型验证级别是什么（以及如何选择）？”。仅供参考：IMO有3个等级...不知道我是否应该将这一天发布为一个自我回答的问题...
–Pierre.Vriens♦
17 Mar 26 '17 at 14:56
我确实看到了注释1，但是如果应用了注释1，那么我将看不到该问题的含义是什么：)如果没有处理管道，那么devops工具集的用途是什么？除了可能是CRM /存储（我的回答也是如此）。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 26 '17在15:08
不确定注释中该CRM的含义（可以重试吗？）。此外，想象一下（差）的SE代理接受以CD形式存入办公室的存款（例如，“一家”软件供应商每年购买1至3张CD，并且有数十家此类软件供应商） 。如果SE代理会通过引入与DevOps兼容的程序来雇用您使这种过时的方法现代化，那么您会提出什么建议？
–Pierre.Vriens♦
17年3月26日在18:33
@ Pierre.Vriens对不起，首字母缩略词混在一起。不是CRM。我的意思是工件存储库。
–丹·科尼莱斯库（Dan Cornilescu）
17年3月26日在21:21
@ Pierre.Vriens如果协议中包含接收CD，那么存储和检索CD（或CD映像）就差不多了。如果不仅限于此，但不涉及处理-我不确定这是什么。如果仍然需要处理，则可以做很多事情。在极端情况下，您可以考虑到SW交付管道中涉及的SE协议的所有3个部分，该部分会产生SW，即使在灾难性的供应商事件中，SW也可以保持可维护性。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 26 '17 at 21:58
评论
什么是Capistrano在木偶或厨师之上的需要？
–滕西拜
17 Mar 24 '17在20:30
令人印象深刻的答案，我需要再消化几次。但是，目前，此评论/想法是：（1）“供应商”是什么意思（您可以尝试使用“软件供应商”或“ SE代理”进行澄清）吗？ （2）在这种情况下，“秘密”将是许可证密钥（也应将其视为代码段，例如，包含PU ID等）。（3）作为ITer，我确实同意“连续”建议。但是，“连续存款”也意味着“连续发票”（=负担不起），因此我不确定（还）“释放”（如每6个月1个）是否适合
–Pierre.Vriens♦
17 Mar 24 '17在20:31
@Tensibai：我的看法是，Capistrano是具有配置管理功能的部署工具； Ansible是具有部署功能的配置管理工具……仅仅因为您可以使用一个工具来完成两项任务，并不意味着您应该这样做。
–Richard Slater
17 Mar 25 '17 at 0:26
@ Pierre.Vriens-我试图同时解决您的第1点和第2点。但是，第3点可能需要更多输入，如果SE代理商建议每笔存款都产生发票，从根本上说，行业正在发生变化然后，敬请尊重他们需要重新考虑其成本模型。他们不这样做的后果是，在DevOps世界中蓬勃发展与逐渐过时之间的区别。
–Richard Slater
17 Mar 25 '17 at 0:39
这篇博客文章有些陈旧，并且没有考虑厨师的一些资源，这里的灵感来自Capistrano。仍然不代表您应该或不应该，但值得一提
–滕西拜
17 Mar 25 '17在7:08