JP2021197098A - 継続的インテグレーションシステム及び継続的インテグレーション方法 - Google Patents

Abstract

【課題】各工程の処理前にモデルファイルや生成コードを静的に解析することで事前に処理の負荷を推定し処理の実行の際に割り当てるリソース量を最適化する。【解決手段】ファイルの構成管理を行うバージョン管理サーバーからの要求に応じてＣＩジョブの実行をジョブ実行マシン群に依頼するＣＩサーバーを含む継続的インテグレーションシステムは、ＣＩサーバーが、バージョン管理サーバーから入力ファイルを受け付けて、実行要求のパイプラインを構成するＣＩジョブ毎に、実行に要するリソースの推定を要求し、受信した推定結果に基づいてジョブ実行マシン群にＣＩジョブの実行を依頼するＣＩジョブ実行部と、ＣＩジョブ実行部からの推定要求に応じて、ＣＩジョブに割り当てるリソースを推定するリソース推定演算部と、リソース推定演算部からの推定結果に応じて、ＣＩジョブに割り当てるリソースを決定するリソース決定演算部を有する。【選択図】図１

Description

本発明は、モデルベース開発での継続的インテグレーションシステムに関する。

モデルベース開発は、組み込みシステム開発において広く採用されている。モデルベース開発ではソフトウェア設計にモデルファイルを利用し、設計段階からシミュレーションを実行できるため設計の検証が早期に行えることから、ソフトウェアの信頼性が高くなることが特徴である。また、モデルファイルから直接自動的にコードが生成できるため、開発におけるコーディングの工数が削減できることも特徴である。

継続的インテグレーション（Ｃｏｎｔｉｎｕｏｕｓ Ｉｎｔｅｇｒａｔｉｏｎ、以下ＣＩ）は、仕様変更に伴うソースファイルの頻繁な変更に対してビルド及びテストをその都度自動的に実行し、エラーを早期に発見、修正することができる開発手法である。

ＣＩにより、開発、テスト、リリースのサイクルが継続的に行われる仕組みが提供され、ソフトウェアの不具合を早期に発見、対処し、品質を短期で向上させることが可能となる。

従来のウォーターフォールに代表される開発手法では、一つの長い開発サイクルのために最終工程までビルド及びテストが実行されない。そのためビルドやテスト実行時にエラーが発生した場合、開発は最終工程であるために原因を解析するため非常に時間がかかるだけでなく、修正の際の手戻りが大きく、工数が増大する。

一方のアジャイル的ソフトウェア開発により開発サイクルが短いＣＩでは、その短いサイクルの中で都度ビルド及びテストを繰り返すため、エラーを早期に発見し、修正することが可能である。

また、開発初期の段階で仕様漏れや仕様違いに気が付くことができ、素早い修正が可能である。それにより従来の手法に比べ、リードタイムが削減できるだけでなく、一定の品質を保つことが可能である。

以下ではＣＩを構成するビルドやテストはジョブと呼ぶ。またジョブを内包した集まりをパイプラインと呼ぶ。

国際公開第２０１８／１１６４６０号

特許文献１は、過去のテストの履歴情報に着目し、各テストに必要なリソースを推定することにより、各テストのインスタンスに割り当てるリソースを変更し、テスト実行時に割り当てるリソース量を低減している。

前記先行技術文献でのテスト工程でのリソース消費量削減の手法は過去の実施データが必要であり、モデルベース開発での継続的インテグレーションにおけるコード生成やビルド工程への応用は困難である。

しかし、過去の履歴情報に基づくリソース推定は実施する処理の負荷が常に同等であるという前提の基で成り立っている。このため、モデルベース開発では処理の負荷がモデルファイルや生成コードに依存するだけでなく、それらのファイルは継続的インテグレーションにおいて日々単位で更新されるため、過去の履歴情報を利用したリソース推定は困難である。

本発明は以上の点を考慮してなされたもので、各工程の処理前にモデルファイルや生成コードを静的に解析することで事前に処理の負荷を推定し、その結果に基づいて各工程に割り当てるリソースを最適に配分し、各工程の処理実行時に割り当てるリソース量を最適化することを目的とする。

本発明は、ファイルの構成管理を行うバージョン管理サーバーと、前記バージョン管理サーバーからの要求に応じてＣＩジョブの実行をジョブ実行マシン群の実行マシンに依頼するＣＩサーバーと、前記ＣＩサーバーからの要求に応じて前記ＣＩジョブを実行するジョブ実行マシン群からなる継続的インテグレーションシステムであって、前記ＣＩサーバーは、前記バージョン管理サーバーから入力ファイルを受け付けて、実行要求のあったパイプラインを構成するＣＩジョブ毎に、実行に必要なリソースの推定要求を発行し、受信した推定結果に基づいて前記ジョブ実行マシン群の実行マシンにＣＩジョブの実行を依頼するＣＩジョブ実行部と、前記ＣＩジョブ実行部からの推定要求に応じて、前記ＣＩジョブに割り当てるリソースを推定するリソース推定演算部と、前記リソース推定演算部からの推定結果に応じて、前記ＣＩジョブに割り当てるリソースを決定するリソース決定演算部を有し、前記リソース推定演算部は、前記ＣＩジョブ実行部からのリソースの推定要求に応じて、前記ＣＩジョブの前記入力ファイルから論理複雑度を算出し、前記リソース決定演算部は、前記リソース推定演算部から受け取った前記論理複雑度に基づいて、予め設定された論理複雑度とジョブ実行マシン対応情報から前記ＣＩジョブを実行する実行マシンを決定する。

本発明によれば、過去の履歴情報に頼ることなく、日々単位で更新されるモデルファイルやソースファイル等のファイルに応じたリソースを最適に配分し、各工程（ＣＩジョブ）の処理の実行の際に割り当てるリソースを最適化することが可能となる。

本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

本発明の実施例を示し、継続的インテグレーションシステムの一例を示すブロック図である。 本発明の実施例を示し、バージョン管理サーバーの機能の一例を示すブロック図である。 本発明の実施例を示し、継続的インテグレーションサーバーの構成の一例を示すブロック図である。 本発明の実施例を示し、入力ファイルがモデルファイルの場合にリソース推定演算部で行われる処理の一例を示すフローチャートである。 本発明の実施例を示し、リソース決定演算部で行われる処理の一例を示すフローチャートである。 本発明の実施例を示し、ジョブ実行マシンと正規化論理複雑度の対応表を示す図である。 本発明の実施例を示し、パイプライン構成ファイルの一例を示す図である。

以下、本発明を実施するための実施形態について説明する。

図１は、継続的インテグレーション（以下、ＣＩ）システムの構成の一例を示すブロック図である。ＣＩシステムは、ファイルの構成管理を行うバージョン管理サーバー４０と、パイプライン７２を構成するＣＩジョブ７３−１〜７３−Ｎを実行するために必要な計算機リソースを推定及び決定し、ＣＩジョブ７３−１〜７３−Ｎの実行をジョブ実行マシン群２００に要求するＣＩサーバー７０と、ＣＩジョブ７３−１〜７３−Ｎの処理を行う複数の実行マシン（計算機）２１１−１〜２１１−Ｍからなるジョブ実行マシン群２００から構成される。

なお、ＣＩジョブを個々に特定しない場合には、「−」以降を省略した符号「７３」を使用する。また、他の構成要素の符号についても同様である。

バージョン管理サーバー４０は、ファイル群の構成管理を行う機能を有し、ファイル群を管理するブランチ４２と、複数のブランチ４２を管理するリポジトリ４１から構成される。図２は、バージョン管理サーバー４０の機能の一例を示すブロック図である。

本実施例ではファイル群として、プログラムのソースファイルからなるソースファイル群４３と、モデルを記述したモデルファイル群４４と、ＣＩスクリプト４５と、パイプラインを構成するＣＩジョブ７３を記述したパイプライン構成ファイル群４８をブランチ４２が管理する。

また、ＣＩスクリプト４５は、ＣＩジョブ７３の処理を記述したＣＩジョブスクリプト群４６と、ＣＩジョブ７３に適切な実行マシン２１１を割り当てるための正規化論理複雑度−ジョブ実行マシン対応表４７からなる。

ＣＩサーバー７０は、パイプライン７２の構成に従ってＣＩジョブ７３の実行管理を行うＣＩジョブ実行部７１と、パイプライン７２を構成するＣＩジョブ７３に必要なリソースを推定するリソース推定演算部８０と、推定されたリソースからＣＩジョブ７３を実行するために必要なリソースを決定するリソース決定演算部９０からなる。

なお、本実施例のパイプライン７２は、ＣＩジョブ７３−１からＣＩジョブ７３−Ｎを順次実行する例を示す。

ユーザー１はユーザー端末２を通じて入力ファイル群２０をバージョン管理サーバー４０へ送信する。バージョン管理サーバー４０は受信した入力ファイル群２０をリポジトリ４１上のブランチ４２へ格納する。

バージョン管理サーバー４０は、受信した入力ファイル群２０とブランチ４２に格納されたファイル群との間に差分が存在する場合、ＣＩサーバー７０へファイル更新情報５０とパイプライン入力ファイル５１を送信する。

パイプライン入力ファイル５１は、ブランチ４２内の全てのファイルであるソースファイル群４３と、モデルファイル群４４と、ＣＩスクリプト４５と、パイプライン構成ファイル群４８からなる。

ファイル更新情報５０は、入力ファイル群２０のうち、ソースファイル群４３やモデルファイル群４４で更新のあったファイルの情報が含まれる。

以下では入力ファイル群としてモデルファイル群４４の例について説明する。

ＣＩサーバー７０は、バージョン管理サーバー４０からＣＩサーバー７０へファイル更新情報５０とパイプライン入力ファイル５１を受け付けると、ＣＩジョブ実行部７１が、パイプライン構成ファイル群４８に記述されたそれぞれのＣＩジョブ７３に対して、リソース推定要求８１をリソース推定演算部８０に送信し、リソース決定演算部９０からリソース決定結果９１を受け付けて、ジョブ実行マシン群２００にＣＩジョブ７３の実行を依頼する。

そして、ＣＩサーバー７０は、ジョブ実行マシン群２００からジョブ実行結果１００を受け付けると、パイプライン実行結果６０をバージョン管理サーバー４０へ送信する。

図７は、パイプライン構成ファイル５００の一例を示す図である。本実施例におけるパイプライン構成ファイル５００は、モデルファイル群４４からコードを生成するジョブ５０１が記述されている。

ＣＩジョブ実行部７１はこのコード生成ジョブ５０１に関してリソース推定要求８１をリソース推定演算部８０に送信し、リソース決定演算部９０からリソース決定結果９１を受け付け、ジョブ実行マシン群２００の実行マシン２１１にＣＩジョブ７３の実行を依頼する。

リソース推定演算部８０は、ＣＩジョブ実行部７１からリソース推定要求８１を受け付けると、パイプライン入力ファイル５１に存在するモデルファイル群４４を用いて計算機リソースの推定を行い、正規化論理複雑度８２を算出してリソース決定演算部９０へ送信する。

リソース決定演算部９０は、リソース推定演算部８０から正規化論理複雑度８２を受け付けると、パイプライン入力ファイル５１に含まれる正規化論理複雑度−ジョブ実行マシン対応表４７を参照して割り当てるリソースの決定を行う。

正規化論理複雑度８２は０〜１の実数値であり、正規化論理複雑度−ジョブ実行マシン対応表４７には、正規化論理複雑度の値とジョブ実行に適した実行マシンを紐づけるための情報が記載されている。

リソース決定演算部９０は正規化論理複雑度８２と、正規化論理複雑度−ジョブ実行マシン対応表４７を用いて、ＣＩジョブ７３を実行する実行マシン２１１を一意に選択し、リソースの決定を行い、リソース決定結果９１をＣＩジョブ実行部７１へ送信する。

ＣＩジョブ実行部７１は、ＣＩジョブ情報１１２と、ジョブ実行要求１１０をジョブ実行マシン群２００へ送信する。ジョブ実行要求１１０はＣＩジョブ７３を実行するマシン情報が含まれ、ジョブ実行マシン群２００の中から一意に選択される。

選択された実行マシン２１１はＣＩジョブ情報１１２を基にＣＩジョブ７３を実行した後、ジョブ実行結果１００をＣＩサーバー７０に送信する。

ジョブ実行マシン群２００は、ＣＩジョブ７３の処理を行う複数の実行マシン２１１−１〜２１１−Ｍから構成されている。

図３は、ＣＩサーバー７０の構成の一例を示すブロック図である。ＣＩサーバー７０は、プロセッサ１１と、メモリ１２と、ストレージ装置１３と、ネットワーク装置１４とを含む計算機である。

メモリ１２には、リソース推定演算部８０と、リソース決定演算部９０と、ＣＩジョブ実行部７１がロードされて、プロセッサ１１によって実行される。

プロセッサ１１は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ１１は、リソース推定演算プログラムに従って処理を実行することでリソース推定演算部８０として機能する。他のプログラムについても同様である。さらに、プロセッサ１１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

ネットワーク装置１４には、ネットワーク１５が接続される。ネットワーク１５には、図１に示したバージョン管理サーバー４０と、ジョブ実行マシン群２００と、ユーザー端末２が接続されて相互に通信を行うことができる。

図４は、リソース推定演算部８０で行われる処理の一例を示すフローチャートである。この処理は、ＣＩサーバー７０がバージョン管理サーバー４０からファイル更新情報５０と、パイプライン入力ファイル５１を受信した場合に実行される。

まず、ＣＩジョブ実行部７１は、ＣＩジョブ７３を実行させる計算機リソースを推定するため、リソース推定要求８１をリソース推定演算部８０に送信する。

リソース推定演算部８０は、リソース推定要求８１を受信（３０１）すると、対象ファイル（例えば、モデルファイル）に対して論理複雑度の評価を実施する。リソース推定演算部８０は、対象ファイルがモデルファイルの場合、論理複雑度の評価はモデルの入出力ポートサイズ（ｋＢ）を測定する（３０２）。

本実施例のＣＩサーバー７０では、リソース推定演算部８０がモデルファイルの入力ポートの数と出力ポートの数に各ポートのサイズを乗じた値の総和を入出力ポートサイズとして算出する。これにより、入出力ポートの数が大きいほど、ＣＩジョブ７３の処理負荷が増大するので、入出力ポートサイズはモデルファイルの処理負荷の指標として算出される。

なお、リソース推定演算部８０は、ＣＩサーバー７０が受け付けたファイル更新情報５０に基づいて、モデルファイル群４４から最新のモデルファイルの情報を取得して入出力ポートサイズを測定する。また、上記では入出力ポートサイズをモデルファイルの処理負荷の指標とする例を示したが、これに限定されるものではなく、入力ポートの数と出力ポートの数の総和をモデルファイルの処理負荷の指標とすることができる。

測定した入出力ポートのサイズは、評価の簡単化のため、広く周知されている既存の方法を用いて正規化を行って論理複雑度として扱う（３０３）。正規化された論理複雑度は、正規化論理複雑度８２としてリソース決定演算部９０へ送信（３０４）される。

図５は、リソース決定演算部９０で行われる処理の一例を示すフローチャートである。

リソース決定演算部９０は正規化論理複雑度８２を受信すると（４０１）、ジョブ実行マシン群２００で使用する計算機リソースの決定処理を実施する。リソース決定演算部９０は、正規化論理複雑度８２と正規化論理複雑度−ジョブ実行マシン対応表４７を比較し（４０２）、ＣＩジョブ７３を実行する実行マシン２１１を一意に決定する（４０３）。

リソース決定演算部９０は、決定したＣＩジョブ７３の実行マシン２１１の結果をリソース決定結果９１としてＣＩジョブ実行部７１へ送信する（４０４）。

上記処理によって、ＣＩジョブ実行部７１は、受信したリソース決定結果９１に基づいてＣＩジョブ７３を割り当てる実行マシン２１１にジョブ実行要求１１０と、入力ファイル１１１と、ＣＩジョブ情報１１２を送信してＣＩジョブ７３を実行させる。

ＣＩジョブ実行部７１は、ＣＩジョブ７３を割り当てた実行マシン２１１からジョブ実行結果１００を受信すると、パイプライン７２を構成するＣＩジョブ７３のジョブ実行結果１００をまとめてパイプライン実行結果６０としてバージョン管理サーバー４０へ送信する。

図６は、正規化論理複雑度−ジョブ実行マシン対応表４７の一例を示す図である。正規化論理複雑度−ジョブ実行マシン対応表４７は、実行マシンの性能４７０と、ＣＩジョブ７３−１〜７３−Ｎ毎の正規化論理複雑度４７１−１〜４７１−Ｎを一つのエントリに含む。

実行マシンの性能４７０には、ジョブ実行マシン群２００の実行マシン２１１毎の性能の指標が格納される。正規化論理複雑度４７１−１〜４７１−Ｎには、各ＣＩジョブ７３毎に予め設定された正規化論理複雑度の範囲が格納される。

また、実行マシン２１１の性能情報は、実行マシン２１１毎にそれぞれの構成に応じて予め設定される。実行マシン２１１毎の性能の指標としては、プロセッサの周波数やコア数に基づく指標や、搭載するメモリ容量などを指標とすることができる。

リソース決定演算部９０は、リソース推定演算部７５が算出したＣＩジョブ７３の正規化論理複雑度８２と、正規化論理複雑度４７１の範囲に応じて、ＣＩジョブ７３を実行するのに最適な実行マシン２１１を決定する。例えば、ＣＩジョブ１（７３−１）の実行マシンを割り当てる場合、正規化論理複雑度８２の値が０．１以上０．４未満であれば実行マシンＭにＣＩジョブ１（７３−１）を割り当て、正規化論理複雑度８２の値が０．４以上０．８未満であれば実行マシン２にＣＩジョブ１（７３−１）を割り当て、正規化論理複雑度８２の値が０．８以上１以下であれば実行マシン１にＣＩジョブ１（７３−１）を割り当てる。

ＣＩジョブ７３毎のマシン割り当ての変更は、対応する正規化論理複雑度４７１のレンジの閾値を適宜変更することにより実現できる。特に正規化論理複雑度が０の場合は該対応表の中に最適なマシンは存在しない。

正規化論理複雑度が０とは、ＣＩジョブ７３の処理対象のファイルに論理が含まれていない場合であり、ＣＩジョブ７３として必要な処理がないと判断することが可能である。この場合、リソース決定演算部９０は、ＣＩジョブ実行部７１には最適な実行マシン２１１はないという情報が送信される。

正規化論理複雑度は、ＣＩジョブ７３の種類毎に正規化論理複雑度−ジョブ実行マシン対応表４７の値を設定すればよく、ＣＩジョブ７３がコンパイルの場合では、ソースファイルの行数を論理複雑度として算出し、ＣＩジョブ７３がテストの場合では、テストベクターを論理複雑度として算出すればよい。

また、論理複雑度は、ＣＩジョブ７３を処理する際の実行マシン２１１の負荷を表す指標であればよく、上記に限定されるものではない。

以上のように、本実施例のＣＩサーバー７０は、過去の履歴情報に頼ることなく、各ＣＩジョブ７３（各工程）の実行前にモデルファイルやソースファイルを静的に解析することで事前に処理の負荷を正規化論理複雑度として推定し、推定結果に基づいて各ＣＩジョブ７３（工程）を割り当てるリソース（実行マシン２１１）を最適に配分することができる。

＜結び＞
以上のように、上記実施例の継続的インテグレーションシステムは、以下のような構成とすることができる。

（１）ファイル（入力ファイル群２０）の構成管理を行うバージョン管理サーバー（４０）と、前記バージョン管理サーバー（４０）からの要求に応じてＣＩジョブ（７３）の実行をジョブ実行マシン群（２００）の実行マシン（２１１）に依頼するＣＩサーバー（７０）と、前記ＣＩサーバー（７０）からの要求に応じて前記ＣＩジョブ（７３）を実行するジョブ実行マシン群（２００）からなる継続的インテグレーションシステムであって、前記ＣＩサーバー（７０）は、前記バージョン管理サーバー（４０）から入力ファイルを受け付けて、実行要求のあったパイプライン（７２）を構成するＣＩジョブ（７３）毎に、実行に必要なリソースの推定要求（８１）を発行し、受信した推定結果に基づいて前記ジョブ実行マシン群（２００）の実行マシン（２１１）にＣＩジョブ（７３）の実行を依頼するＣＩジョブ実行部（７１）と、前記ＣＩジョブ実行部（７１）からの推定要求（８１）に応じて、前記ＣＩジョブ（７３）に割り当てるリソースを推定するリソース推定演算部（８０）と、前記リソース推定演算部（８０）からの推定結果（正規化論理複雑度８２２）に応じて、前記ＣＩジョブ（７３）に割り当てるリソースを決定するリソース決定演算部（９０）を有し、前記リソース推定演算部（８０）は、前記ＣＩジョブ実行部（７１）からのリソースの推定要求（９１）に応じて、前記ＣＩジョブ（７３）の前記入力ファイルから論理複雑度（８２）を算出し、前記リソース決定演算部（９０）は、前記リソース推定演算部（８０）から受け取った前記論理複雑度（８２）に基づいて、予め設定された論理複雑度とジョブ実行マシン対応情報（４７）から前記ＣＩジョブ（７３）を実行する実行マシン（２１１）を決定することを特徴とする継続的インテグレーションシステム。

上記構成により、過去の履歴情報に頼ることなく、日々単位で更新されるモデルファイルやソースファイル等の入力ファイルの更新情報に応じてＣＩジョブ７３を実行するリソースを最適に配分し、各工程（ＣＩジョブ）の処理の実行の際に割り当てるリソースを最適化することが可能となる。

（２）上記（１）に記載の継続的インテグレーションシステムであって、前記リソース推定演算部（８０）は、前記入力ファイルを処理する際の負荷の指標として前記論理複雑度を算出することを特徴とする継続的インテグレーションシステム。

上記構成により、入力ファイルの種類に応じて論理複雑度を算出することで、パイプライン７２を構成する各ＣＩジョブ７３間で処理負荷に応じたリソースの割り当てを最適化することができる。

（３）上記（２）に記載の継続的インテグレーションシステムであって、前記リソース推定演算部（８０）は、前記入力ファイルがモデルファイルの場合、入力ポートの数と出力ポートの数に基づいて前記論理複雑度（８２）を算出することを特徴とする継続的インテグレーションシステム。

上記構成により、入力ファイルがモデルファイルの場合は、入力ポートの数と出力ポートの数の総和の大きさに応じて処理負荷が増大すると予測することができ、論理複雑度の大きさに応じて実行マシン２１１を決定することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１ ユーザー
２ ユーザー端末
２０ 入力ファイル群
４０ バージョン管理サーバー
４１ リポジトリ
４２ ブランチ
４３ ソースファイル群
４４ モデルファイル群
４５ ＣＩスクリプト
４６ ＣＩジョブ用スクリプト群
４７ 正規化論理複雑度−ジョブ実行マシン対応表
４８ パイプライン構成ファイル群
５０ ファイル更新情報
５１ パイプライン入力ファイル
６０ パイプライン実行結果
７０ ＣＩサーバー
７１ ＣＩジョブ実行部
７２ パイプライン
７３−１〜７３−Ｎ ＣＩジョブ１〜Ｎ
８０ リソース推定演算部
８１ リソース推定要求
８２ 正規化論理複雑度
９０ リソース決定結果
１００ ジョブ実行結果
１１０ ジョブ実行要求
１１１ 入力ファイル
１１２ ＣＩジョブ情報
２００ ジョブ実行マシン群
２１１−１〜２１１−Ｍ 実行マシン１〜Ｍ
５０１ コード生成ジョブ

Claims (6)

1. ファイルの構成管理を行うバージョン管理サーバーと、
   前記バージョン管理サーバーからの要求に応じてＣＩジョブの実行をジョブ実行マシン群の実行マシンに依頼するＣＩサーバーと、
   前記ＣＩサーバーからの要求に応じて前記ＣＩジョブを実行するジョブ実行マシン群からなる継続的インテグレーションシステムであって、
   前記ＣＩサーバーは、
   前記バージョン管理サーバーから入力ファイルを受け付けて、実行要求のあったパイプラインを構成するＣＩジョブ毎に、実行に必要なリソースの推定要求を発行し、受信した推定結果に基づいて前記ジョブ実行マシン群の実行マシンにＣＩジョブの実行を依頼するＣＩジョブ実行部と、
   前記ＣＩジョブ実行部からの推定要求に応じて、前記ＣＩジョブに割り当てるリソースを推定するリソース推定演算部と、
   前記リソース推定演算部からの推定結果に応じて、前記ＣＩジョブに割り当てるリソースを決定するリソース決定演算部を有し、
   前記リソース推定演算部は、
   前記ＣＩジョブ実行部からのリソースの推定要求に応じて、前記ＣＩジョブの前記入力ファイルから論理複雑度を算出し、
   前記リソース決定演算部は、
   前記リソース推定演算部から受け取った前記論理複雑度に基づいて、予め設定された論理複雑度とジョブ実行マシン対応情報から前記ＣＩジョブを実行する実行マシンを決定することを特徴とする継続的インテグレーションシステム。
2. 請求項１に記載の継続的インテグレーションシステムであって、
   前記リソース推定演算部は、
   前記入力ファイルを処理する際の負荷の指標として前記論理複雑度を算出することを特徴とする継続的インテグレーションシステム。
3. 請求項２に記載の継続的インテグレーションシステムであって、
   前記リソース推定演算部は、
   前記入力ファイルがモデルファイルの場合、入力ポートの数と出力ポートの数に基づいて前記論理複雑度を算出することを特徴とする継続的インテグレーションシステム。
4. ファイルの構成管理を行うバージョン管理サーバーからの要求に応じてＣＩジョブの実行をジョブ実行マシン群の実行マシンに依頼するＣＩサーバーが前記ＣＩジョブを実行するジョブ実行マシン群を制御する継続的インテグレーション方法であって、
   前記ＣＩサーバーが、前記バージョン管理サーバーから入力ファイルを受け付けて、実行要求のあったパイプラインを構成するＣＩジョブ毎に、実行に必要なリソースの推定要求を発行し、受信した推定結果に基づいて前記ジョブ実行マシン群の実行マシンにＣＩジョブの実行を依頼するＣＩジョブ実行ステップと、
   前記ＣＩサーバーが、前記推定要求に応じて、前記ＣＩジョブに割り当てるリソースを推定するリソース推定演算ステップと、
   前記ＣＩサーバーが、前記推定結果に応じて、前記ＣＩジョブに割り当てるリソースを決定するリソース決定演算ステップと、を含み、
   前記リソース推定演算ステップは、
   前記リソースの推定要求に応じて、前記ＣＩジョブの前記入力ファイルから論理複雑度を算出し、
   前記リソース決定演算ステップは、
   前記論理複雑度に基づいて、予め設定された論理複雑度とジョブ実行マシン対応情報から前記ＣＩジョブを実行する実行マシンを決定することを特徴とする継続的インテグレーション方法。
5. 請求項４に記載の継続的インテグレーション方法であって、
   前記リソース推定演算ステップは、
   前記入力ファイルを処理する際の負荷の指標として前記論理複雑度を算出することを特徴とする継続的インテグレーション方法。
6. 請求項５に記載の継続的インテグレーション方法であって、
   前記リソース推定演算ステップは、
   前記入力ファイルがモデルファイルの場合、入力ポートの数と出力ポートの数に基づいて前記論理複雑度を算出することを特徴とする継続的インテグレーション方法。

Images