DevOpsはソフトウェアエスクロー手順の改善にどのように役立ちますか？
ソフトウェアベンダーと、このベンダーの一部のソフトウェアのライセンスを取得した顧客について検討します。ライセンスを取得するソフトウェアは、オンプレミス（顧客の場所）またはSaaSソリューションの形式（ベンダーがホスト）で使用します。ただし、顧客はソフトウェア（実行可能ファイルなど）を使用/実行するために必要なものにしかアクセスできないため、実行可能ファイルを作成するためのソースコンポーネントやそれに関連するものにはアクセスできません。 ベンダーに問題が発生した場合（破産など）のシナリオで顧客のビジネス継続性を保護するために、両方の当事者が何らかのソフトウェアエスクロー（SE ...「また」）契約（ソースコードエスクローとも呼ばれる）に同意する場合があります。このような合意により、両当事者は、両当事者から信頼される第三者（=「ソフトウェアエスクローエージェント」）を関与させることに同意します。これらは、そのようなSE合意のハイライトです（=実際のSEプロセスの仕様）： すべてのソフトウェアコンポーネント（アーティファクトライセンスされたソフトウェアに関連する）SEエージェントに関連するいくつかの合意された場所で、ソフトウェアベンダーによって寄託されます。そのようなデポジットには、実行可能ファイルだけでなく、実行可能ファイルを作成するためのソースコンポーネントとそれに関連するすべてのものが含まれます（実行可能ファイルを作成するためのドキュメント、指示なども）。 ソフトウェアベンダーはソフトウェアライセンスの有効期間中に複数のリリースを作成する場合があり、お客様はそのような新しいリリースを受け取る権利を持っているため（ライセンス契約に従って）、そのようなSE契約の一部は「すべての主要な新しいリリースについて」です。 （「メジャー」が何を意味する場合でも...）、SEエージェントに配信されたデポジットも更新/更新されます。 特定の条件が満たされた場合（例：ベンダーの破産）、ソフトウェアエスクローエージェントは、顧客の要求に応じて、寄託されたすべてのコピーをライセンスのある顧客に配信し、顧客が引き続き使用できるようにします。ソフトウェア、および必要に応じてソースコードを調整して、顧客のビジネスで引き続き使用できるようにします。 このようなSEエージェントが関与するための一般的な方法は、弁護士などの法人またはエンティティの一種です。しかし、実際に「SEデポジットを処理する」（SEエージェントによる）には、あらゆる種類のリリース管理やソフトウェア配信タスクを、おそらく知らない誰かまたは何か（貧弱なSEエージェント）が実行する必要があります。ライセンスされたソフトウェアが行うことになっているすべてのこと...保証された楽しみ！ 私の質問： 上記のように、DevOpsはソフトウェアエスクロー手順の改善にどのように役立ちますか？どのようなツールチェーン-SE契約のどの部分の履行に使用することをお勧めしますか？そして、適切な場合、そのための（できればオープンソースの）ソフトウェアソリューションを使用しますか？ 注： 事態をさらに複雑にしないために、関係するすべての当事者間で合意され、SEエージェントは実行されているデポジットについていかなる種類の「検証」も行う必要がないと仮定します。つまり、デポジットされたものはすべて、完全、最新、文書化されているなどと見なされます。 「メジャーな新しいリリース」について：毎年1〜3の間であると想定します。つまり、ライセンスを取得した顧客は、それらのリリースに（SEエージェント経由で）アクセスできることだけを期待します。ライセンスされた顧客への中間配信（フィックスやベータ版など）があったとしても、それらのタイプの配信は範囲外と見なされます。それが理由であったとしても： SEエージェントは、「SEエージェントが処理するデポジットごとに」課金します。 ライセンスを取得した顧客がリリースを変更することはめったになく、問題が発生した場合にのみSE契約を使用できることにのみ関心があり、問題が発生した瞬間にリリースが実行されます。