(57)【要約】【課題】開発ネットワーク環境と運用ネットワーク環境との間のやり取りを一括管理することができる。【解決手段】配信サーバ１２は、運用ネットワーク環境３にリリースするためのプログラムモジュールを中立サーバ２１へ送信して、プログラムモジュールのリリース依頼をする転送処理部１２１を備え、中立サーバは、所定の承認者から、配信サーバからのリリース依頼を受け付けたプログラムモジュールのリリースを承認したことを示す情報の入力を受け付ける承認処理部２１４と、承認処理部が受け付けた入力に基づく承認履歴データを記憶するログ記憶部２１３と、承認者によってリリース承認されたプログラムモジュールを、リリースサーバへ配布ディレクトリ２１２と、を備える。【選択図】図１
2011065495.tif 000002
【特許請求の範囲】
【請求項１】
配信サーバを備えた、プログラム開発を行うための開発ネットワーク環境と、前記開発ネットワーク環境で開発されたプログラムモジュールを実行させる複数の業務サーバを備えた運用ネットワーク環境と、前記開発ネットワーク環境及び前記運用ネットワーク環境に接続された中立サーバとを備えたネットワークシステムであって、
前記配信サーバは、
前記運用ネットワーク環境にリリースするためのプログラムモジュールを前記中立サーバへ送信して、前記プログラムモジュールのリリース依頼をするリリース依頼手段を備え、
前記中立サーバは、
所定の承認者から、前記配信サーバからのリリース依頼を受け付けたプログラムモジュールのリリースを承認したことを示す情報の入力を受け付ける受付手段と、
前記受付手段が受け付けた入力に基づく承認履歴データを記憶する承認履歴記憶手段と、
前記承認者によってリリース承認されたプログラムモジュールを、前記リリースサーバへ送信する手段と、を備え、
前記リリースサーバは、
前記中立サーバから送信されたリリース承認されたプログラムモジュールを、前記複数の業務サーバが実行可能に前記運用ネットワーク環境内の他の機器に保存するインストール手段を備えるネットワークシステム。
【請求項２】
前記運用ネットワーク環境は、
前記複数の業務サーバと接続されている共有データ記憶部をさらに有し、
前記インストール手段は、前記リリース承認されたプログラムモジュールを前記共有データ記憶部に保存し、
前記複数の業務サーバは、前記共有データ記憶部を参照して、前記承認されたプログラムモジュールを実行する、請求項１記載のネットワークシステム。
【請求項３】
前記中立サーバは、前記リリースサーバから、前記インストール手段による前記承認されたプログラムモジュールのインストール結果を取得し、前記承認履歴記憶手段に格納する、請求項２記載のネットワークシステム。
【請求項４】
配信サーバを備えた、プログラム開発を行うための開発ネットワーク環境と、前記開発ネットワーク環境で開発されたプログラムモジュールを実行させる複数の業務サーバを備えた運用ネットワーク環境と、前記開発ネットワーク環境及び前記運用ネットワーク環境に接続された中立サーバとを備えたネットワークシステムにおけるプログラムモジュールをリリースする方法であって、
前記配信サーバが、
前記運用ネットワーク環境にリリースするためのプログラムモジュールを前記中立サーバへ送信して、前記プログラムモジュールのリリース依頼をするリリース依頼ステップを行い、
前記中立サーバが、
所定の承認者から、前記配信サーバからのリリース依頼を受け付けたプログラムモジュールのリリースを承認したことを示す情報の入力を受け付けるステップと、
前記受付手段が受け付けた入力に基づく承認履歴データを記憶する承認履歴記憶するステップと、
前記承認者によってリリース承認されたプログラムモジュールを、前記リリースサーバへ送信するステップと、を行い、
前記リリースサーバが、
前記中立サーバから送信されたリリース承認されたプログラムモジュールを、前記複数の業務サーバが実行可能に前記運用ネットワーク環境内の他の機器に保存するステップを行う方法。
【請求項５】
配信サーバを備えた、プログラム開発を行うための開発ネットワーク環境と、前記開発ネットワーク環境で開発されたプログラムモジュールを実行させる複数の業務サーバを備えた運用ネットワーク環境と、前記開発ネットワーク環境及び前記運用ネットワーク環境に接続された中立サーバとを備えたネットワークシステムにおいてプログラムモジュールをリリースするためのコンピュータプログラムであって、
前記配信サーバは、
前記運用ネットワーク環境にリリースするためのプログラムモジュールを前記中立サーバへ送信して、前記プログラムモジュールのリリース依頼をするリリース依頼手段を備え、
前記中立サーバは、
所定の承認者から、前記配信サーバからのリリース依頼を受け付けたプログラムモジュールのリリースを承認したことを示す情報の入力を受け付ける受付手段と、
前記受付手段が受け付けた入力に基づく承認履歴データを記憶する承認履歴記憶手段と、
前記承認者によってリリース承認されたプログラムモジュールを、前記リリースサーバへ送信する手段と、を備え、
前記リリースサーバは、
前記中立サーバから送信されたリリース承認されたプログラムモジュールを、前記複数の業務サーバが実行可能に前記運用ネットワーク環境内の他の機器に保存するインストール手段を備える、ネットワークシステムを構築するためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、開発ネットワーク環境と運用ネットワーク環境を備えたネットワークシステムに関する。
【背景技術】
【０００２】
従来では、開発環境と運用環境とが互いに独立の環境で構築されたシステムにおいて、これら別個の環境間に保存媒体を設けたことで、開発環境側に蓄積されるファイルを、運用環境側に移行させる技術が知られている（例えば特許文献１）。
【０００３】
特許文献１に示す技術は、ＣＯＲＢＡに準拠した分散オブジェクト環境において、開発環境において定義されるインターフェースリポジトリＩＲの情報をＩＤＬファイルとして抽出して保存媒体に記憶させておき、この保存媒体に記憶されたＩＤＬファイルを、全く異なる運用環境で展開して、その環境下でインターフェースリポジトリＩＲとして登録することにより開発環境と運用環境とを異なる環境として構築することが可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１１−３２７８８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、近年ではいわゆる日本版ＳＯＸ法対応として、開発者と運用者の職責分離の義務付けや、監査などの要件が厳しくなっている。このため、開発ネットワーク環境と運用ネットワーク環境とを明確に分離するとともに、開発ネットワーク環境から運用ネットワーク環境へアプリケーションをリリースする際にも監査のためのログを収集するなど、開発ネットワーク環境と運用ネットワーク環境との間のやり取りをきちんと管理しておく必要がある。
【０００６】
そこで、本発明の目的は、開発ネットワーク環境と運用ネットワーク環境との間のやり取りを一括管理することにある。
【課題を解決するための手段】
【０００７】
本発明の一つの実施態様に従うネットワークシステムは、配信サーバを備えた、プログラム開発を行うための開発ネットワーク環境と、前記開発ネットワーク環境で開発されたプログラムモジュールを実行させる複数の業務サーバを備えた運用ネットワーク環境と、前記開発ネットワーク環境及び前記運用ネットワーク環境に接続された中立サーバとを備えたネットワークシステムであって、前記配信サーバは、前記運用ネットワーク環境にリリースするためのプログラムモジュールを前記中立サーバへ送信して、前記プログラムモジュールのリリース依頼をするリリース依頼手段を備え、前記中立サーバは、所定の承認者から、前記配信サーバからのリリース依頼を受け付けたプログラムモジュールのリリースを承認したことを示す情報の入力を受け付ける受付手段と、前記受付手段が受け付けた入力に基づく承認履歴データを記憶する承認履歴記憶手段と、前記承認者によってリリース承認されたプログラムモジュールを、前記リリースサーバへ送信する手段と、を備え、前記リリースサーバは、前記中立サーバから送信されたリリース承認されたプログラムモジュールを、前記複数の業務サーバが実行可能に前記運用ネットワーク環境内の他の機器に保存するインストール手段を備える。
【０００８】
好適な実施態様では、前記運用ネットワーク環境は、前記複数の業務サーバと接続されている共有データ記憶部をさらに有し、前記インストール手段は、前記リリース承認されたプログラムモジュールを前記共有データ記憶部に保存し、前記複数の業務サーバは、前記共有データ記憶部を参照して、前記承認されたプログラムモジュールを実行する。
【０００９】
好適な実施態様では、前記中立サーバは、前記リリースサーバから、前記インストール手段による前記承認されたプログラムモジュールのインストール結果を取得し、前記承認履歴記憶手段に格納する。
【発明の効果】
【００１０】
本発明によれば、開発ネットワーク環境と運用ネットワーク環境との間のやり取りを一括管理することができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態にかかるネットワークシステムの全体構成図である。
【図２】ログ記憶部に記憶されたログの一例を示す図である。
【図３】承認展開部の機能を説明するための図である。
【図４】ＮＡＳの内部のデータ構造の一例を示す図である。
【図５】本実施形態にかかるネットワークシステムの通常時のリリース処理における動作の一例を説明するための説明図である。
【図６】通常時のリリース処理における、展開処理部の展開処理を示すフローチャートの一例である。
【図７】本実施形態にかかるネットワークシステムの緊急時のリリース処理における動作の一例を説明するための説明図である。
【図８】本実施形態にかかるネットワークシステムの切り戻し処理における動作の一例を説明するための説明図である。
【図９】切り戻し処理における、展開処理部の展開処理を示すフローチャートの一例である。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施形態にかかるネットワークシステムとして、開発ネットワーク環境で開発されたプログラムモジュールの運用ネットワーク環境へのプログラムモジュールのリリース処理などを行うシステムを一例に挙げ、図面を参照して詳細に説明する。
【００１３】
本実施形態にかかるネットワークシステムは、配信サーバ１２を備えた、プログラム開発を行うための開発ネットワーク環境１と、開発ネットワーク環境１で開発されたプログラムモジュールを実行させる複数の業務サーバ３３を備えた運用ネットワーク環境３と、開発ネットワーク環境１及び運用ネットワーク環境３に接続された中立サーバ２１とを備える。また、運用ネットワーク環境３は、複数の業務サーバ３３と接続されている共有データ記憶部をさらに備える。
【００１４】
図１は、本実施形態にかかるネットワークシステムの全体構成図である。図１を用いて、本ネットワークシステムの構成を以下に説明する。
【００１５】
本ネットワークシステムは、例えば図１に示すように、開発ネットワーク環境１と、中立ネットワーク環境２と、運用ネットワーク環境３とを備える。
【００１６】
開発ネットワーク環境１、運用ネットワーク環境３及び中立ネットワーク環境２は、各々が独立したネットワークシステムである。これらネットワークシステムは、それぞれＬＡＮなどのネットワーク内にサーバや記憶装置等が接続される。
【００１７】
開発ネットワーク環境１は、プログラムモジュール開発者側の環境であって、例えば図１に示すように、一または複数の開発側アプリケーションサーバ１１（以下、開発側ＡＰサーバという）と、配信サーバ１２とを備える。
【００１８】
開発側ＡＰサーバ１１は、例えば、アプリケーション開発に使用されるサーバである。開発側ＡＰサーバ１１には、開発者が開発したアプリケーションのプログラムモジュールが蓄積される。開発側ＡＰサーバ１１は、一つの開発ネットワーク環境につき１つのみ設置してもよいし、複数設置してもよい。
【００１９】
配信サーバ１２は、運用ネットワーク環境３にリリースするためのプログラムモジュールを中立サーバ２１へ送信して、プログラムモジュールのリリース依頼をするリリース依頼手段としての配信サーバ１２を備える。
【００２０】
配信サーバ１２は、転送処理部１２１と、抽出部１２２とを備える。
【００２１】
「所定のアプリケーションの所定バージョンのプログラムモジュールを運用ネットワーク環境３にリリースするように」との開発者からのリリース依頼が、端末装置４を通じて配信サーバ１２に受信された場合には、抽出部１２２は、例えば、開発者からリリース依頼のあった所定のアプリケーションの所定バージョンのプログラムモジュール（以下、対象モジュールという）を、開発側ＡＰサーバ１１から抽出する。このとき、対象モジュールは、開発者からリリース依頼のあった所定のアプリケーションの所定バージョンのプログラムモジュール群すべてではなく、運用ネットワーク環境３において、そのアプリケーションが現在稼働しているバージョン（以下、カレントバージョンという）との差分のプログラムモジュールのみである。
【００２２】
転送処理部１２１は、対象モジュールを中立サーバ２１へ転送することにより、中立サーバ２１に対象モジュールのリリースを依頼する。
【００２３】
例えば、中立サーバ１２１は、対象モジュールをアーカイブ処理し、アーカイブファイルとして中立サーバ２１へ転送する。
【００２４】
アーカイブファイルは、所定の単位、例えば業務ごとに作成するなどしてもよい。アーカイブファイルは、例えばそのファイル名として、そのアーカイブファイルに含まれる対象モジュールのリリース希望日と、対象モジュールのアプリケーション名及びバージョン名と、１つのアーカイブファイルで複数の対象モジュールをリリースする場合のリリース番号とを記載しておいてもよい。転送は、例えばＦＴＰ形式で行われる。
【００２５】
中立ネットワーク環境２は、開発ネットワーク環境１から運用ネットワーク環境３へ、プログラムモジュールをリリースする場合の中継をするとともに、開発ネットワーク環境１から運用ネットワーク環境３へのプログラムモジュールのリリースについて、一括管理を行うネットワークシステムである。
【００２６】
中立ネットワーク環境２には、例えば図１に示すように、中立サーバ２１が設置される。
【００２７】
中立サーバ２１は、所定の承認者から、配信サーバ１２からのリリース依頼を受け付けたプログラムモジュールのリリースを承認したことを示す情報の入力を受け付ける受付手段としての承認処理部２１４と、受付手段が受け付けた入力に基づく承認履歴データ（ログ）を記憶する承認履歴記憶手段としてのログ記憶部２１３と、承認者によってリリース承認されたプログラムモジュールを、リリースサーバ３１へ送信する手段としての転送処理部２１５と、を備える。中立サーバ２１は、また、移動ディレクトリ２１１と、配布ディレクトリとを備えてもよい。中立サーバ２１は、さらに、リリースサーバ３１から、後述するインストール手段による承認されたプログラムモジュールのインストール結果を取得し、ログ記憶部に格納する。
【００２８】
移動ディレクトリ２１１は、配信サーバ１２から送信されたアーカイブファイルが、一時的に保存されるディレクトリである。
【００２９】
配布ディレクトリ２１２は、例えば、承認処理部２１４によって、移動ディレクトリ２１１から移動してきた、後述する承認アーカイブファイルが保存されるディレクトリである。
【００３０】
承認処理部２１４は、リリース依頼を受けた対象モジュールの承認処理を行う。
【００３１】
例えば、承認処理部２１４は、対象モジュールが承認者に承認されたか否かを示す承認情報を端末装置４から受け付ける。ここで、承認情報とは、「対象モジュールについて運用ネットワーク環境３側にリリースしてほしい」と要請を、本システムとは別途に、承認者が開発者から受けた場合に、承認者が、その要請をアーカイブ単位で承認したか否かを示す情報である。なおここでは、承認者は、アーカイブファイル単位で承認を行っているが、アーカイブファイル単位で承認を行うのでなく、アーカイブファイル内のプログラムモジュール（対象モジュール）単位で承認を行っててもよい。
【００３２】
移動ディレクトリ２１１にアーカイブファイルが一時保存され、かつ、そのアーカイブファイルが承認された旨の承認情報を承認処理部２１４が受信した場合には、承認処理部２１４は、その承認されたアーカイブファイル(以下、承認アーカイブファイルという)を配布ディレクトリ２１２に移動させる。なお、移動ディレクトリ２１１がアーカイブファイルを受信し、かつ、そのアーカイブファイルの承認しない旨の承認情報を承認処理部２１４が受信した場合には、承認処理部２１４は、移動ディレクトリ２１１内のそのアーカイブファイルを破棄する。
【００３３】
また詳細は後述するが、承認処理部２１４は、リリース処理が完了したときには、展開処理部３１３から完了通知を受信する。そして、承認処理部２１４は、受信した完了通知の内容をログ記憶部２１３のログファイル４０に記録する。
【００３４】
転送処理部２１５は、配布ディレクトリ２１２に保存されている承認アーカイブファイルをリリースサーバ３１へ転送する。
【００３５】
例えば、転送処理部２１５は、タイマー送信機能を有しており、配布ディレクトリ２１２が受信した承認アーカイブファイルを、予めタイマー予約しておいた予約時間に、運用ネットワーク環境３内のリリースサーバ３１に転送する。転送は例えばＦＴＰ形式により行われる。
【００３６】
ログ記憶部２１３には、例えば、承認処理部２１４による処理についての情報を含むログが記憶される。例えば図２に、ログ記憶部２１３に記憶されたログファイル４０の一例を示す。ログファイル４０には、承認処理部２１４が承認情報をいつ受信したかを示す日時４１と、承認情報について誰が判断をしたかを示す承認者４２と、どのアーカイブファイルについての承認情報かを示すアーカイブファイル４３と、承認情報の内容について、承認がされたか否かを示す承認の有無４４と、承認がなされた場合に、後述する完了通知結果の内容が記憶される完了通知結果４５と、リリース処理が「通常」の処理であるか、「緊急」の処理であるか、若しくは、リリース処理に代えてバージョン「切り戻し」の処理が行われたかを示すリリースの種類４６と、が記憶される。
【００３７】
運用ネットワーク環境３は、例えば図１に示すように、リリースサーバ３１と、ＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｒａｇｅ）３２と、複数の業務サーバ３３と、運用監視サーバ３４とを備える。
【００３８】
リリースサーバ３１は、中立サーバ２１から送信されたリリース承認されたプログラムモジュールを、複数の業務サーバ３３が実行可能に運用ネットワーク環境３内の他の機器に保存するインストール手段を備える。他の機器は、例えばＮＡＳなどの共有データ記憶部、または、各業務サーバ３３のローカルの記憶部である。、また、インストール手段により、複数の業務サーバ３３は、共有データ記憶部を参照して、承認されたプログラムモジュールを実行する。
【００３９】
リリースサーバ３１は、例えば図１に示すように、受信ディレクトリ３１１と、プールディレクトリ３１２と、展開処理部３１３と、監視部３１４とを備える。
【００４０】
リリースサーバ３１は、中立サーバ２１から転送された承認アーカイブファイル展開処理し、対象モジュールを取り出すとともに、対象モジュールをＮＡＳ３２に反映する。ＮＡＳ３２に対象モジュールを反映した後、リリースサーバ３１は、ＮＡＳ３２への反映が正常に完了したか、異常な完了であったかが記録される完了通知を、業務サーバ３３及び中立ネットワーク環境２の承認処理部２１４に送信する。
【００４１】
受信ディレクトリ３１１は、中立サーバ２１の配布ディレクトリ２１２から転送された承認アーカイブファイルを一時的に蓄積するディレクトリである。
【００４２】
また、受信ディレクトリ３１１は、業務サーバ３３から送信されたフラグファイルを一時的に保存するディレクトリである。ここで、フラグファイルとは、リリース開始の合図として、後述の運用監視サーバ３４などからの指示により、業務サーバ３３などのサーバから送信されるファイルである。フラグファイルは、開発者、承認者若しくはオペレータなどによって、端末装置４から業務サーバ３３などに登録されている。フラグファイルには、例えば、リリース要請のあったアーカイブファイル名と、ＮＡＳ３２への反映が終了した後に完了通知を送付する業務サーバ３３などのＩＰアドレスとが記載される。
【００４３】
プールディレクトリ３１２には、受信ディレクトリ３１１から受け渡された承認アーカイブファイルが保存される
【００４４】
監視部３１４は、受信ディレクトリ３１１及びプールディレクトリ３１２を常時監視する。例えば、受信ディレクトリ３１１に、配布ディレクトリ２１２から転送されて承認アーカイブファイルが格納された場合には、監視部３１４は、格納された承認アーカイブファイルを、受信ディレクトリ３１１からプールディレクトリ３１２へ移動する。
【００４５】
また、受信ディレクトリ３１１が、業務サーバからフラグファイルを受信した場合には、監視部３１４は、プールディレクトリ３１２内に保存された承認アーカイブファイルの中から、そのフラグファイルに記載された承認アーカイブファイル名を展開処理部３１３に通知する。
【００４６】
図３は、承認展開部３１３の機能を説明するための図である。
【００４７】
展開処理部３１３は、監視部３１４からの通知を受け、通知された承認アーカイブファイルを展開処理して、対象モジュールを取り出す。
【００４８】
例えば、展開処理部３１３は、監視部３１４から通知された承認アーカイブファイル名に基づいて、対象モジュールのアプリケーション名及びバージョン名を特定する。そして、特定されたアプリケーション名及びバージョン名の更新ディレクトリｄを、展開処理部３１３の一時記憶部３１３ａ内に作成する。なお、作成された更新ディレクトリｄ名が、更新後の新たなバージョン名となる。
【００４９】
また、展開処理部３１３は、一時記憶部３１３ａの更新ディレクトリｄ内に、対象となるアプリケーションのカレントバージョンのプログラムモジュール群をＮＡＳ３２からコピーするとともに、そのフォルダ内に、対象モジュールを保存する。なお、前述したように、展開処理後の対象モジュールは、対象となるアプリケーションのカレントバージョンのプログラムモジュール群に対する差分のプログラムモジュールであるため、上述の処理により、更新ディレクトリｄ内に、対象となるアプリケーションの更新後の新たなバージョンのプログラムモジュール群が保存されることとなる。
【００５０】
さらに、展開処理部３１３は、一時記憶部内に作成された更新ディレクトリｄをＮＡＳ３２へ反映する。ＮＡＳ３２への反映については後述する。
【００５１】
また、リリース処理が完了したときには、展開処理部３１３は完了通知を作成し、作成した完了通知を、業務サーバ３３と、中立サーバ２１の承認処理部２１４とに送付する。なお、完了通知については後述する。
【００５２】
ＮＡＳ３２には、一または複数のアプリケーションの各バージョンのプログラムモジュールが一元管理されている。
【００５３】
ＮＡＳ３２は、例えば図４のようなディレクトリ構造を有する。業務サーバ３３でアプリケーションが実行される際には、点線の枠で示された部分のディレクトリ群５０が業務サーバ３３にマウントされる。業務サーバ３３へのマウントについては後述する。
【００５４】
点線内のディレクトリ群５０は、一つのアプリケーション５０１に対するディレクトリ群５０であって、業務名を示す（Ａｐｐ  Ｎａｍｅ）ディレクトリ５０２と、グループを示す二つの（ｐｒｏｄ）及び（Ｓｙｓ  ＩＤ）ディレクトリ５０３、５０４と、サブシステムを示す（ｗｗｗ）ディレクトリ５０５と、アーキテクチャのハードウェアを示す（ｘ８６＿６）ディレクトリ５０６及びＯＳ名を示す（ＲＨＥＬ）ディレクトリ５０７と、カレントディレクトリ５０８とを備える。
【００５５】
ＯＳ名を示すディレクトリ５０７は、その下位に、ディレクトリ名がプログラムのバージョンになっている一または複数のディレクトリ５０９（５０９ａ、５０９ｂ）を備える。各ディレクトリ５０９ａ、５０９ｂには、そのバージョンのプログラムモジュール群５１０が保存される。なお、カレントディレクトリ５０８は、仮想ディレクトリであって、カレントディレクトリ５０８からカレントバージョン名のディレクトリ（図４においては、バージョン２．０のディレクトリ５０９ｂ）にシンボリックリンク５１１が貼られている。これにより、使用者はカレントディレクトリ５０８を指定すれば、カレントバージョンのアプリケーションを使用できる。
【００５６】
展開処理部３１３によって、ＮＡＳ３２には、所定位置に、更新ディレクトリｄが反映される。ここで所定位置とは、例えば、ＯＳ名を示す（ＲＨＥＬ）フォルダ５０７の下位の位置の事である。つまり、展開処理部３１３によって反映された、更新ディレクトリｄに対応するバージョン名のディレクトリ５０９に、更新ディレクトリｄ内の各モジュールを格納する。反映されたバージョン名のディレクトリ５０９には、カレントディレクトリ５０８のシンボリックリンク５１１が貼られる。
【００５７】
上述した更新ディレクトリｄの反映が完了すると、業務サーバ３３には、展開処理部３１３から完了通知が通知される。完了通知には、承認アーカイブファイルについてリリースが正常に終了したか、異常終了であったかが記載される。
【００５８】
また、各業務サーバ３３は、所定のアプリケーションを実行するために、ＮＡＳ３２内のディレクトリ群５０をマウントする。ディレクトリ群５０のマウントは、例えば業務単位に行う。各業務サーバ３３には、それぞれ業務が割り当てられている。各業務サーバ３３は、自らに割り当てられた業務に関連するディレクトリ群５０をマウントする。
【００５９】
例えば、図４においては、各業務サーバ３３が行う業務の業務名を示すフォルダ５０２をマウントポイントとして、これ以下の点線枠内のディレクトリ群５０が業務サーバ３３にマウントされる。これにより、各業務サーバ３３は、マウントポイントである業務名を示すフォルダ５０２以下のディレクトリをローカルディレクトリと同様にアクセスできるようになる。従って、ＮＡＳに３２に更新ディレクトリｄを反映することで、各業務サーバ３３にプログラムモジュールを個別にインストールすることと同様の効果を得られる。一方、開発者側は、開発したプログラムモジュールを、ＮＡＳ３２に配布するだけで、各業務サーバ３３にプログラムモジュールを個別に配布したことと同様の効果を得られることとなる。
【００６０】
運用監視サーバ３４は、運用ネットワーク環境３内のすべての業務サーバ３３について、アプリケーションの使用状況を常時監視する。例えば、運用監視サーバ３４は、端末装置４からフラグファイルを受け取った業務サーバ３３に、そのフラグファイルを受信ディレクトリ３１１に通知するタイミングを知らせる。フラグファイルを通知するタイミングは、フラグファイルに記載されたアプリケーションないしはアプリケーションが属する業務が終了したときなどが、業務サーバ３３に使用されていないときである。また、オペレータが、業務処理の終了を確認してから、オペレータの手作業によりフラグファイルを受信ディレクトリに通知してもよい。
【００６１】
なお、運用ネットワーク環境３で何らかのエラーが発生した場合には、運用監視サーバ３４は、例えば、エラーが発生したサーバ３１、３３やＮＡＳ３２からアラームを受信し、アーカイブファイルのリリース処理を中断する。リリース処理の中断若しくはその他のエラーが発生した場合には、後述するアプリケーションのカレントバージョンの切り戻し処理を行う場合がある。
【００６２】
以下に、本実施形態にかかるネットワークシステムの通常時のリリース処理における動作を、図５を参照して説明する。
【００６３】
まず、開発者は、対象モジュールをリリースする旨の指示を端末装置４に入力し、配信サーバ１２へ送信する（Ｓ１）。
【００６４】
配信サーバ１２の抽出部１２２は、ステップＳ１での開発者の指示に基づき、指示された対象モジュールを開発側ＡＰサーバ１１から抽出する（Ｓ２）。
【００６５】
配信サーバ１２の転送処理部１２１は、抽出部１２２によって抽出された対象モジュールをアーカイブ処理し、これにより作成されたアーカイブファイルを中立サーバ２１の移動ディレクトリ２１１に転送する（Ｓ３）。
【００６６】
一方、本システムとは別に、開発者は、承認者に対し、ステップＳ１の対象モジュールについて、運用ネットワーク環境へのリリースを承認してほしいとの要請をする（Ｓ００）。要請を受けた承認者は、リリースを承認するか否かを決定し、その承認情報を端末装置４に入力する。端末装置４はその承認情報を中立サーバ２１の承認処理部２１４へ送信する（Ｓ４）。
【００６７】
承認処理部２１４は、承認情報に基づき、例えば図２に例示されたログファイル４０に、日時４１、承認者４２、アーカイブファイル４３、承認の有無４４、リリースの種類４６を追加し、ログ記憶部２１３に登録する（Ｓ５）。
【００６８】
ステップＳ３において移動ディレクトリ２１１が受信したアーカイブファイルについて、承認情報で承認されている場合には、承認処理部２１４は、移動ディレクトリ２１１内の承認アーカイブファイルを配布ディレクトリ２１２に移動する（Ｓ６）。
【００６９】
承認処理部２１４は、予め設定された予約時間に、配布ディレクトリ２１２内の承認アーカイブファイルを受信ディレクトリ３１１に送信する（Ｓ７）。
【００７０】
受信ディレクトリ３１１が承認アーカイブファイルを受信した場合には、監視部３１４は、受信ディレクトリ３１１内の承認アーカイブファイルをプールディレクトリ３１２に移動する（Ｓ８）。
【００７１】
運用ネットワーク環境３内のすべての業務サーバ３３について、アプリケーションの使用状況を監視している運用監視サーバ３４は、開発者からのフラグファイルを保持している業務サーバ３３に対して、そのフラグファイルに記載されているアプリケーションがどの業務サーバ３３でも実行されていない状態であるときに、その旨を業務サーバ３３に通知する（Ｓ９）。
【００７２】
ステップＳ９において、運用監視サーバ３４から、フラグファイルに記載されたアプリケーションについて、どの業務サーバ３３でも実行されていない状態である旨の通知を受け取った業務サーバ３３は、そのフラグファイルを受信ディレクトリ３１１に送信する（Ｓ１０）。
【００７３】
受信ディレクトリ３１１にフラグファイルが受信されたことを、運用監視サーバ３４が検知すると、運用監視サーバ３４は、フラグファイルに記載された承認アーカイブファイルを、プールディレクトリ３１２から抽出し、展開処理部３１３にコピーする（Ｓ１１）。
【００７４】
展開処理部３１３は、例えば図６に示す展開処理によって、承認アーカイブファイルから対象モジュールを取り出し、ＮＡＳ３２に反映する（Ｓ１２）。
【００７５】
展開処理部３１３は、対象モジュールのＮＡＳ３２への反映が、正常に終了したか若しくは異常終了であったかを検知する（Ｓ１３）。
【００７６】
検知の結果に基づき、展開処理部３１３は完了通知を作成し、業務サーバ３３へ送信する（Ｓ１４）。
【００７７】
また、展開処理部３１３は、完了通知を中立ネットワーク環境２の承認処理部２１４にも通知する（Ｓ１５）。
【００７８】
図６は、展開処理部３１３による展開処理を示すフローチャートの一例である。
【００７９】
展開処理部３１３は、プールディレクトリ３１２から抽出した承認アーカイブファイルに含まれる対象モジュールについて、そのアプリケーション名及びバージョン名を検出する（Ｓ１００）。
【００８０】
次に、展開処理部３１３は、一時記憶部に、検出したバージョン名を示す更新フォルダｄを作成する（Ｓ１０１）。
【００８１】
展開処理部３１３は、ＮＡＳ３２を参照して、検出したアプリケーションのカレントバージョンのバージョン名（１．０）を示すディレクトリ５０９ａを抽出し、バージョン名（１．０）を示すディレクトリ５０９ａ内のプログラムモジュール群を、ステップＳ１０１で作成した更新フォルダｄ内にコピーする（Ｓ１０２）。
【００８２】
展開処理部３１３は、ステップＳ１００でプールディレクトリ３１２から抽出した承認アーカイブファイルを展開し取り出した対象モジュールを、更新フォルダｄ内に保存する（Ｓ１０３）。
【００８３】
次に、展開処理部３１３は、更新フォルダｄをＮＡＳ３２へ反映する（Ｓ１０４）。
【００８４】
ステップＳ１３の検知の結果に基づき、展開処理部３１３は完了通知を作成し、業務サーバ３３及び中立サーバ２１の承認処理部２１４に送信する（Ｓ１０５）。
【００８５】
次に、本実施形態にかかるネットワークシステムの緊急時のリリース処理の動作を、図７を参照して以下に説明する。以下の説明では、緊急時における対象モジュールのリリース処理の動作が、通常時の対象モジュールのリリース処理の動作と異なる部分を中心に説明し、同じ動作については説明を割愛することがある。
【００８６】
緊急時には、フラグファイルは、リリースを要請した開発者によって業務サーバ３３に登録されるのではなく、例えば、開発者から承認の要請のあった承認者などによって承認処理部２１４に送付される。これは例えば、ステップＳ４において承認情報を承認処理部２１４に送付する際に、承認処理部２１４に一緒に送付しておく。
【００８７】
そして、承認処理部２１４は、フラグファイルを受信ディレクトリ３１１に送付する（Ｓ２１）。このため、通常時におけるステップＳ９及びステップＳ１０は省略される。
【００８８】
また、ステップＳ７に代えて、承認処理部２１４は、移動ディレクトリ２１１から配布ディレクトリ２１２が承認アーカイブファイルを受信すると、すぐに受信ディレクトリ３１１に送信する（Ｓ２２）。
【００８９】
次に、本実施形態に係るネットワークシステムのリリース処理の変形例として、ＮＡＳ３２内に保存される所定のアプリケーションのカレントバージョンの切り戻し処理の動作を、図８を参照して説明する。通常時における対象モジュールのリリース処理の動作と同じ動作については説明を割愛することがある。
【００９０】
アプリケーションのカレントバージョンの切り戻し処理は、主に、リリース処理の中断など、リリース処理が失敗した場合や、本システムにおいて何かしらのエラーが発生した時などに行われる。
【００９１】
まず、開発者は、ステップＳ１に代えて、ＮＡＳ３２上に記憶された、所定のアプリケーションのカレントバージョンを切り戻す旨の指示を端末装置４に入力し、指示ファイルとして配信サーバ１２へ送信する（Ｓ３１）。
【００９２】
このため、ステップＳ２は省略される。
【００９３】
ステップＳ３に代えて、配信サーバ１２の転送処理部１２１は、指示ファイルをアーカイブ処理してアーカイブファイルを作成し、そのアーカイブファイルを移動ディレクトリ２１１へ転送する（Ｓ３２）。
【００９４】
一方、本システムとは別に、開発者は、承認者に対し、ステップＳ３１の切り戻し指示ついて承認してほしいとの要請をする（Ｓ９９）。要請を受けた承認者は、ステップＳ４に代えて、その切り戻しについての承認情報を端末装置４に入力し、中立サーバ２１の承認処理部２１４へ送信する（Ｓ３３）。
【００９５】
切り戻し処理の際には、フラグファイルは、切り戻しを要請した開発者によって業務サーバ３３に登録されるのではなく、例えば、開発者から承認の要請のあった承認者などによって承認処理部２１４に送付される。これは例えば、ステップＳ３３において承認情報を承認処理部２１４に送付する際に、承認処理部２１４に一緒に送付しておく。
【００９６】
そして、承認処理部２１４は、フラグファイルを受信ディレクトリ３１１に送信する（Ｓ３４）。
【００９７】
ステップＳ５及びステップＳ６は通常時と同様である。
【００９８】
ステップＳ７に代えて、承認処理部２１４は、移動ディレクトリ２１１から配布ディレクトリ２１２が承認アーカイブファイルを受信すると、すぐに受信ディレクトリ３１１に送信する（Ｓ３５）。
【００９９】
ステップＳ８は通常時と同様である。
【０１００】
前述したように、フラグファイルはステップＳ４で承認処理部２１４に送付されるため、ステップＳ９及びステップＳ１０は省略される。
【０１０１】
ステップＳ１１は通常時と同様である。
【０１０２】
ステップＳ１２に代えて、展開処理部３１３は、例えば図９に示す展開処理によって、承認アーカイブファイルから指示ファイルを取り出し、指示に基づいてＮＡＳ３２内の該当バージョンの切り戻し処理を行う（Ｓ３６）。
【０１０３】
ステップＳ１３に代えて、展開処理部３１３は、該当バージョンの切り戻し処理が、正常に終了したか若しくは異常終了であったかを検知する（Ｓ３７）。
【０１０４】
ステップＳ１４及びステップＳ１５は通常時と同様である。
【０１０５】
図９は、カレントバージョン切り戻し処理の際の、展開処理部３１３による展開処理を示すフローチャートの一例である。
【０１０６】
展開処理部３１３は、プールディレクトリ３１２から抽出した承認アーカイブファイルを一時記憶部３１３ａに展開する（Ｓ２００）。
【０１０７】
展開処理部３１３は、一時記憶部３１３ａ内の指示ファイルを参照し、そこに記載されたアプリケーションのカレントバージョンをＮＡＳ３２から検出し、そのカレントバージョンを切り戻す（Ｓ２０１）。カレントバージョンの切り戻しは、カレントフォルダ５０８のシンボリックリンク５１０貼られる位置を、現在指示しているバージョン名のフォルダ５０９から上位のバージョン名のフォルダ５０９へ変更することで行われる。
【０１０８】
カレントバージョンの切り戻しが正常に行われたか否かの結果を検出した展開処理部３１３は、この結果に基づいて完了通知作成し、業務サーバ３３及び中立サーバ２１の承認処理部２１４に送信する（Ｓ２０２）。
【０１０９】
本実施形態によれば、開発ネットワーク環境１と運用ネットワーク環境３の間に中立ネットワーク環境２を設け、中立ネットワーク環境２内の中立サーバ２１に、プログラムモジュールの運用ネットワーク環境３へのリリース処理若しくは運用ネットワーク環境３においてのカレントバージョン切り戻し処理の際のログが記憶される。このため、中立サーバ２１によって、開発ネットワーク環境１及び運用ネットワーク環境３とのやり取り、とくに上記リリース処理や上記カレントバージョン切り戻し処理によるやり取りを一元管理することができる。
【０１１０】
本実施形態によれば、一または複数のアプリケーションの各バージョンのプログラムモジュールが一元管理されている。このため、開発者側は、開発したプログラムモジュールを、各業務サーバ３３を意識することなく、ＮＡＳ３２にのみリリースすればよい。
【０１１１】
また、本実施形態によれば、アプリケーションのバージョン情報が蓄積されたＮＡＳ３２内部の構造が、ディレクトリ構造となっている。このため、各業務サーバ３３は、必要に応じて、ＮＡＳ３２へアクセスすれば、ＮＡＳ３２内のアプリケーションのカレントバージョンを、自身にインストールされているのと同等に、使用できることとなる。
【０１１２】
また、アプリケーションのバージョン情報が蓄積されたＮＡＳ３２内部の構造が、ディレクトリ構造となっていることによって、プログラムモジュールのＮＡＳ３２へのリリースが失敗した場合であっても、上述したアプリケーションのカレントバージョンの切り戻し処理によって、容易に現状回復できる。
【０１１３】
以上、本発明の幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
【符号の説明】
【０１１４】
１      開発ネットワーク環境
２      中立ネットワーク環境
３      運用ネットワーク環境
４      端末装置
１１    開発側アプリケーションサーバ
１２    配信サーバ
２１    中立サーバ
３１    リリースサーバ
３３    業務サーバ
３４    運用監視サーバ
１２１  転送処理部
２１１  移動ディレクトリ
２１２  配布ディレクトリ
２１３  ログ記憶部
２１４  承認処理部
３１１  受信ディレクトリ
３１２  プールディレクトリ
３１３  展開処理部
３１４  監視部
【図１】
2011065495.tif 000003
【図２】
2011065495.tif 000004
【図３】
2011065495.tif 000005
【図４】
2011065495.tif 000006
【図５】
2011065495.tif 000007
【図６】
2011065495.tif 000008
【図７】
2011065495.tif 000009
【図８】
2011065495.tif 000010
【図９】
2011065495.tif 000011