DevOpsはソフトウェアエスクロー手順の改善にどのように役立ちますか？

ソフトウェアベンダーと、このベンダーの一部のソフトウェアのライセンスを取得した顧客について検討します。ライセンスを取得するソフトウェアは、オンプレミス（顧客の場所）またはSaaSソリューションの形式（ベンダーがホスト）で使用します。ただし、顧客はソフトウェア（実行可能ファイルなど）を使用/実行するために必要なものにしかアクセスできないため、実行可能ファイルを作成するためのソースコンポーネントやそれに関連するものにはアクセスできません。

ベンダーに問題が発生した場合（破産など）のシナリオで顧客のビジネス継続性を保護するために、両方の当事者が何らかのソフトウェアエスクロー（SE ...「また」）契約（ソースコードエスクローとも呼ばれる）に同意する場合があります。このような合意により、両当事者は、両当事者から信頼される第三者（=「ソフトウェアエスクローエージェント」）を関与させることに同意します。これらは、そのようなSE合意のハイライトです（=実際のSEプロセスの仕様）：

• すべてのソフトウェアコンポーネント（アーティファクトライセンスされたソフトウェアに関連する）SEエージェントに関連するいくつかの合意された場所で、ソフトウェアベンダーによって寄託されます。そのようなデポジットには、実行可能ファイルだけでなく、実行可能ファイルを作成するためのソースコンポーネントとそれに関連するすべてのものが含まれます（実行可能ファイルを作成するためのドキュメント、指示なども）。
• ソフトウェアベンダーはソフトウェアライセンスの有効期間中に複数のリリースを作成する場合があり、お客様はそのような新しいリリースを受け取る権利を持っているため（ライセンス契約に従って）、そのようなSE契約の一部は「すべての主要な新しいリリースについて」です。 （「メジャー」が何を意味する場合でも...）、SEエージェントに配信されたデポジットも更新/更新されます。
• 特定の条件が満たされた場合（例：ベンダーの破産）、ソフトウェアエスクローエージェントは、顧客の要求に応じて、寄託されたすべてのコピーをライセンスのある顧客に配信し、顧客が引き続き使用できるようにします。ソフトウェア、および必要に応じてソースコードを調整して、顧客のビジネスで引き続き使用できるようにします。

このようなSEエージェントが関与するための一般的な方法は、弁護士などの法人またはエンティティの一種です。しかし、実際に「SEデポジットを処理する」（SEエージェントによる）には、あらゆる種類のリリース管理やソフトウェア配信タスクを、おそらく知らない誰かまたは何か（貧弱なSEエージェント）が実行する必要があります。ライセンスされたソフトウェアが行うことになっているすべてのこと...保証された楽しみ！

私の質問：

上記のように、DevOpsはソフトウェアエスクロー手順の改善にどのように役立ちますか？どのようなツールチェーン-SE契約のどの部分の履行に使用することをお勧めしますか？そして、適切な場合、そのための（できればオープンソースの）ソフトウェアソリューションを使用しますか？

注：

1. 事態をさらに複雑にしないために、関係するすべての当事者間で合意され、SEエージェントは実行されているデポジットについていかなる種類の「検証」も行う必要がないと仮定します。つまり、デポジットされたものはすべて、完全、最新、文書化されているなどと見なされます。

2. 「メジャーな新しいリリース」について：毎年1〜3の間であると想定します。つまり、ライセンスを取得した顧客は、それらのリリースに（SEエージェント経由で）アクセスできることだけを期待します。ライセンスされた顧客への中間配信（フィックスやベータ版など）があったとしても、それらのタイプの配信は範囲外と見なされます。それが理由であったとしても：

   • SEエージェントは、「SEエージェントが処理するデポジットごとに」課金します。
   • ライセンスを取得した顧客がリリースを変更することはめったになく、問題が発生した場合にのみSE契約を使用できることにのみ関心があり、問題が発生した瞬間にリリースが実行されます。

非常に興味深い質問です。ソフトウェアエスクロープロセスの目標は、^サードパーティがソフトウェアベンダーの責任を引き継ぐか、または追加のパーティを指名できるようにすることであるという前提で、サポートするDevOpsオペレーティングモデルの次の要素を提案します。ソフトウェアエスクロー：

1. コードとしてのインフラストラクチャ-ソース管理に格納およびバージョン管理された依存インフラストラクチャの実行可能な仕様を通じて効果的に文書化すると、ソースコードが開発された環境が提供されます。ソフトウェアによって定期的に実行されるため、テキストファイルの静的なドキュメントとは異なります独自の環境を構築するベンダーは、「ビットの腐敗」に悩まされる時代遅れになることはありません。これは、Infrastructure-as-codeプリンシパルを適用するソース管理で開発パイプライン全体を構築および維持する場合に常に最も価値があります。

2. 継続的統合 -継続的統合の目標は、ソリューションを定期的に、理想的には変更ごとに統合する一連のステップを実行することです。通常、これは、チェックインして中央リポジトリにプッシュすると、プロセスを検証する一連のテストが実行されることを意味します。ソフトウェアエスクローの観点から、これにより、^サードパーティが所有および運用するセカンダリ「バックアップ」リポジトリに作業バージョンがプッシュされることも期待します。これは、ソフトウェアベンダーから法的および経済的に「リンク解除」する必要があることに注意することが重要です。

3. 継続的展開 -継続的展開の目標は、ソフトウェアを稼働状態で頻繁に配信することです。この意味で、^サードパーティは出力を展開するもう1つの展開ターゲットですが、おそらく^サードパーティファブリックのインフラストラクチャを積極的に起動していません。

方程式に取り入れるべきその他の考慮事項は次のとおりです。

• コードが静的なドキュメントからインフラストラクチャに移行することで、ソフトウェアのインストール、構成、回復方法を説明するドキュメントの更新に伴う手間が大幅に削減されます。
• 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

結局のところ、コードとしてのインフラストラクチャ、継続的インテグレーション、継続的デプロイメントの原則をソフトウェアパッケージに採用できる場合、それを使用してソフトウェアエスクロー契約に基づく義務を果たすことができます。

しかし、実際に「SEデポジットを処理する」（SEエージェントによる）には、あらゆる種類のリリース管理やソフトウェア配信タスクを、おそらく知らない誰かまたは何か（貧弱なSEエージェント）が実行する必要があります。ライセンスされたソフトウェアが行うことになっているすべてのこと...保証された楽しみ！

私はそのような不幸な状況が存在することを可能にするSEプロバイダーと取引をしません-彼らは彼らが何をしているのかを知りません。

SEデポジットがSEエージェントによって何らかの方法で処理される場合、実際に使用できるように、正確で完全な処理手順を契約に完全に文書化する必要があります。

これには、正確な環境仕様（またはそれを再現する手順）とそのような処理に使用されるツールチェーンも含まれます。言い換えれば、その選択は、SEエージェントに対して一方的にオープンではありません。おそらく実際のストレージ戦略を除いて（個人的には、SEエージェントが一方的に選択したとしても、その選択を契約仕様書にも含めます）。

適切なSE契約は、ベンダーによるすべてのSEデポジットがその処理を通過し、顧客が常に特定の処理の結果を取得および認定/サインオフすることを保証します。手順自体は最新のままであり、SE預金ごとに有効です。

それ以外の場合、後で（必要に応じて、または必要に応じて）「SEの引き出し」を再現する機能に問題があり、SEストーリー全体が実質的に無効になります。