JP6868728B2 - パーミッションドブロックチェーンアプリケーションの継続的デリバリのための方法及び装置 - Google Patents

Description

本開示は、一般にクラウドベースのシステムに関し、より詳細には、ブロックチェーンの使用を通じてクラウドベースのシステムに対して継続的デリバリを容易に行えるようにすることに関する。

従来技術では、クラウドベースのサービス又はハイブリッドなクラウド／エンタープライズシステム上にデプロイされるアプリケーションのための、大規模に拡張可能な継続的デリバリのパイプラインを管理するためのシステム及び方法が存在する。継続的デリバリはある種のパイプラインを構成する一連のジョブであり、ジョブは、ソフトウェア製品をソースコードから取得し、コンパイル及びテストを行って、デプロイ、承認、及びデリバリへと移行するように編成されている。継続的デリバリサーバは、パイプラインの処理を管理する。

複雑なトポロジを有するシステムにおいて継続的デリバリを管理する場合、複数の物理サーバ、ネットワーク、ドメイン及びファイアウォールにわたってワーカーにジョブを割り当てる必要がある場合がある。問題は、集中管理型のサーバが、アクセス制御制限のためにパイプライン内のすべてのジョブを管理できないことである。

このような問題に対処するために、従来技術では、ビルドパイプラインのプラン全体をジョブパッケージ内に書込むような解決策をとっている。さらに、従来技術の実装形態では、異なるサーバ上で動作する複数のビルドワーカーが存在する。各ビルドワーカーは、パイプライン内のジョブに割り当てられる。ビルドワーカーは、ジョブパッケージを受け取り、ジョブを実行し、ジョブの結果を記録する。例えば、第１のジョブは、ビルドワーカーＡが実行し、第２のジョブはビルドワーカーＢが実行する。ビルドワーカーが実行したジョブの結果は、他のビルドワーカーと共有される。結果を共有するために、ブロックチェーン又はデータベースなどの実装形態を利用する。

しかしながら、従来技術では、パイプライン内で次のジョブに進む前に、ジョブの結果を検証する実装形態はない。本明細書で説明する例示の実装形態は、すべてのビルドワーカーが、パイプライン内の次のジョブへ進む前に必ずジョブの結果を検証することを含む。

本開示の態様は、ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理する方法を含んでもよく、この方法は、デプロイのためのソースコードの送信のために、独立して管理される複数の法人のそれぞれにローカルな第１のネットワーク上でソースコードをテストすることを含む。ブロックチェーンにおいて有効であるとして検証されたテストの結果に対して、第２のネットワークでステージングを実行することにより、独立して管理される複数の法人のそれぞれにわたってテストを検証することができる。ブロックチェーンにおいて独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、ソースコードを独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークにおいてそのソースコードをデプロイする。

本開示の態様は、ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理するための命令を有するコンピュータプログラムを含んでもよく、この命令は、デプロイのためのソースコードの送信のために、独立して管理される複数の法人のそれぞれにローカルな第１のネットワーク上でソースコードをテストすることを含む。ブロックチェーンにおいて有効であるとして検証されたテストの結果に対して、第２のネットワークでステージングを実行することにより、独立して管理される複数の法人のそれぞれにわたってテストを検証することができる。ブロックチェーンにおいて独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、ソースコードを、独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークにおいてそのソースコードをデプロイする。命令は、非一時的なコンピュータ可読媒体上に記憶され、１以上のプロセッサによって実行される。

本開示の態様は、ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理するシステムを含んでもよく、そのシステムは、独立して管理される複数の法人のそれぞれにローカルでありソースコードをテストするように構成された第１のネットワークと、ブロックチェーンにおいて有効であるとして検証されたテストの結果に対し、独立して管理される複数の法人のそれぞれにわたってテストを検証するためにステージングを実行するように構成された第２のネットワークと、ブロックチェーンにおいて独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、ソースコードを独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークとを含む。

本開示の態様は、ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理するシステムを含んでもよく、このシステムは、デプロイのためのソースコードの送信のために、独立して管理される複数の法人のそれぞれにローカルな第１のネットワークでソースコードをテストする手段を含む。ブロックチェーンにおいて有効であるとして検証されたテストの結果に対して、第２のネットワークでステージングを実行することにより、独立して管理される複数の法人のそれぞれにわたってテストを検証する手段を含む。ブロックチェーン内において独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、ソースコードを、独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークにおいてそのソースコードをデプロイする手段を含む。

例示の実装形態による、ブロックチェーンネットワークトポロジのシステムアーキテクチャの一例を示す。 例示の実装形態による、ローカルネットワークのシステム構造の一例を示す。 例示の実装形態による、テストツールの物理的構成の一例を示す。 例示の実装形態による、テストブロックチェーンノードの物理的構成の一例を示す。 例示の実装形態による、ジョブ定義テーブルのデータ構造の一例を示す。 例示の実装形態による、状態テーブルのデータ構造の一例を示す。 例示の実装形態による、ログテーブルのデータ構造の一例を示す。 例示の実装形態による、ＣＤドライバの処理の一例のフロー図を示す。 例示の実装形態による、ＣＤマネージャの処理の一例を示すフロー図である。 例示の実装形態による、ローカルステージの処理の一例を示すシーケンス図である。 例示の実装形態による、ステージング段階の処理の一例を示すシーケンス図である。 例示の実装形態による、デプロイ段階の処理の一例を示すシーケンス図である。

以下の詳細な説明は、本出願の図面及び例示の実装形態のさらなる詳細を提供する。図面間の冗長要素の参照番号及び説明は、明確のため、省略する。本明細書全体を通して使用される用語は、実施例として提供されるものであり、限定することを意図するものではない。例えば、「自動」という用語の使用は、本出願の実装形態を実施する当業者の所望の実装形態に応じて、実装形態のいくつかの態様では、ユーザ又は管理者の制御を含む完全自動又は半自動の実装を含んでいてもよい。選択は、ユーザインターフェース若しくは他の入力手段を介してユーザによって実行されることができ、又は所望のアルゴリズムを通して実装されることができる。本明細書で説明する例示の実装形態は、単独で、又は組み合わせて利用することができ、実装形態の機能性は、所望の実装形態による任意の手段を通して実装することができる。

継続的デリバリ（ＣＤ）は、通常、高度の自動化を伴う、短いサイクルでリリースできるようにコード変更を準備できるソフトウェア開発プラクティスである。その目的は、ソフトウェア品質を向上させるために、フィードバックループをできるだけ短くすることである。

ＣＤでは、自動化されたビルド、テスト及びステージングデプロイを１つの連続処理に統合する。すべてのコード変更は、ビルドされ、テストされ、次にステージング環境にプッシュされる。ステージング環境では、本番システムのネットワークの前にＵＩテスト、結合テスト、性能テスト、負荷テスト及び信頼性テストのような複数のテストが存在する。処理を自動化するために、開発チームではＣＤツールを使用する。

ブロックチェーンとは、ネットワークに参加するノード間で分散されて共有されるデータベースである。ブロックチェーンは基本的には追記専用データベースである。ブロックチェーンの名前が示すように、ブロックチェーンはブロックで構成されたチェーンを含む。各ブロックは、トランザクションのリストを含む。各ブロックは、暗号ハッシュを用いて前のブロックにリンクされる。ノードは、ブロックチェーンの状態を維持しながら、状態を変更するためのトランザクションを実行する。ブロックチェーンは、分散型台帳技術としても知られている。

ブロックチェーンシステムは、互いに完全には信頼しない異なる組織によって動作される複数のノードを含む。ブロックチェーンネットワーク内のすべてのノードは、ブロックチェーンに格納されたトランザクション及びトランザクションの順序に合意する。合意のメカニズムは、コンセンサスアルゴリズムとして知られている。パブリックネットワークにおけるコンセンサス中にノードに重度の数学的計算を実行させるＰｒｏｏｆ―ｏｆ―Ｗｏｒｋ（ＰｏＷ）のような様々なコンセンサスアルゴリズムが存在する。ノードが閉じたプライベートネットワーク内で認証されるとき、Ｒａｆｔ、Ｐａｘｏｓ、及びＰＢＦＴなどのフォールトトレラントなコンセンサスプロトコルが使用される。

金融機関やその他の企業は、ブロックチェーンアプリケーションを開発してきた。ブロックチェーンにより、彼らのビジネスプロセスが変わり、新しいサービスが生まれることが期待される。ブロックチェーンの利点は、分散された管理、不変性、及び透明性である。ブロックチェーンネットワークでは、各ノードは同一のトランザクションを実行し、同一の状態を有する。特権のある第３者を介さずにトランザクションを容易にすることが可能である。ブロックチェーン上のデータが不変であるのは、ハッシュのチェーンがトランザクション履歴を変更することを防止するからである。分散データは出資者間の透明性を維持するので、ブロックチェーンは、組織を越える通信や監査のコストを減少させる。

ブロックチェーンプラットフォームソフトウェアには、「パーミッションレスブロックチェーン」と「パーミッションドブロックチェーン」との２種類がある。名前が示すように、パーミッションレスブロックチェーンでは、誰もがブロックチェーンネットワークに参加し、ブロックチェーンノードを動作させることができる。一方、パーミッションドブロックチェーンには、ブロックチェーンネットワークに加わる前にユーザの認証を必要とする。認証されたユーザのみがブロックチェーンノードを動作することができる。企業は、様々なユースケースにおいて適格なアイデンティティを有する組織間で一般的なビジネストランザクションを実行するため、パーミッションドブロックチェーンを使用する。このため、本明細書で説明する例示の実装形態は、パーミッションドブロックチェーンに焦点を当てている。

パーミッションドブロックチェーンを使用する場合、組織は、ブロックチェーンネットワーク内でアプリケーションを実行するためのコンソーシアムを作成する。ブロックチェーンネットワークでは、すべての参加組織は、同じアプリケーションを所有する。これらのアプリケーションは、すべての組織によって実行され、トランザクションを実行し記録する。組織が、コンソーシアム内でアプリケーションを開発して修正すると、全組織は、ブロックチェーンネットワークにそれらをデプロイする前にそのアーチファクトを承認する必要がある。すべての組織は、アプリケーションの権利及び責任を有する。この管理ポリシーは、コンソーシアムにおいて同等の関係を維持する。

テスト結果を使用して、アーチファクト内容を承認する。すべてのテストケースが合格した場合は、そのアーチファクトは組織によって承認される。通常、テストには、ユニットテスト（ＵＴ）、結合テスト（ＩＴ）及びシステムテスト（ＳＴ）が含まれる。参加組織がアーチファクトの内容（例えば、スマートコントラクト、コンフィギュレーション情報）を確実に承認できるように、組織は、ブロックチェーンネットワークの外側でデジタル署名をアーチファクトに与える。その後、署名されたアーチファクトが、本番システムのネットワークにデプロイされる。

しかしながら、パーミッションドブロックチェーンアプリケーション用のエンドツーエンドのＣＤ方法は存在しない。従来のＣＤ法をパーミッションドブロックチェーンアプリケーションに適用する場合には、以下のような問題がある。

すべての組織からの検証なしに次のステップに進んでしまうこと。ＣＤパイプラインの状態は、組織内の１つのサーバによって管理される。パイプラインで次のステップへ進むと、このサーバはジョブ結果を検証し、決定を行う。他の組織は、単一の組織によって管理された状態を信頼する必要がある。この制限は、各組織が等しい力を有するべきであるという、ブロックチェーンネットワークにおける基本的な信頼性に関する前提と矛盾する。

自己のテスト結果を検証することなく承認してしまうこと。ＵＴ及びＩＴのようないくつかのテストでは、単一の組織のみがテストを実行する。他の組織は、自身でテストを実行することなく、アーチファクトを承認しなければならない。他の組織は、テスト結果を有していないため、１つの組織が実行するテスト結果に依存することになる。この制限は、ブロックチェーンネットワークにおける基本的な信頼性に関する前提と矛盾する。各組織は、等しい力を有するべきである。例えば、ＣＤサーバは、組織１にＵＴ及びＩＴを実行するように依頼するとする。他の組織２、３及び４はテストを実行しない。組織２、３及び４は、組織１によって実行されたテスト結果に基づいてアーチファクトを承認しなければならない。

組織を越えた未知の状態：各組織が署名されたアーチファクトを本番システムのネットワークにデプロイするかどうかは明らかではない。デプロイ動作は、各組織によって実行される。ＣＤサーバは、各組織が、承認されたアーチファクトを本番システムのネットワークにデプロイするかどうかがわからない。いくつかの組織は、異なるアーチファクトを誤ってデプロイするか、又はそれらをデプロイすることを忘れる可能性がある。

これらの問題を解決するために、本明細書で説明する例示の実装形態は、以下の解決策、すなわち、ブロックチェーンで共有された結果に従って、パイプラインにおける次のステップへと進むことをすべての組織に検証させる、分散継続的デリバリシステムを含む方法を含むものである。状態は、ブロックチェーンアプリケーション（例えば、スマートコントラクト）として実装されるＣＤマネージャによって管理される。この方法は、すべての組織が自身でテストを実行する分散環境も含む。

これら例示の実装形態により、その寿命全体にわたってパイプラインの状態を制御するＣＤマネージャを介した、すべての組織による検証が容易になる。例えば、パイプラインは、以下の段階を含んでいてもよい。

ローカル段階：テストのため、アーチファクトを、リポジトリにプッシュする。すべての組織が、ローカルネットワークにおいてユニットテスト及び結合テストを実行する。

ステージング段階：システムテストを、ステージングネットワークにおいて実行する。テストに合格したら、すべての組織が、アーチファクトにデジタル署名する。その後、署名されたアーチファクトは、本番システムのネットワークのためのリポジトリにマージされる。

デプロイ段階：すべての組織は、署名されたアーチファクトを本番システムのネットワークにデプロイする。

次のステップに進む前に、すべての組織はＣＤマネージャを実行して、すべての組織が状態を変更することに同意するかどうかを検証する。例えば、ＣＤマネージャは、すべての組織が、ユニットテストと結合テストに合格したかどうかを、ステージング段階へ進む前に検証するように構成されている。ＣＤマネージャは、また、すべての組織が、アーチファクトを署名する前に、システムテストを合格させたかどうかを検証するように構成されている。ＣＤマネージャは、本番システムのリポジトリへアーチファクトをプッシュする前に、すべての組織がアーチファクトを署名したかどうかを検証し、すべての組織が署名されたアーチファクトを本番システムのネットワークにデプロイするかどうかを検証するように構成される。

例示の実装形態では、ＣＤマネージャはブロックチェーンアプリケーションとして実装される。パイプラインの状態を制御する機能は、ブロックチェーンアプリケーションとして実装される。ブロックチェーンアプリケーションは、ブロックチェーンネットワーク内のすべての組織によってホストされ、実行される。ＣＤマネージャはブロックチェーンアプリケーションであるため、ブロックチェーンネットワーク内のすべての組織によって実行される。これは、ＣＤサーバが分散されていることを意味する。さらに、ＣＤマネージャは、ジョブ結果を受け取り、それらをブロックチェーンに書き込む。結果は、すべての組織において共有される。すべての組織は、他の組織が実行した結果を得ることができる。ＣＤマネージャは、ＣＤ状態の変更を検証すると、その結果をブロックチェーンから読み出す。

例示の実装形態は、さらに、ローカルネットワーク、ステージングネットワーク及び本番システムのネットワークが存在し得る分散環境も含む。各環境は、以下を含み得る異なる目的のために使用される。ローカルネットワークは、各組織でテストケースを実行するように構成されたローカル段階用の環境である。ステージングネットワークは、組織を越えてテストケースを実行するように構成されたステージング段階用の環境である。本番システムのネットワークは、本番システムのサービスとしてブロックチェーンアプリケーションを実行するように構成された本番システムの環境である。すべての組織は、すべての段階に対応できる環境を有する。すべての組織は、これらの環境において自身でテストを実行するので、テストの結果は、各組織が信頼することができる。

第１の例示の実装形態では、パーミッションドブロックチェーンアプリケーションの継続的デリバリのための方法及び装置を説明する。本明細書で説明するように、３つのネットワーク（ローカルネットワーク、ステージングネットワーク、本番システムのネットワーク）を含むシステムは、ブロックチェーンを利用することにより、本番システムのリポジトリ及び独立して管理される複数のエンティティ（すなわち、本明細書で説明する組織）それぞれへのソースコードのデプロイを管理及び検証するために利用される。本明細書で説明するように、法人によるデプロイのためのソースコードの送信のために、ソースコードを、図１、２及び１０に示すように、独立して管理される複数の法人のそれぞれにローカルな第１のネットワークでテストする。テストが、図１０の処理を通して有効であるとブロックチェーンで検証された場合、図１、図３、図４及び図１１に示すように、独立して管理される複数の法人のそれぞれにわたってテストを検証するために、第２のネットワークでステージングが実行される。ブロックチェーン内の、独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、ソースコードは、図１及び図１２に示すように、独立して管理される複数の法人のそれぞれにソースコードをデプロイするように構成された第３のネットワークにおいてデプロイされ、それによって、独立して管理される複数の法人からの第３のネットワークにおけるソースコードのデプロイが成功した旨の検証のために、ソースコードは本番システムのリポジトリにデプロイすることができる。

上述の例示の実装形態を通して、ソースコードは、それらのローカルネットワークにおいて各組織によって独立して検証され、次に、検証の結果は、ステージングネットワークにおいて組織間で検証され、その後、ソースコードが本番システムのリポジトリにデプロイされる前に、本番システムのネットワーク内ですべての組織によってデプロイを検証することができる。このようにして、ソースコードのデプロイの有効性を信頼するために、単一の法人に依存する必要はなく、各組織は、それらのローカルネットワーク上でデプロイを独立して検証することができ、ステージングネットワーク上で他の組織のデプロイを検証することができる。

さらに、第１のネットワーク上でのソースコードのテスト、第２のネットワーク上でのステージング、第３のネットワーク上でのソースコードのデプロイは、図１０〜図１２に示すような順で実行して、単一の法人がソースコードのデプロイにおいて単一の信頼ポイントとならないようにすることができる。

本明細書で説明するように、独立して管理される複数の法人のそれぞれにローカルな第１のネットワーク上のソースコードのテストは、図１０のフローに示すように、ソースコードをテストリポジトリにデプロイすること、独立して管理される複数の法人のそれぞれにローカルな第１のネットワーク上でソースコードのテストを実行すること、そして独立して管理される複数の法人から成功であるとして提供される第１のネットワーク上でのソースコードのテストの結果に対し、そのブロックチェーンでのテスト結果を有効であるとして検証することを含んでもよい。図１０のフローは、図３に示すように、テストツール１０４のプロセッサ３０４によって実行される。

本明細書で説明するように、独立して管理される複数の法人のそれぞれにわたってテストを検証するために第２のネットワーク上でステージングを実行することは、図１１のフローに示すように、独立して管理される複数の法人間のスマートコントラクトを介して、第２のネットワーク上のソースコードのテストを実行することと、テストが成功することを示すスマートコントラクトの一部に対し、テストが成功したことを示すスマートコントラクトのうちの一部に関連付けられた独立して管理される複数の法人のうちの一部の間のブロックチェーンに署名を実行することと、その署名実行により得られた署名を本番システムのリポジトリにマージすることと、を含んでもよい。図１１のフローは、図４に示すように、テストブロックチェーンノード１０５のプロセッサ４０４によって実行することができる。

本明細書で説明するように、独立して管理される複数の法人のそれぞれにソースコードをデプロイするように構成された第３のネットワークにおいてソースコードをデプロイすることは、図１２に示すように、ステージングの結果に関連付けられた本番システムのリポジトリから独立して管理される複数の法人のマージされた署名を取得することと、マージされた署名をブロックチェーンにデプロイすることと、ソースコードを独立して管理される複数の法人のそれぞれにデプロイすることと、複数の法人のそれぞれへのソースコードのデプロイの成功を検証するために、本番システムのリポジトリ内でソースコードのデプロイを維持することと、を含んでもよい。図１２のフローは、図３及び図４からのプロセッサ３０４及び４０４で実行されるＣＤマネージャ４１０及びＣＤドライバ３０８によって駆動することができる。

図１は、例示の実装形態によるブロックチェーンネットワークトポロジのシステムアーキテクチャの一例を示す。システム１００は、３つの環境、すなわちローカルネットワーク１０１（１）〜１０１（３）、ステージングネットワーク１０２、及び本番システムのネットワーク１０３を含む。

ブロックチェーンネットワークに参加する各組織はそれ自身のローカルネットワークを有するので、複数のローカルネットワーク１０１（１）〜１０１（３）が存在する。例えば、組織１はローカルネットワーク１０１（１）を有し、組織２はローカルネットワーク１０１（２）を有し、組織３はローカルネットワーク１０１（３）を有する。この実施例では、３つのローカルネットワークを有する３つの組織（各組織に１つずつ）が存在するが、本開示は、これに限定されず、任意の数の組織及びローカルネットワークを、所望の実装形態に従って使用することができる。ローカルネットワークの構造について、以下でさらに詳細に説明する。

ステージングネットワーク１０２は、テストツール１０４（１）〜１０４（３）と、テストブロックチェーンノード１０５（１）〜１０５（３）とを有する。各組織は、少なくとも１つのテストツール１０４（１）〜１０４（３）と、１つのテストブロックチェーンノード１０５（１）〜１０５（３）とを有する。例えば、組織１は、テストツール１０４（１）及びテストブロックチェーンノード１０５（１）を有する。組織２は、テストツール１０４（２）とテストブロックチェーンノード１０５（２）を有する。

本番システムのネットワーク１０３は、動作ツール１０６（１）〜１０６（３）及びブロックチェーンノード１０７（１）〜１０７（３）を有する。いずれの組織も、少なくとも１つの動作ツール１０６（１）〜１０６（３）と、１つのブロックチェーンノード１０７（１）〜１０７（３）とを有する。例えば、組織１は、動作ツール１０６（１）とブロックチェーンノード１０７（１）とを有する。組織２は、動作ツール１０６（２）とブロックチェーンノード１０７（２）とを有する。

システム１００には、テストリポジトリ１０８及び本番システムのリポジトリ１０９の２つのリポジトリが存在する。テストリポジトリ１０８は、ローカルネットワーク及びステージングネットワークにおけるテスト用のアプリケーションコード、コンフィギュレーションデータ、テストコード及びテストデータなどのアーチファクトを格納する。本番システムのリポジトリ１０９は、本番システムのネットワークにおける動作のためのアプリケーションコード及びコンフィギュレーションデータなどのアーチファクトを格納する。すべてのコンポーネントは、ネットワーク１１０を介して接続される。

図２は、例示の実装形態による、ローカルネットワークのシステム構造の一例を示す。この例では、ローカルネットワーク１０１（１）が図示されているが、ローカルネットワークのすべてが同様のアーキテクチャを有することもできる。ローカルネットワーク１０１（１）は、テストツール１０４（Ｌ１）及びテストブロックチェーンノード１０５（Ｌ１−１）、１０５（Ｌ１−２）、１０５（Ｌ１−３）を含む。ローカルネットワークは、各組織によって実行されるビルドおよびテストのために使用される。ローカルネットワークは、各組織に対して独立したブロックチェーンネットワークである。例えば、ローカルネットワーク１０１（１）は、組織１用のブロックチェーンネットワークである。ローカルネットワーク１０１（１）は、組織１によって動作されるテストツール１０４（Ｌ１）を有する。ローカルネットワーク１０１（１）は、組織１によって動作される複数のテストブロックチェーンノード１０５（Ｌ１〜１）、（Ｌ１〜２）及び（Ｌ１〜３）も有する。

図３は、例示の実装形態による、テストツール１０４の物理的構成の一例を示す。テストツール１０４は、図１に示すように、テストツール１０４（１）〜１０４（３）についての基礎となる構成を示している。テストツール１０４は、メモリ３０１、ローカルストレージ３０２、通信インターフェース（単数又は複数）３０３、プロセッサ（単数又は複数）３０４、及びＩ／Ｏデバイス（単数又は複数）３０５を含む。ローカルストレージ３０２は、ＣＤドライバ３０８、署名アプリケーション３０７及びオペレーティングシステム３０６を含む。

図４は、例示の実装形態によるテストブロックチェーンノード１０５の物理的構成の一例を示す。テストブロックチェーンノード１０５は、メモリ４０１、ローカルストレージ４０２、通信インターフェース（単数又は複数）４０３、プロセッサ（単数又は複数）４０４及びＩ／Ｏデバイス（単数又は複数）４０５を含む。ローカルストレージ４０２は、ＣＤマネージャ４１０、スマートコントラクト（単数又は複数）４０９、台帳４０８、ブロックチェーンプログラム（単数又は複数）４０７及びオペレーティングシステム４０６を含む。台帳４０８は、ジョブ定義テーブル５００と、状態テーブル６００と、ログテーブル７００とを含む。

図５は、例示の実装形態によるジョブ定義テーブル５００のデータ構造の一例を示す。このテーブルは、台帳４０８に格納される。ジョブ定義５００は、パイプライン内の一連のジョブを定義する。各行は、ジョブの定義を示す。列５０１は、一意の識別子を各ジョブに割り当てる、パイプライン内のｊｏｂＩＤを示す。列５０２は、ジョブが成功裏に終了したときのジョブの状態を示す。列５０３は、ｎｅｘｔＪｏｂＩＤを示しており、これは、現在のジョブの後に実行されるジョブのｊｏｂＩＤを示す。列５０４は、どの組織が次のジョブを実行するかを示すａｓｓｉｇｎＰｏｌｉｃｙを示す。

図６は、状態テーブル６００のデータ構造の一例を示す。このテーブルは、ＣＤマネージャ４１０によって台帳４０８内に作成される。状態テーブル６００は、パイプラインにおける状態を示す。ＣＤマネージャ４１０が状態を変更すると、各行は更新される。行６０１は、ｃｈａｎｇｅＩＤを示し、これは、パイプラインのインスタンスを識別するために使用される。コードがテストリポジトリに提出されると、そのインスタンスに対して新しいｃｈａｎｇｅＩＤが生成される。行６０２は、パイプラインにおける状態を示す。この値は、パイプラインの進捗状況に応じて、ジョブ定義テーブル５００の状態５０２から選択される。行６０３は、状態が更新されたときの更新時間を示す。

図７は、例示の実装形態による、ログテーブル７００のデータ構造の一例を示す。このテーブルは、ＣＤマネージャ４１０によって台帳４０８内に作成される。ログテーブル７００は、パイプライン全体にわたって実行されるジョブの結果を格納する。各行は、ＣＤマネージャ４１０がジョブの結果を更新するときに作成される。行７０１は、パイプラインのインスタンスのｃｈａｎｇｅＩＤを示す。行７０２は、実行されるｊｏｂＩＤを示す。行７０３は、ジョブを実行した組織を示すｏｒｇＩＤを示す。行７０４は、ジョブの結果を示す。この値は、ジョブの結果に応じて成功又は失敗に設定される。行７０５は、ログが更新されたときの更新時間を示す。

図８は、例示の実装形態による、ＣＤドライバ３０８の処理の一例のフロー図を示す。ＣＤドライバ３０８は、ＣＤドライバ３０８が受信するイベントに従って、テストの実行、アーチファクトの署名、アーチファクトのマージ及びアーチファクトのデプロイを要求する。ＣＤドライバ３０８はまた、トランザクション提案メッセージをＣＤマネージャ（単数又は複数）４１０に送信し、応答を受信する。

手順は８０１から開始する。ＣＤドライバ３０８の起動時には、登録するイベントの名前を受信する。ＣＤドライバ３０８は、すべての組織によって実行される。ＣＤドライバ３０８の各インスタンスは、組織の名前を有する。８０２において、ＣＤドライバ３０８は、イベントについて登録する。８０３において、ＣＤドライバ３０８は、ネットワーク１１０上のイベントをリッスンし、イベントを受信するまで待機する。８０４において、ＣＤドライバ３０８はイベントを受信する。８０５において、ＣＤドライバ３０８は、受信されたイベント内のａｓｓｉｇｎｅｅフィールドの値をチェックする。ＣＤドライバ３０８を実行する組織がａｓｓｉｇｎｅｅに一致するか又はａｓｓｉｇｎｅｅが空の場合（Ｙｅｓ）、フローは、８０６に進む。ＣＤドライバ３０８を実行する組織が、ａｓｓｉｇｎｅｅと一致しない場合（Ｎｏ）、フローは、８０３に戻って次のイベントを待つ。

８０６において、ＣＤドライバ３０８は、受信したイベント内のｅｖｅｎｔｎａｍｅフィールドの値をチェックする。ｅｖｅｎｔｎａｍｅが８０２から決定された登録イベントの名前と一致する場合（Ｙｅｓ）、フローは８０７に進み、そうでない場合は（Ｎｏ）、フローは８０３に戻り、次のイベントを待つ。

８０７において、ＣＤドライバ３０８は、受信されたイベント内のｅｖｅｎｔｎａｍｅフィールドの値をチェックして、受信したイベントに基づいて処理をルーティングする。ｅｖｅｎｔｎａｍｅが「ｕｐｄａｔｅＬｏｃａｌ」である場合には、フローは８０８に進む。ｅｖｅｎｔｎａｍｅが「ｕｐｄａｔｅＳｔａｇｉｎｇ」である場合には、フローは８１０に進む。ｅｖｅｎｔｎａｍｅが「ｕｐｄａｔｅＳｉｇｎｉｎｇ」である場合には、フローは８１１に進む。ｅｖｅｎｔｎａｍｅが「ｕｐｄａｔｅＭｅｒｇｅ」である場合には、フローは８１２に進む。ｅｖｅｎｔｎａｍｅが「ｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔ」である場合には、フローは８１３に進む。ｅｖｅｎｔｎａｍｅが上述したものと一致しない場合、フローは８１４に進む。

８０８において、ＣＤドライバ３０８は、ローカルネットワークにおけるテスト実行を要求する。異なる組織によって管理される複数のローカルネットワーク１０１（１）〜１０１（３）が存在する。ＣＤドライバ３０８は、組織の名前を有する。ＣＤドライバ３０８は、その組織に対応するローカルネットワークに要求メッセージを送信する。例えば、組織１によって動作されるＣＤドライバ３０８は、組織１のローカルネットワーク１０１（１）に要求メッセージを送信する。要求を送信した後、テストは、ローカルネットワーク１０１で実行される。ＣＤドライバ３０８は、そのローカルネットワークからの結果が受信されるまで待機する。

８０９において、ＣＤドライバ３０８は、イベントからの結果を受信する。

８１０において、ＣＤドライバ３０８は、ステージングネットワーク１０２におけるテスト実行を要求する。リクエストを送信した後、ステージングネットワーク１０２においてテストが実行される。ＣＤドライバ３０８は、ステージングネットワーク１０２からの結果が受信されるまで待機する。

８１１において、ＣＤドライバ３０８は、アーチファクトに対する署名を要求する。すべての組織は、テストツール１０４内に署名アプリケーション３０７を有する。ＣＤドライバ３０８は、同一の組織によって管理される署名アプリケーション３０７に要求メッセージを送信する。例えば、組織１によって動作されるＣＤドライバ３０８は、テストツール１０４（１）に対応するように組織１の署名アプリケーション３０７に要求メッセージを送信する。要求を送信した後、デジタル署名はアーチファクトに入れられる。ＣＤドライバ３０８は、署名アプリケーション３０７からの結果が受信されるまで待機する。

８１２において、ＣＤドライバ３０８は、アーチファクトのマージを要求する。ＣＤドライバ３０８は、マージ要求メッセージを用いて、本番システムのリポジトリ１０９にアーチファクトを送信する。要求を送信した後、アーチファクトは、本番システムのリポジトリ１０９にマージされる。ＣＤドライバ３０８は、本番システムのリポジトリ１０９からの結果が受信されるまで待機する。

８１３において、ＣＤドライバ３０８は、アーチファクトのデプロイを要求する。すべての組織は、本番システムのネットワーク１０３内のブロックチェーンノード１０７（１）〜１０７（３）を有する。これらのノードは、デプロイのターゲットである。デプロイは、各組織によって行われる。ＣＤドライバ３０８は、同一組織で管理されている動作ツール１０６（１）〜１０６（３）に要求メッセージを送信する。例えば、組織１によって動作されるＣＤドライバ３０８は、組織１の動作ツール１０６（１）に要求メッセージを送信する。

要求を送信した後、動作ツールは、その管理下でブロックチェーンノード（単数又は、複数）にアーチファクトをデプロイする。ＣＤドライバ３０８は、動作ツールからの結果を受信するまで待機する。

８１４において、ＣＤドライバ３０８は、トランザクション提案メッセージを生成する。トランザクション提案メッセージは、ｃｈａｎｇｅＩＤ、ｊｏｂＩＤ、組織及び結果を含む。

トランザクション提案メッセージの構造例は、以下の通りである。
｛
“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，
“ｊｏｂ＿ｉｄ”：“ｕｐｄａｔｅＬｏｃａｌ”，
“ｏｒｇａｎｉｚａｔｉｏｎ”：“ｏｒｇ１”
“ｒｅｓｕｌｔ”：“ｓｕｃｃｅｓｓ”
｝

８１５において、ＣＤドライバ３０８は、提案メッセージをＣＤマネージャ（単数又は複数）４１０に送信する。すべての組織は、ステージングネットワーク１０３内のテストブロックチェーンノード（単数又は複数）１０５上にＣＤマネージャ（単数又は複数）４１０を有する。ＣＤドライバ３０８は、ステージングネットワーク１０３内のすべてのＣＤマネージャ（単数又は複数）に提案メッセージを送信する。ＣＤドライバ３０８は、ＣＤマネージャ（単数又は複数）４１０から応答を受信するまで待機する。

８１６において、ＣＤドライバ３０８は、ＣＤマネージャ（単数又は複数）４１０からの応答を受信し、８１７において処理を終了する。

図９は、例示の実装形態による、ＣＤマネージャ４１０の処理の一例を示すフロー図である。ＣＤマネージャ４１０は、要求メッセージを受信し、ジョブの結果を更新し、ジョブの結果を検証し、イベントを発信し、応答メッセージを返信する。この処理は、要求メッセージ内のｊｏｂＩＤに応じて変化する。

フローは、９０１から開始される。９０２において、ＣＤマネージャ４１０は、ＣＤドライバ３０８から要求メッセージを受信する。ＣＤマネージャ４１０は、要求メッセージからデータを抽出する。

９０３において、ＣＤマネージャ４１０は、要求に対するジョブ定義を取得する。ＣＤマネージャ４１０は、要求メッセージから抽出されたｊｏｂＩＤを用いてジョブ定義テーブル５００を探す。ＣＤマネージャ４１０は、ｊｏｂＩＤの状態、ｎｅｘｔＪｏｂＩＤ及びａｓｓｉｇｎｅｅを取得する。

９０４において、ＣＤマネージャ４１０は、要求された変更を実行するためにジョブ状態が正しいかどうかを検証する。ＣＤマネージャ４１０は、要求メッセージから抽出されたｃｈａｎｇｅＩｄを有する状態テーブル６００を探す。ＣＤマネージャ４１０は、要求メッセージが正しい状態を有するかどうかをチェックする。状態が正しい場合（Ｙｅｓ）、フローは９０５に進む。

状態が正しくない場合（Ｎｏ）、フローは９１９に進む。要求は無効であるので、処理は何も更新することなく終了する。

９０５において、ＣＤマネージャ４１０は、要求メッセージから抽出されたｊｏｂＩＤの値をチェックする。ｊｏｂＩＤがｓｔａｒｔＬｏｃａｌ、ｓｔａｒｔＳｔａｇｉｎｇ、ｓｔａｒｔＳｉｇｎｉｎｇ又はｓｔａｒｔＤｅｐｌｏｙｍｅｎｔと一致する場合、フローは９１６に進む。ｊｏｂＩＤがｕｐｄａｔｅＬｏｃａｌ、ｕｐｄａｔｅＳｉｇｎｉｎｇ又はｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔと一致する場合、フローは９０６に進む。ｊｏｂＩＤがｕｐｄａｔｅＳｔａｔｉｎｇ又はｕｐｄａｔｅＭｅｒｇｅと一致する場合、フローは９０９に進む。ｊｏｂＩＤがｖｅｒｉｆｙＬｏｃａｌ又はｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔと一致する場合、フローは９１０に進む。ｊｏｂＩＤがｖｅｒｉｆｙＳｔａｔｉｎｇ又はｖｅｒｉｆｙＭｅｒｇｅと一致する場合、フローは９１４に進む。

９０６において、ＣＤマネージャ４１０は、組織によって実行されるジョブの結果を更新する。各組織は、ローカルネットワークにおけるテストのための動作を実行し、デジタル署名をアーチファクトに置き、アーチファクトを本番システムのネットワークにデプロイする。その結果、各組織は、ジョブの独自の結果を有する。ＣＤドライバ３０８がＣＤマネージャ４１０に要求メッセージを送信すると、ジョブの結果は、各組織による要求メッセージに含まれる。ＣＤマネージャ４１０は、要求メッセージからジョブの結果を抽出し、ログテーブル７００に新たな記録を入れる。

９０７において、ＣＤマネージャ４１０は、ブロックチェーンネットワーク内の組織についてのリストを取得する。組織のリストは、ブロックチェーンプログラム（単数又は複数）４０７によって維持され、データは、台帳４０８内に存在する。ＣＤマネージャ４１０は、台帳４０８にアクセスすることによって組織のリストを取得する。

９０８において、ＣＤマネージャ４１０はログテーブル７００を探し、ログテーブル７００がすべての組織からの結果を有するかどうかをチェックする。ログテーブル７００内にすべての組織からのすべての結果が存在する場合、フローは９１６に進む。ある組織からの結果が欠落している場合、フローは９１８に進む。すべての組織がジョブ結果を提出するまで、ＣＤマネージャ４１０は、状態を更新するのを待機する。

９０９において、ＣＤマネージャ４１０は、ジョブの結果を更新する。一例では、ステージングネットワークにおけるテスト及びアーチファクトのマージは、システム全体にわたって一度動作される。システム内には１つの結果が存在する。ＣＤドライバ３０８がＣＤマネージャ４１０に要求メッセージを送信すると、ジョブ結果は要求メッセージに含まれる。ＣＤマネージャ４１０は、要求メッセージからジョブ結果を抽出し、ログテーブル７００に新しい記録を配置し、９１６に進む。

９１０において、ＣＤマネージャ４１０は、ｃｈａｎｇｅＩＤ及びｊｏｂＩＤを有するログテーブル７００を探し、結果のリストを取得する。９１１において、ＣＤマネージャ４１０は、９１０で選択されたすべての結果が、結果の値として成功を有するかどうかを検証する。ローカルネットワーク及びデプロイにおけるテストのために、ログテーブル７００は、すべての組織からのジョブ結果のセットを有している。ＣＤパイプラインの状態を変更する前に、ＣＤマネージャ４１０は、すべての組織がそれらのジョブを成功裏に終えたかどうかをチェックする。すべてのジョブが成功した場合（Ｙｅｓ）、ＣＤマネージャ４１０は、状態を変更することができ、９１２に進むことができる。ジョブの失敗が存在する場合（Ｎｏ）、ＣＤマネージャ４１０は、状態の変更を拒否し、９１３に進む。９１２において、ＣＤマネージャ４１０は、「ｖｅｒｉｆｉｅｄ」を値として状態に設定する。９１３において、ＣＤマネージャ４１０は、「ｒｅｊｅｃｔｅｄ」を値として状態に設定する。

９１４において、ＣＤマネージャ４１０は、ｃｈａｎｇｅＩＤ及びｊｏｂＩＤを有するログテーブル７００を探し、その結果を取得する。９１５において、ＣＤマネージャ４１０は、９１４において選択された結果が、結果の値として成功を有するかどうかを検証する。ステージングネットワークにおけるテストとアーチファクトのマージのために、ログテーブル７００はジョブを格納する。ＣＤパイプラインの状態を変更する前に、ＣＤマネージャ４１０は、ジョブが成功裏に終了したかどうかをチェックする。ジョブが成功した場合（Ｙｅｓ）、ＣＤマネージャ４１０は、状態を変更することができ、９１２に進む。ジョブが失敗した場合（Ｎｏ）、ＣＤマネージャ４１０は、状態の変更を拒否し、９１３に進む。

９１６において、ＣＤマネージャ４１０は、状態テーブル６００内の状態を更新する。前のステップで状態が「ｒｅｊｅｃｔｅｄ」に設定されている場合には、状態テーブルも「ｒｅｊｅｃｔｅｄ」として更新される。他の場合には、状態の値はジョブ定義内の状態に等しい。

９１７において、ＣＤマネージャ４１０は、次のジョブについてのパラメータを渡すイベントを設定する。イベントは、ｅｖｅｎｔｎａｍｅ及びペイロードを含む。ペイロードは、ｃｈａｎｇｅＩＤ及びａｓｓｉｇｎｅｅを含む。

トランザクション提案メッセージの構造例は、以下の通りである。
｛
“ｅｖｅｎｔｎａｍｅ”：“ｕｐｄａｔｅＭｅｒｇｅ”，
“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，
“ａｓｓｉｇｎｅｅ”：“０ｒｇ１”
｝

ｅｖｅｎｔｎａｍｅの値は、ジョブ定義内のｎｅｘｔＪｏｂＩＤに等しい。

要求メッセージから抽出されたｃｈａｎｇｅＩｄの値は、イベント内のｃｈａｎｇｅＩＤに渡される。ａｓｓｉｇｎｅｅの値は、ジョブ定義におけるａｓｓｉｇｎＰｏｌｉｃｙに従って変更される。ａｓｓｉｇｎＰｏｌｉｃｙがＡＬＬ＿ＯＲＧである場合、ａｓｓｉｇｎｅｅは空値に設定される。ａｓｓｉｇｎＰｏｌｉｃｙが「ＯＮＥ＿ＯＲＧ」である場合、ａｓｓｉｇｎｅｅは、ランダムに選択された組織名に設定される。

９１８において、ＣＤマネージャ４１０は、応答を返信する。この応答は、状態コード及びメッセージを含む。次に、９１９において、ＣＤマネージャ４１０は、処理を終了する。

図１０は、例示の実装形態による、ローカルステージの処理の一例を示すシーケンス図である。ローカルステージでは、アーチファクトはテストリポジトリ１０８にコミットされ、パイプラインは開始され、異なる組織によって所有されるすべてのローカルネットワーク１０１においてテストが実行され、結果はブロックチェーンに記録され、その結果はＣＤマネージャ（単数又は複数）４１０によって検証される。

１００１において、アーチファクトは、テストリポジトリ１０８にプッシュされる。通常、コンソールは、開発者がコードを書き込む機械からアーチファクトを送信するために使用する。１００２において、テストリポジトリ１０８は、１００１において開始された要求に対するｃｈａｎｇｅＩＤを生成する。ｃｈａｎｇｅＩＤはパイプラインの状態を追跡するために使用する。１００３において、テストリポジトリ１０８は、ｓｔａｒｔＬｏｃａｌのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｓｔａｒｔＬｏｃａｌ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ１”｝

ｃｈａｎｇｅＩＤは、１００２で生成されたものと等しい。ａｓｓｉｇｎｅｅは、アーチファクトをテストリポジトリ１０８にプッシュした組織となる。イベントは、ネットワーク１１０全体を通じて同報される。

１００４において、ＣＤドライバ３０８はイベントを待っているので、ＣＤドライバ３０８はｓｔａｒｔＬｏｃａｌのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、受信したイベントがＣＤドライバ３０８を実行する組織に割り当てられているかをチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップを実行し続ける。割り当てられていない場合、ＣＤドライバ３０８は次のステップに移行せず、イベントを再び受信するために待機する。

１００５において、ＣＤドライバ３０８は、ｓｔａｒｔＬｏｃａｌに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｓｔａｒｔＬｏｃａｌ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２内の各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１００６において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、状態テーブル６００内の状態をｌｏｃａｌＴｅｓｔＳｔａｒｔｅｄに更新し、ｕｐｄａｔｅＬｏｃａｌのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｕｐｄａｔｅＬｏｃａｌ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“”｝

１００７において、ＣＤドライバ３０８は、ｕｐｄａｔｅＬｏｃａｌのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。ａｓｓｉｇｎｅｅのフィールドは空であるため、すべての組織が割り当てられる。

１００８において、ＣＤドライバ３０８は、対応するローカルネットワーク（単数又は複数）におけるテスト実行を要求する。ＣＤドライバ３０８は、現在のＣＤドライバ３０８の所有者と一致する組織が所有するローカルネットワークに要求メッセージを送信する。１００９において、対応するローカルネットワークは、一連のテストを実行し、その結果をＣＤドライバ３０８に返信する。テストが成功した場合には、返される値は「成功」である。テストが失敗した場合には、返される値は「失敗」である。

１０１０において、ＣＤドライバ３０８は、ｕｐｄａｔｅＬｏｃａｌに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｕｐｄａｔｅＬｏｃａｌ”，“ｏｒｇａｎｉｚａｔｉｏｎ”：“ｏｒｇ１”，“ｒｅｓｕｌｔ”：“ｓｕｃｃｅｓｓ”｝

１００９でのテスト結果は、結果フィールドの値として与えられる。ＣＤドライバ３０８は、ステージングネットワーク１０２において各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１０１１において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、テストの結果をログテーブル７００に入れる。これが最後の組織からの要求である場合、ＣＤマネージャ（単数又は複数）は、状態テーブル６００内の状態をｌｏｃａｌＴｅｓｔＥｎｄｅｄに更新し、ｖｅｒｉｆｙＬｏｃａｌのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｖｅｒｉｆｙＬｏｃａｌ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ２”｝

１０１２において、ＣＤドライバ３０８は、ｖｅｒｉｆｙＬｏｃａｌのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は次のステップに継続する。割り当てられていない場合、ＣＤドライバ３０８は、次のステップに継続せず、再びイベントを受信するために待機する。

１０１３において、ＣＤドライバ３０８は、ｖｅｒｉｆｙＬｏｃａｌに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｖｅｒｉｆｙＬｏｃａｌ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２において各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１０１４において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、すべての組織がそれらのジョブを成功裏に完了したかをチェックする。すべてのテストが成功した場合、ＣＤマネージャ（単数又は複数）４１０は、状態テーブル６００内の状態をｌｏｃａｌＴｅｓｔＶｅｒｉｆｉｅｄに更新し、ｓｔａｒｔＳｔａｇｉｎｇのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｓｔａｒｔＳｔａｇｉｎｇ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ２”｝

失敗したテストが存在する場合、ＣＤマネージャ（単数又は複数）４１０は、状態テーブル６００内の状態を拒否されたとして更新し、エラーイベントを発信する。エラーイベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｅｒｒｏｒ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｍｅｓｓａｇｅ”：“ｖｅｒｉｆｙＬｏｃａｌ ｉｓ ｒｅｊｅｃｔｅｄ．”｝

図１１は、例示の実装形態による、ステージング段階の処理の一例を示すシーケンス図である。ステージング段階において、テストはステージングネットワーク１０２において実行され、結果はブロックチェーンに記録され、その結果はＣＤマネージャ（単数又は複数）４１０によって検証される。その後、アーチファクトのデジタル署名はすべての組織から収集され、署名されたアーチファクトは本番システムのリポジトリ１０９にプッシュされる。

１１０１において、ＣＤドライバ３０８は、ｓｔａｒｔＳｔａｇｉｎｇのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップに進む。割り当てられていない場合、ＣＤドライバ３０８は、次のステップに進まず、イベントを再び受信するために待機する。

１１０２において、ＣＤドライバ３０８は、ｓｔａｒｔＳｔａｇｉｎｇに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｓｔａｒｔＳｔａｇｉｎｇ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２において各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１１０３において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、状態テーブル６００内の状態をｓｔａｇｉｎｇＴｅｓｔＳｔａｒｔｅｄに更新し、ｕｐｄａｔｅＳｔａｇｉｎｇのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｕｐｄａｔｅＳｔａｇｉｎｇ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ３”｝

１１０４において、ＣＤドライバ３０８は、ｕｐｄａｔｅＳｔａｇｉｎｇのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は次のステップに継続する。割り当てられていない場合、ＣＤドライバ３０８は次のステップに進まず、イベントを再び受信するために待機する。

１１０５において、ＣＤドライバ３０８は、ステージングネットワーク１０２におけるテスト実行を要求する。ＣＤドライバ３０８は、一連のテストケースを開始し、スマートコントラクト（単数又は複数）４０９にリクエストを送信する。１１０６において、スマートコントラクト（単数又は複数）４０９は一連のテストを実行し、結果をＣＤドライバ３０８に返す。テストが成功した場合には、返される値は「成功」である。テストが失敗した場合には、返される値は「失敗」である。

１１０７において、ＣＤドライバ３０８は、ｕｐｄａｔｅＳｔａｇｉｎｇに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｕｐｄａｔｅＳｔａｇｉｎｇ”，“ｏｒｇａｎｉｚａｔｉｏｎ”：“ｏｒｇ３”，“ｒｅｓｕｌｔ”：“ｓｕｃｃｅｓｓ”｝

１１０６からのテスト結果を、結果フィールドの値として与えられる。ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１１０８において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、テストの結果をログテーブル７００に入れ、状態テーブル６００内の状態をｓｔａｇｉｎｇＴｅｓｔＥｎｄｅｄに更新し、ｖｅｒｉｆｙＳｔａｇｉｎｇのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｖｅｒｉｆｙＳｔａｇｉｎｇ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ２”｝

１１０９において、ＣＤドライバ３０８は、ｖｅｒｉｆｙＳｔａｇｉｎｇのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップに継続する。割り当てられていない場合、ＣＤドライバ３０８は、次のステップに継続せず、イベントを再び受信するために待機する。

１１１０において、ＣＤドライバ３０８は、ｖｅｒｉｆｙＳｔａｇｉｎｇに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの例は以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｖｅｒｉｆｙＳｔａｇｉｎｇ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１１１１において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、ジョブが成功裏に終了したかどうかをチェックする。ジョブが成功した場合、ＣＤマネージャ（単数又は複数）４１０は状態テーブル６００内の状態をｓｔａｇｉｎｇＴｅｓｔＶｅｒｉｆｉｅｄに更新し、ｓｔａｒｔＳｉｇｎｉｎｇのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｓｔａｒｔＳｉｇｎｉｎｇ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ３”｝

ジョブが失敗した場合、ＣＤマネージャ（単数又は複数）４１０は、状態テーブル６００内の状態をｒｅｊｅｃｔｅｄに更新し、エラーイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｅｒｒｏｒ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｍｅｓｓａｇｅ”：“ｖｅｒｉｆｙＳｔａｇｉｎｇ ｉｓ ｒｅｊｅｃｔｅｄ．”｝

１１１２において、ＣＤドライバ３０８は、ｓｔａｒｔＳｉｇｎｉｎｇのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップに継続する。割り当てられていない場合、ＣＤドライバ３０８は、次のステップに継続せず、イベントを再び受信するために待機する。

１１１３において、ＣＤドライバ３０８は、ｓｔａｒｔＳｉｇｎｉｎｇに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｓｔａｒｔＳｉｇｎｉｎｇ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１１１４において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、状態テーブル６００内の状態をｓｉｇｎＳｔａｒｔｅｄに更新し、ｕｐｄａｔｅＳｉｇｎｉｎｇのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｕｐｄａｔｅＳｉｇｎｉｎｇ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“”｝

１１１５において、ＣＤドライバ３０８は、ｕｐｄａｔｅＳｉｇｎｉｎｇのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。ａｓｓｉｇｎｅｅのフィールドは空であるため、すべての組織が割り当てられる。

１１１６において、ＣＤドライバ３０８は、アーチファクトの署名を要求する。ＣＤドライバ３０８は、現在のＣＤドライバ３０８の所有者と一致する組織が所有する署名アプリケーション３０７に要求メッセージを送信する。

１１１７において、署名アプリケーション３０７は、デジタル署名をアーチファクトに付けて、署名をＣＤドライバ３０８に返信する。

１１１８において、ＣＤドライバ３０８は、ｕｐｄａｔｅＳｉｇｎｉｎｇに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｕｐｄａｔｅＬｏｃａｌ”，“ｏｒｇａｎｉｚａｔｉｏｎ”：“ｏｒｇ１”，“ｓｉｇｎａｔｕｒｅ”：“４３ｕ８１ｌｋｅ５４２ｐａ２３ｐｆｓｄ２４２３９０”｝

１１１７から返信された署名は、署名フィールドの値として入力される。

ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１１１９において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、署名の結果をログテーブル７００に入力する。これが最後の組織からの要求である場合、ＣＤマネージャ（単数又は複数）は、状態テーブル６００内の状態をｓｉｇｎＥｎｄｅｄに更新し、ｕｐｄａｔｅＭｅｒｇｅのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｕｐｄａｔｅＭｅｒｇｅ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ１”｝

１１２０において、ＣＤドライバ３０８は、ｕｐｄａｔｅＭｅｒｇｅのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップに進む。割り当てられていない場合、ＣＤドライバ３０８は、次のステップに継続せず、イベントを再び受信するために待機する。

１１２１において、ＣＤドライバ３０８はアーチファクトのマージを要求する。ＣＤドライバ３０８は、署名されたアーチファクトを有するプッシュ要求を本番システムのリポジトリ１０９に送信する。１１２２において、本番システムのリポジトリ１０９は、受信されたアーチファクトをマージし、応答メッセージをＣＤドライバ３０８に返信する。１１２３において、ＣＤドライバ３０８は、ｕｐｄａｔｅＭｅｒｇｅに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。このようなメッセージの例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｕｐｄａｔｅＭｅｒｇｅ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１１２４において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、状態テーブル６００内の状態をａｒｔｉｆａｃｔＭｅｒｇｅｄに更新し、ｓｔａｒｔＤｅｐｌｏｙｍｅｎｔのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｓｔａｒｔＤｅｐｌｏｙｍｅｎｔ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｏｒｇ３”｝

図１２は、例示の実装形態による、デプロイ段階の処理の一例を示すシーケンス図である。デプロイ段階では、アーチファクトは本番システムのネットワーク１０３にデプロイされ、デプロイの結果はブロックチェーンに記録され、その結果はＣＤマネージャ（単数又は複数）４１０によって検証される。

１２０１において、ＣＤドライバ３０８は、ｓｔａｒｔＤｅｐｌｏｙｍｅｎｔのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップに継続する。割り当てられていない場合、ＣＤドライバ３０８は次のステップに継続せず、イベントを再び受信するために待機する。

１２０２において、ＣＤドライバ３０８は、ｓｔａｒｔＤｅｐｌｏｙｍｅｎｔに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。このようなメッセージの例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｓｔａｒｔＤｅｐｌｏｙｍｅｎｔ”｝

ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１２０３において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、状態テーブル６００内の状態をｄｅｐｌｏｙＳｔａｒｔｅｄに更新し、ｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔのイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“”｝

１２０４において、ＣＤドライバ３０８は、ｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。ａｓｓｉｇｎｅｅのフィールドは空であるため、すべての組織が割り当てられる。

１２０５において、ＣＤドライバ３０８は、動作ツール１０６（１）〜１０６（３）へのアーチファクトのデプロイを要求する。いずれの組織も、それら自身のブロックチェーンノード（単数又は複数）にアーチファクトをデプロイするために、それらに対応する動作ツールを有する。各組織がアーチファクトをデプロイするために、ＣＤドライバ３０８は、現在のＣＤドライバ３０８の所有者と一致する組織が所有する動作ツールに要求メッセージを送信する。１２０６において、動作ツールは、マージされたアーチファクトを本番システムのリポジトリ１０９から取得する。

１２０７において、動作ツールは、アーチファクトをブロックチェーンノード（単数又は複数）にデプロイし、デプロイ結果を受信する。デプロイが成功した場合には、返信される値は「成功」である。デプロイが失敗した場合、返信される値は、「失敗」である。動作ツールはまた、結果をＣＤドライバ３０８に返信する。

１２０８において、ＣＤドライバ３０８は、ｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｕｐｄａｔｅＤｅｐｌｏｙｍｅｎｔ”，“ｒｅｓｕｌｔ”：“ｓｕｃｃｅｓｓ”｝

１２０７からのデプロイの結果が、結果フィールドの値として入力される。ＣＤドライバ３０８は、ステージングネットワーク１０２における各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１２０９において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、デプロイの結果をログテーブル７００に入れる。これが最後の組織からの要求である場合、ＣＤマネージャ（単数又は複数）は、状態テーブル６００内の状態をｄｅｐｌｏｙＥｎｄｅｄに更新し、ｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔのイベントを発信する。このようなイベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“ｏｒｇ３”｝

１２１０において、ＣＤドライバ３０８は、ｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔのイベントを受信する。イベントを受信した後、ＣＤドライバ３０８は、その担当者をチェックする。イベント内のａｓｓｉｇｎｅｅフィールドの値が、このＣＤドライバ３０８を実行する組織と一致する場合に、イベントが割り当てられる。ＣＤドライバ３０８は、次のステップに継続する。割り当てられていない場合、ＣＤドライバ３０８は、次のステップに継続せず、イベントを再び受信するために待機する。

１２１１において、ＣＤドライバ３０８は、ｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔに対するトランザクション提案メッセージを作成し、それをＣＤマネージャ（単数又は複数）４１０に送信する。メッセージの一例は、以下の通りである。
｛“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｊｏｂ＿ｉｄ”：“ｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔ”｝．

ＣＤドライバ３０８は、ステージングネットワーク１０２内の各組織が所有するすべてのＣＤマネージャ（単数又は複数）４１０に要求を送信する。

１２１２において、ＣＤマネージャ（単数又は複数）４１０は、要求を受信し、すべての組織が成功裏にデプロイを終了したかどうかをチェックする。すべてのデプロイが成功した場合、ＣＤマネージャ（単数又は複数）４１０は状態テーブル６００内の状態をｄｅｐｌｏｙＶｅｒｉｆｉｅｄに更新し、終了するイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｆｉｎｉｓｈｅｄ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ａｓｓｉｇｎｅｅ”：“”｝

デプロイの失敗が存在する場合、ＣＤマネージャ（単数又は複数）４１０は、状態テーブル６００内の状態をｒｅｊｅｃｔｅｄに更新し、エラーイベントを発信する。イベントの例は、以下の通りである。
｛“ｅｖｅｎｔｎａｍｅ”：“ｅｒｒｏｒ”，“ｃｈａｎｇｅＩＤ”：“ｃｈａｎｇｅ０５”，“ｍｅｓｓａｇｅ”：“ｖｅｒｉｆｙＤｅｐｌｏｙｍｅｎｔ ｉｓ ｒｅｊｅｃｔｅｄ．”｝

詳細な説明のうちの一部は、コンピュータ内の動作のアルゴリズム及び記号表現に関して提示される。これらのアルゴリズム記述及び記号表現は、データ処理技術の当業者が使用することにより、他の当業者にそれらの技術革新の本質を伝える手段である。アルゴリズムは、所望の終了状態又は結果をもたらす、定義された一連のステップである。例示の実装形態では、実行されるステップは、有形の結果を達成するための有形量の物理的操作を必要とする。

特に記載がない限り、議論から明らかなように、明細書全体を通して「処理」、「演算」、「計算」、「判定」、「表示」などの用語を使用する議論は、物理（電子）量として表されるコンピュータシステムのレジスタ及びメモリ内のデータを演算システムのメモリ、レジスタ、又は他の情報ストレージ、伝送若しくは表示デバイス内の物理量として同様に表される他のデータに、操作及び変換するコンピュータシステム、又は他の情報処理装置のアクション及び処理を含むものであることは理解できよう。

例示の実装形態は、本明細書の動作を実行するための装置に関連する場合もある。この装置は、必要な目的のために特別に構成することができ、あるいは１以上のコンピュータプログラムを選択的に起動又は再構成する１以上の汎用コンピュータを含んでいてもよい。このようなコンピュータプログラムは、コンピュータ可読な格納媒体又はコンピュータ可読な信号媒体などのコンピュータ可読媒体に格納されてもよい。コンピュータ可読格納媒体は、限定されるものではないが、光ディスク、磁気ディスク、読み取り専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイス及びドライブなどの有形媒体、又は任意の別の種類の電子情報を格納するのに適した有形又は非一時的媒体を含んでもよい。コンピュータ可読な信号媒体は、搬送波のような媒体を含んでいてもよい。本明細書で提示されるアルゴリズム及び表示は、いかなる特定のコンピュータ又は他の装置にも本質的に関連するものではない。コンピュータプログラムは、所望の実装形態の操作を実行する命令を含む純粋なソフトウェア実装形態を含んでもよい。

様々な汎用システムを、本明細書の実施例に従ってプログラム及びモジュールと共に使用することができ、又は所望の方法ステップを実行するためのより特化された装置を構築することが便利となる場合もある。さらに、例示の実装形態の説明には、任意の特定のプログラミング言語を参照していない。本明細書に記載された例示の実装形態の教示を実装するために、様々なプログラミング言語を使用することができることは理解できよう。プログラミング言語（単数又は複数）の命令は、１以上の処理装置、例えば中央処理装置（ＣＰＵ）、プロセッサ、又はコントローラによって実行してもよい。

当該技術分野で知られているように、上述した動作は、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアのいくつかの組み合わせによって実行することができる。例示の実装形態の様々な態様は、回路及び論理デバイス（ハードウェア）を使用して実装してもよく、他の態様は、プロセッサによって実行される場合、プロセッサに本出願の実装を実行する方法を実行させる、機械読み取り可能な媒体（ソフトウェア）上に格納された命令を用いて実装してもよい。さらに、本出願のいくつかの例示の実装形態は、ハードウェアのみで実行してもよく、他の例示の実装形態は、ソフトウェアのみで実行してもよい。さらに、記載された様々な機能は、単一のユニット内で実行することができ、又はいくつかの方法でいくつかの構成要素にわたって拡散することができる。ソフトウェアによって実行される場合、方法は、コンピュータ可読媒体上に格納された命令に基づいて、汎用コンピュータなどのプロセッサによって実行してもよい。所望であれば、命令は、圧縮されたフォーマット及び／又は暗号化されたフォーマットで媒体上に格納することができる。

さらに、本出願のその他の実装形態は、本出願の明細書及び教示内容を考慮することによって、当業者には明らかであろう。記載された例示の実装形態の様々な態様及び／又は構成要素は、単独で、又は任意の組み合わせで使用してもよい。本明細書及び例示の実装形態は、単なる例示として考慮され、本発明の真の範囲及び精神は、以下の特許請求の範囲によって示されることを意図するものである。

１０１（１）〜（３） ローカルネットワーク
１０２ ステージングネットワーク
１０３ 本番システムのネットワーク
１０４（１）〜（３） テストツール
１０５（１）〜（３） テストブロックチェーンノード
１０６（１）〜（３） 動作ツール
１０７（１）〜（３） ブロックチェーンノード
１０８ テストリポジトリ
１０９ 本番システムのリポジトリ
１１０ ネットワーク
３０１ メモリ
３０２ ローカルストレージ
３０３ 通信インターフェース
３０４ プロセッサ
３０５ Ｉ／Ｏデバイス
３０６ 動作システム
３０７ 署名アプリケーション
３０８ ＣＤドライバ
４０１ メモリ
４０２ ローカルストレージ
４０８ 台帳
４０９ スマートコントラクト
４１０ ＣＤマネージャ
５００ ジョブ定義
６００ 状態
７００ ログ

Claims (13)

1. ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理する方法であって、
   デプロイのための前記ソースコードの送信のために、
   前記独立して管理される複数の法人のそれぞれにローカルな第１のネットワーク上で前記ソースコードをテストすることと、
   前記ブロックチェーンにおいて有効であるとして検証されたテストの結果に対して、
   第２のネットワークでステージングを実行することにより、前記独立して管理される複数の法人のそれぞれにわたってテストを検証することと、
   ブロックチェーンにおいて独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、前記ソースコードを前記独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークにおいて前記ソースコードをデプロイすることと、を含む方法。
2. 前記第３のネットワークにおける前記ソースコードのデプロイが成功であるという検証を前記独立して管理される複数の法人から得るために、前記ソースコードを前記本番システムのリポジトリにデプロイすることをさらに含む請求項１に記載の方法。
3. 前記独立して管理される複数の法人のそれぞれにローカルな前記第１のネットワーク上の前記ソースコードをテストすることは、
   前記ソースコードをテストリポジトリにデプロイすることと、
   前記独立して管理される複数の法人のそれぞれにローカルな前記第１のネットワーク上で前記ソースコードのテストを実行することと、
   前記独立して管理される複数の法人から成功したとして提供される前記第１のネットワーク上で前記ソースコードの前記テストの結果に関し、前記ブロックチェーンの前記テストの前記結果が有効であることを検証することとを含む請求項１に記載の方法。
4. 前記第２のネットワーク上にステージングすることにより、前記独立して管理される複数の法人のそれぞれにわたって前記テストを検証することは、
   前記独立して管理される複数の法人間のスマートコントラクトを介して、前記第２のネットワーク上で前記ソースコードのテストを実行することと、
   前記テストが成功したことを示す前記スマートコントラクトのうちの一部に関し、前記テストが成功したことを示す前記スマートコントラクトのうちの前記一部に関連付けられた前記独立して管理される複数の法人のうちの一部の間の前記ブロックチェーンへの署名を実行することと、
   署名することから得た署名を前記本番システムのリポジトリへマージすることと、を含む請求項１に記載の方法。
5. 前記ソースコードを前記独立して管理される複数の法人のそれぞれにデプロイするように構成された前記第３のネットワーク内に前記ソースコードをデプロイすることは、
   前記ステージングの結果に関連付けられた前記本番システムのリポジトリから前記独立して管理される複数の法人のマージされた署名を取得することと、
   前記マージされた署名を前記ブロックチェーンにデプロイすることと、
   前記ソースコードを、前記独立して管理される複数の法人のそれぞれにデプロイすることと、
   前記ソースコードの、複数の法人のそれぞれへの成功したデプロイの検証に関し、前記本番システムのリポジトリ内で前記ソースコードのデプロイを維持することと、を含む請求項１に記載の方法。
6. 前記第１のネットワーク上で前記ソースコードをテストすることと、前記第２のネットワーク上でステージングを実行することと、前記第３のネットワーク上で前記ソースコードをデプロイすることとが順に実行される請求項１に記載の方法。
7. ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理する命令を記憶する非一時的なコンピュータ可読媒体であって、前記命令は、
   デプロイのための前記ソースコードの送信のために、
   前記独立して管理される複数の法人のそれぞれにローカルな第１のネットワーク上で前記ソースコードをテストすることと、
   前記ブロックチェーンにおいて有効であるとして検証された前記テストの結果に対して、
   第２のネットワークでステージングを実行することにより、前記独立して管理される複数の法人のそれぞれにわたって前記テストを検証することと、
   前記ブロックチェーン内の、前記独立して管理される複数の法人のそれぞれによって署名される前記ステージングの結果に対して、前記ソースコードを、前記独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークにおいて前記ソースコードをデプロイすることと、を含む非一時的なコンピュータ可読媒体。
8. 前記第３のネットワークにおける前記ソースコードのデプロイが成功であるという検証を前記独立して管理される複数の法人から得るために、前記ソースコードを前記本番システムのリポジトリにデプロイすることをさらに含む請求項７に記載の非一時的なコンピュータ可読媒体。
9. 前記独立して管理される複数の法人のそれぞれにローカルな前記第１のネットワーク上の前記ソースコードをテストすることは、
   前記ソースコードをテストリポジトリにデプロイすることと、
   前記独立して管理される複数の法人のそれぞれにローカルな前記第１のネットワーク上で前記ソースコードのテストを実行することと、
   前記独立して管理される複数の法人から成功したとして提供される前記第１のネットワーク上で前記ソースコードの前記テストの結果に関し、前記ブロックチェーンの前記テストの前記結果が有効であることを検証することとを含む請求項７に記載の非一時的なコンピュータ可読媒体。
10. 前記第２のネットワーク上にステージングすることにより、前記独立して管理される複数の法人のそれぞれにわたってテストを検証することは、
    前記独立して管理される複数の法人間のスマートコントラクトを介して、前記第２のネットワーク上で前記ソースコードのテストを実行することと、
    前記テストが成功したことを示す前記スマートコントラクトのうちの一部に関し
    前記テストが成功したことを示す前記スマートコントラクトのうちの前記一部に関連付けられた前記独立して管理される複数の法人のうちの一部の間の前記ブロックチェーンへの署名を実行することと、
    前記署名することによって得た署名を前記本番システムのリポジトリへマージすることと、を含む請求項７に記載の非一時的なコンピュータ可読媒体。
11. 前記ソースコードを前記独立して管理される複数の法人のそれぞれにデプロイするように構成された前記第３のネットワーク内に前記ソースコードをデプロイすることは、
    前記ステージングの結果に関連付けられた前記本番システムのリポジトリから前記独立して管理される複数の法人のマージされた署名を取得することと、
    前記マージされた署名を前記ブロックチェーンにデプロイすることと、
    前記ソースコードを、前記独立して管理される複数の法人のそれぞれにデプロイすることと、
    前記ソースコードの、前記複数の法人のそれぞれへの成功したデプロイの検証に関し、前記本番システムのリポジトリ内で前記ソースコードのデプロイを維持することと、を含む請求項７に記載の非一時的なコンピュータ可読媒体。
12. 前記第１のネットワーク上で前記ソースコードをテストすることと、前記第２のネットワーク上でステージングを実行することと、前記第３のネットワーク上で前記ソースコードをデプロイすることとが順に実行される請求項７に記載の非一時的なコンピュータ可読媒体。
13. ブロックチェーンによって、独立して管理される複数の法人にわたって本番システムのリポジトリへのソースコードのデプロイを管理するシステムであって、
    前記ソースコードをテストするように構成された、前記独立して管理される複数の法人のそれぞれにローカルな第１のネットワークと、
    前記ブロックチェーンにおいて有効であるとして検証されたテストの結果に対して、ステージングを実行して、前記独立して管理される複数の法人のそれぞれにわたってテストを検証するように構成された第２のネットワークと、
    前記ブロックチェーンにおいて前記独立して管理される複数の法人のそれぞれによって署名されるステージングの結果に対して、前記ソースコードを、前記独立して管理される複数の法人のそれぞれにデプロイするように構成された第３のネットワークと、を含むシステム。

Images