(57)【要約】【課題】複数の環境が存在するシステムにおいて、一元的に管理対象ファイルの更新管理を実施できるようにしたライブラリ管理システムを得る。【解決手段】本番環境に配置された管理対象サーバ１０と開発環境の管理対象サーバ２０で使用される管理対象ファイルがクライアントＰＣ３０により更新されたとき、更新申請ごとにタグを付与し、このタグにより更新申請に含まれる共通部と環境依存部を紐付けして、それぞれを構成サーバ１１０の共通部更新申請ファイル１１２及び環境依存部更新申請ファイル１１３に格納しておき、生成サーバ１２０では、タグに基づき、構成サーバ１１０に格納された管理対象ファイル１１１と、更新申請の共通部と、環境依存部とによりモジュールを生成して、管理対象サーバに配布するようにした。【選択図】図１
2008225762.tif 000002
【特許請求の範囲】
【請求項１】
複数の環境を有するシステムに配置された管理対象サーバで使用される管理対象ファイルを更新するライブラリ管理システムにおいて、
上記管理対象ファイル及びこの管理対象ファイルの更新申請を格納した構成サーバ、及びこの構成サーバの上記管理対象ファイル及び上記更新申請を基にして、更新後の管理対象ファイルのモジュールを作成して上記管理対象サーバに配布する生成サーバを備え、
上記構成サーバは、上記管理対象ファイルを複数の環境に共通する部分である共通部ファイルと共通部以外の環境依存部分である環境依存部ファイルに分けて格納した管理対象ファイルデータベースと、上記構成サーバに接続されたクライアント装置により上記管理対象ファイルが更新されたとき、上記クライアント装置からの上記管理対象ファイルの更新申請に基づき、上記更新申請の共通部ファイルと環境依存部ファイルとをそれぞれ別に格納した共通部更新申請データベース及び環境依存部更新申請データベースと、上記各データベースのファイルのバージョン管理を行うバージョン管理部と、上記更新申請ごとに上記共通部ファイルと環境依存部ファイルを紐付けするタグを管理するタグ管理部とを有し、
上記生成サーバは、上記タグに基づき、上記構成サーバから、上記管理対象ファイルと上記更新申請された共通部ファイル及び環境依存部ファイルを取得し、この取得した上記管理対象ファイルに上記共通部ファイルと環境依存部ファイルを順に上書きすることで、管理対象サーバ毎のモジュール生成に必要な生成環境を作成する生成環境作成部と、この生成環境作成部によって作成された生成環境からモジュールを生成するモジュール生成部と、このモジュール生成部によって生成されたモジュールを上記管理対象サーバごとにパッケージ化した配布ファイルを作成する配布対象パッケージ部と、この配布対象パッケージ部によりパッケージ化された配布ファイルを上記管理対象サーバに配布する配布実行部とを有することを特徴とするライブラリ管理システム。
【請求項２】
上記生成サーバは、上記配布ファイルが、上記管理対象サーバでインストールされるように指示するリモートインストール部を有することを特徴とする請求項１記載のライブラリ管理システム。
【請求項３】
上記管理対象サーバと、上記クライアント装置は、それぞれ上記構成サーバ及び上記生成サーバとは離れた場所に配置されるとともに、ＶＰＮを介した広域ネットワークで上記構成サーバ及び上記生成サーバに接続されたことを特徴とする請求項１または請求項２記載のライブラリ管理システム。
【請求項４】
上記生成サーバは、更新申請された共通部ファイル及び環境依存部ファイルの記述をチェックするチェック機能を有することを特徴とする請求項１〜請求項３のいずれかに記載のライブラリ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、情報システムの開発におけるライブラリ管理作業（版管理、更新申請受付、モジュール生成、モジュール投入という一連の作業）を支援し、効率化と品質向上を実現するライブラリ管理システムに関するものである。
【背景技術】
【０００２】
従来のライブラリ管理システムでは、ＣＶＳ（Ｃｏｎｃｕｒｒｅｎｔ  Ｖｅｒｓｉｏｎｓ  Ｓｙｓｔｅｍ）に代表されるバージョン管理ソフトウェアを用いて、バージョン管理を実施している。バージョン管理ソフトウェアは、版管理作業の効率化に有用であるが、申請順に更新される単一環境の管理を基本としているため、管理対象が、それぞれ共通部分と異なる部分とを持つ複数の環境（本番環境、開発環境など）であるような場合、また、複数の申請者から非同期に申請が発生したり、申請の順序と実際の反映順序が異なる場合には、管理作業が非常に複雑になり、作業時間が増大したり、更新反映のミスによって誤ったモジュールの投入が発生し、動作不具合を起こす等の問題が発生する場合があった。
また、版管理以外の作業、つまりモジュール生成・投入といった作業は、バージョン管理ソフトウェアでは実施できず、別途手動にて作業を実施していた。
特許文献１には、プロダクト管理ファイルに情報を付加し、プロダクトが開発中、稼働中等の情報を管理するシステムが記載されている。
【０００３】
【特許文献１】特開平７−６４７７４号公報（第３〜４頁、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のバージョン管理方式では、大部分が共通部分と呼ばれる同一部で、一部の環境依存部分のみが異なる複数の管理対象に対して管理を行う場合、共通部分の更新や環境依存部分の更新によって、各管理対象の更新処理が複雑になり、更新モレや誤った更新など、作業ミスが発生する危険性が高い。
また、更新申請順に更新反映する場合には問題はないが、そうでない場合、例えば先に申請されたものが後に反映しなければならないような場合には対応できない。
また、反映後のモジュール生成、モジュール投入といった作業は、サポートされていない、などの問題点があった。
特許文献１のシステムでは、開発環境のプロダクトが本番環境に誤って混入されることを防止するが、共通部分や環境依存部分といった考え方ではないため、１つのプロダクトを本番環境あるいは開発環境の複数の環境に配置する場合、また本番環境と開発環境にて同一のファイルを使用する場合について対応できないという問題があった。
【０００５】
この発明は、上記のような課題を解決するためになされたものであり、複数の環境が存在するシステムにおいて、一元的に管理対象ファイルの更新管理を実施できるようにしたライブラリ管理システムを得ることを目的にしている。
【課題を解決するための手段】
【０００６】
この発明に係わるライブラリ管理システムにおいては、複数の環境を有するシステムに配置された管理対象サーバで使用される管理対象ファイルを更新するライブラリ管理システムにおいて、
管理対象ファイル及びこの管理対象ファイルの更新申請を格納した構成サーバ、及びこの構成サーバの管理対象ファイル及び更新申請を基にして、更新後の管理対象ファイルのモジュールを作成して管理対象サーバに配布する生成サーバを備え、
構成サーバは、管理対象ファイルを複数の環境に共通する部分である共通部ファイルと共通部以外の環境依存部分である環境依存部ファイルに分けて格納した管理対象ファイルデータベースと、構成サーバに接続されたクライアント装置により管理対象ファイルが更新されたとき、クライアント装置からの管理対象ファイルの更新申請に基づき、更新申請の共通部ファイルと環境依存部ファイルとをそれぞれ別に格納した共通部更新申請データベース及び環境依存部更新申請データベースと、各データベースのファイルのバージョン管理を行うバージョン管理部と、更新申請ごとに共通部ファイルと環境依存部ファイルを紐付けするタグを管理するタグ管理部とを有し、
生成サーバは、タグに基づき、構成サーバから、管理対象ファイルと更新申請された共通部ファイル及び環境依存部ファイルを取得し、この取得した管理対象ファイルに共通部ファイルと環境依存部ファイルを順に上書きすることで、管理対象サーバ毎のモジュール生成に必要な生成環境を作成する生成環境作成部と、この生成環境作成部によって作成された生成環境からモジュールを生成するモジュール生成部と、このモジュール生成部によって生成されたモジュールを管理対象サーバごとにパッケージ化した配布ファイルを作成する配布対象パッケージ部と、この配布対象パッケージ部によりパッケージ化された配布ファイルを管理対象サーバに配布する配布実行部とを有するものである。
【発明の効果】
【０００７】
この発明は、以上説明したように、複数の環境を有するシステムに配置された管理対象サーバで使用される管理対象ファイルを更新するライブラリ管理システムにおいて、
管理対象ファイル及びこの管理対象ファイルの更新申請を格納した構成サーバ、及びこの構成サーバの管理対象ファイル及び更新申請を基にして、更新後の管理対象ファイルのモジュールを作成して管理対象サーバに配布する生成サーバを備え、
構成サーバは、管理対象ファイルを複数の環境に共通する部分である共通部ファイルと共通部以外の環境依存部分である環境依存部ファイルに分けて格納した管理対象ファイルデータベースと、構成サーバに接続されたクライアント装置により管理対象ファイルが更新されたとき、クライアント装置からの管理対象ファイルの更新申請に基づき、更新申請の共通部ファイルと環境依存部ファイルとをそれぞれ別に格納した共通部更新申請データベース及び環境依存部更新申請データベースと、各データベースのファイルのバージョン管理を行うバージョン管理部と、更新申請ごとに共通部ファイルと環境依存部ファイルを紐付けするタグを管理するタグ管理部とを有し、
生成サーバは、タグに基づき、構成サーバから、管理対象ファイルと更新申請された共通部ファイル及び環境依存部ファイルを取得し、この取得した管理対象ファイルに共通部ファイルと環境依存部ファイルを順に上書きすることで、管理対象サーバ毎のモジュール生成に必要な生成環境を作成する生成環境作成部と、この生成環境作成部によって作成された生成環境からモジュールを生成するモジュール生成部と、このモジュール生成部によって生成されたモジュールを管理対象サーバごとにパッケージ化した配布ファイルを作成する配布対象パッケージ部と、この配布対象パッケージ部によりパッケージ化された配布ファイルを管理対象サーバに配布する配布実行部とを有するので、管理対象ファイルを各環境の共通部と環境依存部に分割してタグにより管理することにより、共通部の各環境への更新モレを防止することができるとともに、更新反映後のモジュール生成、モジュール投入も自動的に実行でき、作業効率の向上と作業ミスの低減が実現できる。
【発明を実施するための最良の形態】
【０００８】
実施の形態１．
本発明の実施の形態１を、図に基づいて説明する。
図１は、この発明の実施の形態１によるライブラリ管理システムを示す構成図である。
図１では、例として、ライブラリ管理対象として本番環境、開発環境の２つの環境が存在するものとする。
図１において、管理対象サーバ１０は、本番環境に配置されている。管理対象サーバ２０は、開発環境に配置されている。ライブラリ管理サーバ１０１は、ライブラリ担当者５０によって管理され、管理対象サーバ１０と管理対象サーバ２０にネットワークを介して接続される。更新申請者４０は、ライブラリ管理サーバ１０１にネットワークを介して接続されたクライアントＰＣ３０を用いてライブラリの更新申請を行う。なお、クライアントＰＣ３０は、複数が接続されてもよい。
ライブラリ管理サーバ１０１は、さらにクライアントＰＣ３０からの登録命令に応じて申請を登録する構成サーバ１１０と、更新申請から更新されたモジュールを生成して配布する生成サーバ１２０から構成される。
【０００９】
構成サーバ１１０は、管理対象のプログラムを格納した管理対象ファイル１１１（管理対象ファイルデータベース）と、更新申請のうち、複数の環境に共通する部分である共通部ファイルを格納した共通部更新申請ファイル１１２（共通部更新申請データベース）と、更新申請のうち、共通部以外の環境に依存した部分である環境依存部ファイルを格納した環境依存部更新申請ファイル１１３（環境依存部更新申請データベース）とを有している。１１１〜１１３は、バージョン管理部１１４によってバージョン管理され、さらに管理対象ファイル１１１の反映バージョンと、共通部更新申請ファイル１１２および環境依存部更新申請ファイル１１３の各申請毎の更新ファイルは、タグ管理部１１５により、タグによって紐付けされ、管理されている。
なお、管理対象ファイル１１１は、共通部ファイルと環境依存部ファイルに分けて格納されている。
【００１０】
生成サーバ１２０は、ライブラリ管理担当者５０によって作成されたタグリスト定義ファイル１２７を読込む更新反映管理部１２１と、このタグリストに基づき、管理対象ファイル１１１から対象のプログラムを取得して、共通部更新申請ファイル１１２および環境依存部更新申請ファイル１１３の両更新申請ファイルを用いて更新反映されたモジュール生成環境を作成するモジュール生成環境作成部１２２（生成環境作成部）と、モジュール生成環境上でビルドを実施し（コンパイルなど）、実行ファイルであるモジュールを生成するモジュール生成部１２３と、生成されたモジュールを別途設けられた設定ファイルとともに配布対象（管理対象サーバ１０、２０）ごとにパッケージングする配布対象パッケージ部１２４と、パッケージを配布対象に配布する配布実行部１２５と、１２１〜１２５を実行させる自動実行部１２６を有している。
【００１１】
図２は、この発明の実施の形態１によるライブラリ管理システムの処理を示すフローチャートである。
図２（ａ）は、更新申請処理、図２（ｂ）は、ライブラリ管理処理を示している。
【００１２】
図３は、この発明の実施の形態１によるライブラリ管理システムのモジュール生成環境作成方式を示す図である。
図３において、１１１〜１１３は図１におけるものと同一のものである。図３では、管理対象ファイル１１１と、共通部更新申請ファイル１１２と、環境依存部更新申請ファイル１１３との関連を示している。
【００１３】
実施の形態１の処理の流れを、図１および図２に基づいて説明する。
図２（ａ）の更新申請処理では、ステップＳ１で、まずクライアントＰＣ３０は、管理対象ファイル１１１から更新元ファイル（更新対象プログラム）を取得する。ステップＳ２で、クライアントＰＣ３０上で、管理対象ファイルの更新が行われる。この更新は、管理対象ファイルの共通部ファイル及び環境依存部ファイルのいずれか一方または両方について行われる。次いで、ステップＳ３で、クライアントＰＣ３０上で更新された結果は、クライアントＰＣ３０から登録命令が出され、共通部ファイルであれば、共通部更新申請ファイル１１２に、環境依存部ファイルであれば、環境依存部更新申請ファイル１１３に登録される。この更新時に、各更新単位（単一ファイルもしくは複数ファイル）ごとに、クライアントＰＣ３０上で、更新単位でユニークな管理タグが付加される。ステップＳ４で、このタグがライブラリ管理担当者５０にメールにより連絡されることで、更新申請が行われる。
【００１４】
次に、図２（ｂ）のライブラリ管理処理について説明する。
ステップＳ６で、複数の更新申請の連絡を受けた更新申請のうち、今回の処理にて管理対象サーバ１０、２０に反映する更新を決定し、ステップＳ７で、決定された更新のタグをタグリスト定義ファイル１２７に記述する。
記述後に自動実行部１２６に実行コマンドを送ることにより、ステップＳ８で、自動実行部１２６により、ステップＳ１１〜ステップＳ１５を順次実行させ、生成サーバ１２０上にてモジュール生成および配布が自動実行される。
この自動実行内部処理では、まず、ステップＳ１１で、更新反映管理部１２１がタグリスト定義ファイル１２７を読込み、モジュール生成環境作成部１２２に送信する。
ステップＳ１２で、モジュール生成環境作成部１２２は、まず管理対象ファイル１１１から更新元ファイルを取得し、更新元ファイルの共通部ファイルを管理対象サーバ分、コピーを行い、その共通部ファイル上に環境依存部ファイルを上書きすることによって、管理対象サーバ毎の更新元モジュール生成環境を作成する。さらに、その上に共通更新部申請ファイル１１２および環境依存部更新申請ファイル１１３の両更新申請ファイルを指定されたタグの順番にて、順次、上書きすることで、更新反映されたモジュール生成環境を作成する。この処理を図３に示す。
【００１５】
モジュール生成環境が作成された後、ステップＳ１３で、モジュール生成部１２３が、モジュール生成環境上でビルドを実施し、実行ファイルであるモジュールを生成する。次に、ステップＳ１４で、配布対象パッケージ部１２４が、生成されたモジュールと、今回の更新反映にて、管理対象サーバ１０、２０への反映が必要な更新ファイルを抜き出し、管理対象サーバ１０、２０毎にパッケージ化を実施する。
最後に、ステップＳ１５で、配布実行部１２５が、各管理対象サーバに対し、パッケージを配布し、自動処理が終了する。
処理終了後、ステップＳ９で、各管理対象サーバ１０、２０は、配布されたパッケージのインストールを実行し、更新反映が完了する。ステップＳ１０で、完了後に、次回の更新申請のために、管理対象ファイル１１１に今回の更新を反映しておく。
【００１６】
実施の形態１によれば、管理対象ファイルを共通部分と環境依存部に分割してタグにより管理するため、他環境への更新反映モレや環境依存ファイルの更新ミスが防止できる。
また、更新反映後のモジュール生成、モジュール投入も自動的に実行でき、作業効率の向上と作業ミスの低減が実現できる。
また、多数の申請者が非同期に更新申請を発行する場合においても、ライブラリ管理担当者は、更新タグを管理するのみで、更新反映が自動的に実行される。
また、一部の申請のみを反映しない、もしくは次回反映に延期する場合の処理については、従来の時系列に更新が反映されるバージョン管理システムでは困難だが、本システムでは該当タグを外すのみで実現できる。
さらに、更新申請の連絡順番が更新反映すべき順番と異なっている場合にも、タグの並び替えのみで順序の入れ替えが可能となる。
【００１７】
実施の形態２．
図４は、この発明の実施の形態２によるライブラリ管理システムを示す構成図である。
図４において、１０〜５０、１０１、１１０〜１１５、１２０〜１２７は図１におけるものと同一のものである。図４では、生成サーバ１２０に、各管理対象サーバ１０、２０へのモジュールのインストールを遠隔から実行するリモート実行部１３０（リモートインストール部）、及びインストール結果のログである結果ログ１３１を追加した。
【００１８】
実施の形態１では、パッケージの配布までは自動化されていたが、最終的な各管理対象サーバ１０、２０へのモジュールのインストールは、ライブラリ管理担当者５０が手動で実施する必要があった。
実施の形態２は、パッケージの配布後に、リモート実行部１３０が配布対象サーバ上のインストールパッケージの実行を行うため、完全自動にて更新反映が行われる。インストール実行結果は、結果ログ１３１としてライブラリ管理担当者５０に入手され、処理の成功失敗を確認できる。
【００１９】
実施の形態２によれば、遠隔から各管理対象サーバへのモジュールのインストールを実行することができるとともに、インストール結果を確認することができる。
【００２０】
実施の形態３．
図５は、この発明の実施の形態３によるライブラリ管理システムを示す構成図である。
図５において、１０〜５０、１０１、１１０〜１１５、１２０〜１２７、１３０、１３１は図４におけるものと同一のものである。図５では、管理対象サーバ１０、２０と、ライブラリ管理サーバ１０１、及びクライアントＰＣ３０は、距離的に離れた別の場所にあり、各々はＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）装置２０１を介したインターネット等の広域ネットワーク２００にて接続されている。
【００２１】
実施の形態３は、例えば管理対象サーバ１０、２０が遠隔地にあり、また申請者も各々別個の地域で作業している場合であっても、実施の形態１および実施の形態２がそのまま実現できる。実施の形態２により、ライブラリ管理担当者５０は、結果ログ１３１を参照して処理の結果を知ることができるため、リモートライブラリ管理が実現でき、作業者の移動の時間および金額的なコストが大幅に削減できる。
【００２２】
実施の形態３によれば、管理対象サーバ１０、２０やライブラリ管理サーバ１０１やクライアントＰＣ３０を広域ネットワーク２００を介して接続することにより、離れた場所から更新処理を行うことができる。
【００２３】
実施の形態４．
図６は、この発明の実施の形態４によるライブラリ管理システムの生成サーバを示す構成図である。
図６において、１２０〜１２７は図１におけるものと同一のものである。図６では、
図６では、生成サーバ１２０内に、それぞれ後述するチェック機能である、タグリストチェック部３０１と、バイナリ／アスキーチェック部３０２と、改行コード変換部３０３と、環境依存ファイルリストチェック部３０４と、環境キーワードチェック部３０５と、チェックサム生成部３０６とを持ち、さらに、環境依存ファイルリストチェック部３０４により参照される環境依存ファイルリスト３１０と、環境キーワードチェック部３０５により参照される環境キーワードリスト３１１とを持つ。
【００２４】
実施の形態４では、実施の形態１での各種作業ミスを、生成サーバ１２０の自動実行時のチェック機能により防止する。
タグリストチェック部３０１では、ライブラリ管理担当者５０によって記述されたタグリスト定義ファイル１２７のタグ文字列をチェックし、予め定義されたタグ文字列フォーマットに合致しているかどうか、および文字列中に使用を禁止された文字が入っていないかどうかをチェックする。並びに、該当タグ文字列でファイルを取得できるかどうかもチェックし、一つも取得できない場合はエラーとする。チェック結果がエラーであれば、自動実行部１２６に通知し、自動実行を停止させ、ユーザにエラーを返す。これにより、タグ文字列の連絡ミスおよび記述ミスをチェックする。
【００２５】
バイナリアスキーチェック３０２では、取得したファイルを拡張子毎にバイナリファイルかアスキーファイルかを判定し、判定結果と実際のファイルの属性を比較し、判定結果と取得ファイルの属性が異なっている場合には、更新登録ミスとしてユーザにエラーを返す。
改行コード変換部３０３では、バイナリアスキーチェック３０２でアスキーと判定された場合に、さらにファイルの改行コードをチェックし、指定された形式と異なる場合には改行コード変換を行う。
環境依存ファイルリストチェック部３０４では、環境依存部更新申請ファイル１１３を取得した場合に、そのファイルが環境依存ファイルリスト３１０中に存在するかどうかをチェックし、なければエラーを返す。これは共通部のファイルか環境依存部のファイルかの管理を環境依存ファイルリスト３１０で管理することによって、誤って共通部のファイルを環境依存部のファイルとして更新申請を行ったり、その逆を行ったりすることを防止するものである。
【００２６】
環境キーワードチェック部３０５では、取得した環境依存部更新申請ファイル１１３の内部を検索し、環境キーワードリスト３１１に含まれるキーワードが存在するかどうかをチェックする。環境キーワードリスト３１１の内部には、本番環境、開発環境といった環境毎にその環境に固有なキーワードが定義されており、チェックの結果、本番環境の環境依存部のファイル中に開発環境のキーワードが含まれるといった、異なる環境のキーワードがマッチした場合、更新登録ミスとしてユーザにエラーを返す。これにより、間違った環境に環境依存部のファイルが反映されることを防止するものである。
チェックサム生成部３０６では、配布パッケージ生成時に各配布対象のチェックサムを取得し、チェックサムリストをパッケージに付加する。このチェックサムリストは、インストール実行時に参照され、インストールファイルとチェックサムが異なっていた場合にエラーを発生させることで、配布実行時の通信路異常による破損ファイルが、インストールされることを防止する。
【００２７】
実施の形態４によれば、各種作業ミスを自動実行時のチェック機能により防止することができる。
【００２８】
実施の形態５．
図７は、この発明の実施の形態５によるライブラリ管理システムを示す構成図である。
図７において、１０〜５０、１０１、１１０〜１１５、１２０〜１２７、１３０、１３１、２００、２０１は図５におけるものと同一のものである。図７では、管理対象サーバ１０、２０に替えて、受注前に客先提案デモを行う客先提案デモサーバ４０１、および受注後に客先とともに仕様検討を行う仕様検討プロトサーバ４０２を広域ネットワーク２００を介してライブラリ管理サーバ１０１と接続するように配置する。
なお、客先提案デモサーバ４０１及び仕様検討プロトサーバ４０２は、客先に置かれる。客先提案デモサーバ４０１は、受注後には、仕様検討を行う際に複数案の仕様を同時に比較検討できるように、仕様検討プロトサーバ４０２と同様に使用する。
【００２９】
客先デモや仕様検討の際には、システムに対する修正が多数発生するが、この発明に係わるライブラリ管理システムを使用することにより、リモートにシステムの修正が可能になる。客先提案デモサーバ４０１と仕様検討プロトサーバ４０２という開発のための異なる複数の環境が存在する場合でも、一元的に管理対象ファイルの更新管理を実行できる。
なお、複数の環境としては、実運用される環境とその仕様変更などの修正を行う環境でもよいし、共通な仕様をベースに客先ごとに細部が異なる実運用される複数の環境でもよい。また、ネットワークで接続されていれば、各環境がどこに配置されていてもよい。
【図面の簡単な説明】
【００３０】
【図１】この発明の実施の形態１によるライブラリ管理システムを示す構成図である。
【図２】この発明の実施の形態１によるライブラリ管理システムの処理を示すフローチャートである。
【図３】この発明の実施の形態１によるライブラリ管理システムのモジュール生成環境作成方式を示す図である。
【図４】この発明の実施の形態２によるライブラリ管理システムを示す構成図である。
【図５】この発明の実施の形態３によるライブラリ管理システムを示す構成図である。
【図６】この発明の実施の形態４によるライブラリ管理システムの生成サーバを示す構成図である。
【図７】この発明の実施の形態５によるライブラリ管理システムを示す構成図である。
【符号の説明】
【００３１】
１０  本番環境の管理対象サーバ
２０  開発環境の管理対象サーバ
３０  クライアントＰＣ
４０  更新申請者
５０  ライブラリ管理担当者
１０１  ライブラリ管理サーバ
１１０  構成サーバ    
１１１  ライブラリ管理対象ファイル
１１２  共通部更新申請ファイル
１１３  環境依存部更新申請ファイル
１１４  バージョン管理部
１１５  タグ管理部
１２０  生成サーバ
１２１  更新反映管理部
１２２  モジュール生成環境作成部
１２３  モジュール生成部
１２４  配布対象パッケージ部
１２５  配布実行部
１２６  自動実行部
１２７  タグリスト定義ファイル
１３０  リモート実行部
１３１  結果ログ
２００  広域ネットワーク
２０１  ＶＰＮ装置
３０１  タグリストチェック部
３０２  バイナリ／アスキーチェック部
３０３  改行コード変換部
３０４  環境依存ファイルチェック部
３０５  環境キーワードチェック部
３０６  チェックサム生成部
３１０  環境依存ファイルリスト
３１１  環境キーワードリスト
４０１  客先提案デモサーバ
４０２  仕様検討プロトサーバ
【図１】
2008225762.tif 000003
【図２】
2008225762.tif 000004
【図３】
2008225762.tif 000005
【図４】
2008225762.tif 000006
【図５】
2008225762.tif 000007
【図６】
2008225762.tif 000008
【図７】
2008225762.tif 000009