リリースプログラム管理方法およびリリースプログラム管理システム
【課題】一旦リリースしたプログラムに不備があった場合に、プログラムの回復処理をするか否かを判定し管理することができるリリースプログラム管理方法を提供する。
【解決手段】本番用サーバ１０の記憶装置１１にプログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理テーブル１０１が記憶されており、ＣＰＵ１３（処理部）は、クライアントから入力されたリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、リリースグループ識別情報をもとにリリース管理テーブルを検索し、リリースグループ識別情報に関連付けられた監視期限日を取得し、リリースグループ回復処理要求の日が監視期限日を過ぎていないとき、リリースグループの回復処理をすることを特徴とする。
【解決手段】本番用サーバ１０の記憶装置１１にプログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理テーブル１０１が記憶されており、ＣＰＵ１３（処理部）は、クライアントから入力されたリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、リリースグループ識別情報をもとにリリース管理テーブルを検索し、リリースグループ識別情報に関連付けられた監視期限日を取得し、リリースグループ回復処理要求の日が監視期限日を過ぎていないとき、リリースグループの回復処理をすることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システム開発・運用・保守において、本番環境へリリースしたリリースプログラムの管理方法およびリリースプログラム管理システムに関する。
【背景技術】
【０００２】
従来技術において、プログラムを本番環境へリリースする仕組みについて、様々な検討がなされてきた。開発者から修正オブジェクトのリリース依頼があると、システム管理装置は、オブジェクトファイルが修正されているか否かを判定し、修正されていると判定した場合には、リリース対象オブジェクトファイルを、本番用オブジェクトファイルへリリースする（例えば、特許文献１参照）。なお、オブジェクトファイルとは、コンパイラがプログラムのソースコードをもとに生成したモジュールのことである。
【０００３】
また、一方で、プログラムのバージョンを戻す仕組みについても検討がなされてきた。リリース後にクライアントのプログラムの戻しが必要な事態が発生した場合には、サーバからクライアントへ戻すよう命令を発行し、クライアントではリリース前のバックアップを使用して元に戻すという方法がある（例えば、特許文献２参照）。
【特許文献１】特開平１１−２９６３５０号公報
【特許文献２】特開２００１−３５０６３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
前記した特許文献２に開示された技術によれば、クライアントは、機能毎に独立したプログラムの場合にはサーバからの指示によって戻すことができる。しかしながら、サーバから配布されるプログラムは、多数の機能が複雑に入り組んだプログラムが多く、サーバからの差し戻しの指示が問題となる。
【０００５】
システム管理者が、一旦プログラムをリリースした後でプログラムの戻しをする際に、戻す対象のプログラムを手動で選別したり、プログラムを戻す作業を手動で実行したりしてしまうと、手動のために人為的なミスが発生する可能性があり、更に障害が拡大する恐れがある。
【０００６】
プログラムをリリースする仕組みにおいては、整合性をとってリリースしたり安全にリリースしたりするための仕組みは検討されてきたが、万一リリースしたプログラムに不備があった場合に、それを整合性をとって戻す仕組みが十分に検討された例は無かった。
【０００７】
本発明は、前記の課題を解決するための発明であって、一旦リリースしたプログラムに不備があった場合に、プログラムの回復処理をするか否かを判定し管理することができるリリースプログラム管理方法およびリリースプログラム管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記目的を達成するために、記憶部（例えば、記憶装置１１）、処理部（例えば、ＣＰＵ１３）を有する管理サーバ（例えば、本番用サーバ１０）を備える情報処理システム（リリースプログラム管理システム）において、リリースするプログラムの管理をするリリースプログラム管理方法は、プログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報（例えば、リリースグループＩＤ）、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理情報（例えば、リリース管理テーブル１０１）が記憶部に記憶されており、
処理部は、クライアントから前記リリースグループに障害があった際に、以前のリリースグループに回復する処理要求であるリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、リリースグループ識別情報をもとにリリース管理情報を検索し、リリースグループ識別情報に関連付けられた監視期限日を取得し、リリースグループ回復処理要求の日が監視期限日を過ぎていないとき、リリースグループの回復処理（例えば、プログラム戻しの処理）をし、リリースグループ回復処理要求の日が監視期限日を過ぎているとき、リリースグループの回復処理をしないことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、一旦リリースしたプログラムに不備（障害）があった場合に、プログラムの回復処理をするか否かを判定し管理することができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施形態について、図面を参照して説明する。
図１は、本発明の実施形態に係わるプログラムリリース処理およびプログラム戻し処理を示す説明図である。プログラムリリース処理（図６から図８参照）およびプログラム戻し処理（図１０から図１２参照）の詳細については後述するものとし、図１においては概要のみ説明する。
【００１１】
本実施形態によれば、一旦プログラムをリリースした後にプログラム戻しの処理をする際に、関連性のある複数のプログラムをまとめて元の状態に戻すことのできるよう、リリースグループという概念を採用している。リリースグループとは、ある機能に対応するためにリリースされるプログラム群であり、プログラムをリリースする際には、リリースする機能毎に１つのリリースグループＩＤ（リリースグループ識別情報）を定義し、その機能のためにバージョンアップされる全てのプログラムはそのリリースグループに属するように設定する。リリース後にその機能に関連するプログラムの戻しをする際には、そのリリースグループに属する全てのプログラムを、予め退避していたリリース前のプログラムに戻すことができる。以下、具体的に説明する。
【００１２】
処理部（図２参照、ＣＰＵ１３）は、リリース日になりリリース処理要求を受理すると、プログラムリリース処理を開始する。ステップＳ７０１にて、リリース日になりリリース処理要求を受理すると、プログラムの処理要求をリリース管理テーブル１０１（リリース管理情報）からリリース対象となるプログラム名称、リリースグループＩＤ（リリースグループ識別情報）を取得する。プログラムをリリースする際には、リリースする機能毎に１つのリリースグループＩＤを定義し、その機能のためにバージョンアップされる全てのプログラムは、そのリリースグループに属するように設定されている。
【００１３】
ステップＳ７０２にて、バックアップとして、現在リリースされているリリース対象のリリースグループに属するプログラムを、本番稼動資源用ライブラリ１０３から、資源退避用ライブラリ１０５にコピーしてバックアップを取得する。ステップＳ７０３にて、今回リリースするリリース対象のリリースグループに属するプログラムを、リリース前資源用ライブラリ１０４から、本番稼動資源用ライブラリ１０３へコピーし、コピーされた本番稼動資源用ライブラリ１０３のプログラムをリリースする。
【００１４】
処理部は、プログラム戻し要求を受理すると、プログラム戻し処理を開始する。ステップＳ７０４にて、プログラム戻し処理画面１３０１（図１９参照）から、戻す対象のリリースグループＩＤを取得する。ステップＳ７０５にて、取得したリリースグループＩＤに属するプログラムを、資源退避用ライブラリ１０５から本番稼動資源用ライブラリ１０３に戻し、リリースすることにより、プログラムのバックアップの戻しを行う。
【００１５】
具体的には、リリースグループを、Ｂ０００１、Ｂ０００２、Ｂ０００３として説明する。プログラムリリース処理において、今回のリリースされるグループがＢ０００３であると、今回のリリース前においては、リリース前資源用ライブラリ１０４には、Ｂ０００３が格納されており、本番稼動資源用ライブラリ１０３には、Ｂ０００２が格納されており、資源退避用ライブラリ１０５には、Ｂ０００１が格納されている。
【００１６】
プログラムリリース処理により、本番稼動資源用ライブラリ１０３から、資源退避用ライブラリ１０５にコピーしてバックアップを取得し、Ｂ０００２が格納される。また、リリース前資源用ライブラリ１０４から、本番稼動資源用ライブラリ１０３へコピーし、本番稼動資源用ライブラリ１０３には、Ｂ０００３が格納される。そして、Ｂ０００３がリリースされる。一方、プログラム戻し処理においては、資源退避用ライブラリ１０５から本番稼動資源用ライブラリ１０３に戻し、Ｂ０００２がリリースされる。
【００１７】
図２は、本発明の実施形態に係わるリリースプログラム管理システムを示す構成図である。リリースプログラム管理システム（情報処理システム）は、本番用サーバ１０（管理サーバ）、ＳＩ管理用サーバ２０、作業用クライアント３０（クライアント）を有し、本番用サーバ１０、ＳＩ管理用サーバ２０、作業用クライアント３０は、ＬＡＮ（Local Area Network）４０などのネットワークで相互に接続されている。なお、ＳＩはSystem Integratorの略である。
【００１８】
本番用サーバ１０は、記憶装置１１、メモリ１２、ＣＰＵ１３（処理部）、通信部１４を有している。記憶装置１１は、本番用サーバ１０が処理を実行するための各種データを保存する。メモリ１２は、本番用サーバ１０が処理を実行する各種プログラムおよび一時的なデータを保持する。ＣＰＵ１３は、メモリ１２に格納される各種プログラムを実行する。通信部１４は、ＬＡＮ４０を介して、他の装置と各種データやコマンドを交換する。
【００１９】
メモリ１２には、プログラムをリリースする際にリリースする機能毎に１つのリリースグループＩＤとして設定するリリースグループ設定部１１１、リリースする際に前処理・後処理などの実行処理を登録するリリース時実行処理登録部１１２、所定日時になるとプログラムリリースの処理をするプログラムリリース処理部１１３、障害監視システムからの起動命令により異常終了調査の処理をする異常終了調査処理部１１４、リリースプログラムの戻し処理をするプログラム戻し処理部１１５が格納される。
【００２０】
記憶装置１１には、リリースプログラムの管理テーブルであるリリース管理テーブル１０１（図１３参照）、リリース時の実行処理の定義テーブルであるリリース時実行処理定義テーブル１０２（図１４参照）、本番稼動のリリースプログラムを格納する本番稼動資源用ライブラリ１０３（図２３参照）、次回リリースするリリース前のリリースプログラムを記憶するリリース前資源用ライブラリ１０４（図２４参照）、本番稼動資源用ライブラリのバックアップを記憶する資源退避用ライブラリ１０５（図２５参照）、リリース時の実行処理用プログラムを記憶するリリース時実行処理用ライブラリ１０６（図２６参照）が格納される。
【００２１】
ＳＩ管理用サーバ２０は、記憶装置２１、ＣＰＵ２２、メモリ２３、通信部２４を有している。記憶装置２１には、リリースプログラムの管理ライブラリであるＳＩ管理用ライブラリ１２１（図２１参照）、リリース時の実行処理シェル、プログラムなどの管理ライブラリであるリリース時実行処理管理用ライブラリ１２２（図２２参照）が格納されており、ＣＰＵ２２で実行されている処理から必要に応じて読み込まれる。通信部２４は、ＬＡＮ４０を介して、他の装置と各種データやコマンドを交換する。
【００２２】
作業用クライアント３０は、ＣＰＵ３１、メモリ３２、通信部３６を有し、ディスプレイ３３、キーボード３４、マウス３５を接続している。作業者は、ディスプレイ３３に表示される画面を見て、キーボード３４およびマウス３５を使用して操作を行う。ディスプレイ３３には、リリースグループ設定画面１１０１（図１７参照）、リリース時実行処理登録画面１２０１（図１８参照）、プログラム戻し処理画面１３０１（図１９参照）が表示され、状況に応じて、本番用サーバ１０で実行されるリリースグループ設定部１１１、リリース時実行処理登録部１１２、異常終了調査処理部１１４、プログラム戻し処理部１１５と、通信部１４，３６およびＬＡＮ４０を介して通信を行う。
【００２３】
図１３は、リリース管理テーブルの一例を示す説明図である。リリース管理テーブル１０１は、リリースグループＩＤ９０１、リリースグループ名９０２、プログラム名称９０３、リリース日９０４、監視期限日９０５、後述する図２０で示される状態９０６を有している。例えば、リリースグループＩＤ９０１がＢ０００１の場合は、マスタの項目を追加対応するリリースグループ名であり、プログラムとしては、ＰＡ１１．ｅｘｅ、ＰＡ１２．ｅｘｅ、ＳＡ１１．ｃｓｈなどがある。
【００２４】
監視期限日９０５は、本実施形態の特徴とする項目であり、繰り返しリリースされるプログラムの日程管理をするための項目である。一度、リリースされたプログラムを再度リリースする際に、同じプログラム名称があるとき、最も新しい監視期限日を取得し、リリースグループ設定部１１１が受理したリリース日が最も新しい監視期限日を過ぎているとき、該当するプログラムをリリースグループに設定登録することができる。具体的には、ＰＡ１１．ｅｘｅのプログラムを次回リリースする場合には、リリースグループ設定部１１１は、リリース管理テーブル１０１を検索し、レコード９１１およびレコード９１２を抽出し、レコード９１２に示される監視期限日が最も新しい日である２００８年８月４日（２００８／０８／０４）を取得する。したがって、次回リリース日は、２００８年８月５日以降であれば設定登録することができる。例えば、ＰＡ１１．ｅｘｅのプログラムの場合、レコード９１１の監視期限日は２００８年７月２８日であるので、レコード９１２において、リリース日は、２００８年７月２９日として登録されていることがわかる。
【００２５】
図１４は、リリース時実行処理定義テーブルの一例を示す説明図である。リリース時実行処理定義テーブル１０２は、リリースグループＩＤ１００１、実行タイミング１００２、実行順１００３、プログラム名称１００４を有している。例えば、レコード１０１１に示すＢ０００１＿１１．ｃｓｈのプログラムの場合、リリースされる前の前処理のプログラムを意味し、レコード１０１２のＢ０００１＿２１．ｃｓｈのプログラムの場合、リリース後の後処理のプログラムを意味する。
【００２６】
次に処理フローについて説明する。
（リリースグループ設定の処理）
図３および図４は、リリースグループ設定の処理を示すフロー図である。図１３に示すリリース管理テーブル１０１および図１７に示すリリースグループ設定画面表示例を、適宜参照して説明する。リリースグループ設定の処理は、メモリ１２に格納されるリリースグループ設定部１１１のプログラムをＣＰＵ１３が実行することで実現される。
【００２７】
図１７は、リリースグループ設定画面例を示す説明図である。図１７（ａ）に示すリリースグループ設定画面１１０１は、リリースグループ設定処理の実行時に作業用クライアント３０のディスプレイ３３に表示する画面表示例である。リリースグループ設定画面１１０１には、リリースグループＩＤ１１０２、リリースグループ名１１０３、リリース日１１０４、監視期限日１１０５、プログラム名称１１０６のフィールド、メッセージ表示エリア１１０７、実行ボタン１１０８、システム日付１１１０のフィールドを有している。なお、図１７（ｂ）の画面については後述する。
【００２８】
図３に戻り、ＣＰＵ１３（処理部）は、ステップＳ２０１において、リリースグループ設定画面１１０１の実行ボタン１１０８が押下されたのを検知すると、ステップＳ２０２において、リリースグループ設定画面１１０１のリリース日１１０４、プログラム名称１１０６のフィールドに入力されたデータを取得し、ステップＳ２０３からステップＳ２０７までの処理を、取得したプログラム名称の数分繰り返す。
【００２９】
ステップＳ２０４において、リリース管理テーブル１０１を、リリースグループ設定画面から取得したプログラム名称１１０６をキーに検索し、リリース管理テーブル１０１から、ヒットしたリリース管理テーブル１０１のレコードの中から最も新しい監視期限日９０５を取得する。もし該当するレコードがリリース管理テーブル１０１に存在しない場合には、「０」を取得する。ステップＳ２０５では、ステップＳ２０４で取得した監視期限日が画面のリリース日１１０４以降であるか否かを条件判定する。条件を満たす場合には（ステップＳ２０５，Ｙｅｓ）、「監視期間中のためリリース登録できません」のメッセージをリリースグループ設定画面１１０１のメッセージ表示エリア１１０７に表示し（ステップＳ２０６）、処理を終了する。条件を満たさない場合には（ステップＳ２０５，Ｎｏ）、処理を続行する。
【００３０】
図１７（ｂ）には、ステップＳ２０６での画面表示例を示している。図１７（ｂ）においては、リリースグループＩＤがＢ０００３を、システム日付１１１０が２００８年８月１日に、その日のうちにリリースグループ設定を試みた場合である。この場合、ステップＳ２０４において、プログラム名称１１０６中のＰＡ１１．ｅｘｅをキーとしてリリース管理テーブル１０１（図１３参照）のレコードの中から最も新しい監視期限日９０５を取得すると、２００８年８月４日である。ステップＳ２０５において、リリース日１１０４の２００８年８月１日は、取得した監視期限日（２００８年８月４日）以前のために、ステップＳ２０６において、メッセージ表示エリア１１０７に「監視期間中のためリリース登録できません（ＰＡ１１．ｅｘｅ）」が表示されている。なお、メッセージ表示エリア１１０７には、どのプログラムが監視期間中であるかも表示されており、作業者は容易に、どのプログラムが適切でないかを知ることができる。
【００３１】
ここで、ステップＳ２０５のチェックを実施している理由を具体的に、図２７を参照して説明する。監視期限日は、リリースされるプログラムの管理と、リリースプログラムを戻すか否かの判断とに利用される。
【００３２】
図２７は、比較例を示す説明図である。比較例では、以下のような現象が想定される。なお、以下のプログラム名称などは例示として示す。また、リリースされるリリースグループは、Ａ０００１およびＡ０００２があるとして説明する。Ａ０００１およびＡ０００２は、複数のプログラムのまとめたリリースグループであり、同じプログラム「ＰＡ０１．ｅｘｅ」を含んでいる。リリースグループのＡ０００１は、リリース日が２００８年９月１日（２００８／０９／０１）であり、リリースグループのＡ０００２は、リリース日が２００８年９月８日（２００８／０９／０８）とする。
【００３３】
仮に、２００８年９月１２日（２００８／０９／１２）に、リリースグループのＡ０００１に含まれる他のプログラム「ＰＡ０２．ｅｘｅ」に不具合があることが判明し、それを元のバージョンに戻してシステムを動かしたいとする。元のバージョンの「ＰＡ０２．ｅｘｅ」が動くためには、リリースグループのＡ０００１のリリース時にリリースした他のプログラムも元のバージョンに戻しておかないとプログラム間の整合性が取れなくなるおそれがあるため、リリースグループのＡ０００１に含まれる全プログラムの戻しを行う必要がある。
【００３４】
しかし、リリースグループのＡ０００１に含まれる全プログラムをＡ０００１のリリース前のプログラムに戻してしまうと、リリースグループのＡ０００２で修正した内容が反映されていない２００８年９月１日より前のバージョンの「ＰＡ０１．ｅｘｅ」が戻されてしまうことになり、そのバージョンのプログラム「ＰＡ０１．ｅｘｅ」はシステム日付が２００８年９月１２日の時点の環境では正常に動作しない可能性がある。
【００３５】
具体的には、リリースグループのＡ０００１のリリース時に、ある業務マスタ１、業務マスタ２の両者にＡという項目を追加し、リリースグループのＡ０００２のリリース時に、ある業務マスタ２、業務マスタ３の両者にＢという項目を追加した場合である。例えば、リリースグループのＡ０００２のリリース後は、業務マスタ２には項目Ａ，Ｂ両方がある状態だが、２００８年９月１日より前の「ＰＡ０１．ｅｘｅ」は、項目Ａ，Ｂのどちらもない時点のプログラムであるため、リリースグループのＡ０００１のプログラム戻し時に業務マスタ１、業務マスタ２からＡという項目を削除したとしても、業務マスタ２にはＢという項目が残ったままのため、マスタの読み込みなどで不具合の発生する可能性がある。
【００３６】
このとき、リリースグループのＡ０００１の全プログラムを戻すだけでなく（対策１参照）、更にリリースグループのＡ０００２の全プログラムも戻す（対策２参照）、という方法も考えられる。しかし、リリースグループのＡ０００２に含まれる他のプログラムが、更に、リリースグループのＡ０００１のリリース日以降にリリースされた他のリリースグループに入っている可能性もあり、その場合はそのリリースグループの全プログラムも元に戻さないとプログラム間の整合性が取れなくなる可能性が出てくる。このように、リリースグループのプログラムを戻すには他のリリースグループの戻しも必要になることがある。これらの影響調査をシステム的に実装すると複雑になる。
【００３７】
本実施形態によれば、ステップＳ２０５の制限を課し、しかも、後述するプログラム戻しの処理をするときには、ステップＳ６０７（図１０参照）の制限を課すことにより、リリースプログラムの管理を容易にすることができる。
【００３８】
図４において、ステップＳ２２１からステップＳ２２３は、リリースグループ設定画面１１０１のプログラム名称１１０６の数分繰り返す。ステップＳ２２２では、リリース管理テーブル１０１にレコードを追加する。追加するレコードには、リリースグループ設定画面１１０１の同名の項目をそれぞれセットする。即ち、リリースグループＩＤ９０１の項目にはリリースグループＩＤ１１０２のフィールドの入力値を、リリースグループ名９０２の項目にはリリースグループ名１１０３のフィールドの入力値、プログラム名称９０３にはプログラム名称１１０６のフィールドの入力値、リリース日９０４にはリリース日１１０４のフィールドの入力値、監視期限日９０５には監視期限日１１０５のフィールドの入力値をそれぞれセットする。また、状態９０６の項目は「０」をセットする。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０１の状態になっている。
【００３９】
ステップＳ２２４からステップＳ２２８については、リリースグループ設定画面１１０１のプログラム名称１１０６の数分繰り返す。ステップＳ２２５では、ＳＩ管理用サーバ２０のＳＩ管理用ライブラリ１２１のパス名（図２１に示す、／ＳＩ＿ＫＡＮＲＩ／ｂｉｎ／ の例示参照）を取得し、リリースグループ設定画面１１０１のプログラム名称１１０６と名称が一致するファイルをＦＴＰでダウンロードする。
【００４０】
ステップＳ２２６では、本番用サーバ１０のリリース前資源用ライブラリ１０４のパス名（図２４に示す、／ｒｅｌｅａｓｅ／の例示参照）を取得し、ステップＳ２２５でダウンロードしたファイルを、本番用サーバ１０のリリース前資源用ライブラリ１０４へコピーする。ステップＳ２２７では、リリースグループ設定画面１１０１のリリースグループＩＤ１１０２、プログラム名称１１０６をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「１」に更新する。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０２の状態になっている。そして、一連のリリースグループ設定の処理を終了する。
【００４１】
（リリース時実行処理登録の処理）
図５は、リリース時実行処理登録の処理を示すフロー図である。図１３に示すリリース管理テーブル１０１、図１４に示すリリース時実行処理定義テーブル１０２および図１８に示すリリース時実行処理登録画面表示例を、適宜参照して説明する。リリース時実行処理登録の処理は、メモリ１２に格納されるリリース時実行処理登録部１１２のプログラムをＣＰＵ１３が実行することで実現される。
【００４２】
図１８は、リリース時実行処理登録画面表示例を示す説明図である。リリース時実行処理登録画面１２０１は、リリース時実行処理登録の実行時に作業用クライアント３０のディスプレイ３３に表示する画面表示例である。リリース時実行処理登録画面１２０１には、リリースグループＩＤ１２０２、リリースグループ名１２０３、リリース日１２０４、監視期限日１２０５、実行タイミング１２０６、実行順１２０７、プログラム名称１２０８のフィールド、実行ボタン１２０９、システム日付１２１０のフィールドを有している。
【００４３】
図５に戻り、ＣＰＵ１３は、ステップＳ３０１では、リリース時実行処理登録画面１２０１のリリースグループＩＤ１２０２が更新されたのを検知し、ステップＳ３０２では、リリース時実行処理登録画面１２０１のリリースグループＩＤ１２０２をキーにリリース管理テーブル１０１からリリースグループ名９０２、リリース日９０４、監視期限日９０５の項目を取得し、それぞれリリース時実行処理登録画面１２０１の図１８におけるリリースグループ名１２０３のフィールド、リリース日１２０４のフィールド、監視期限日１２０５のフィールドに表示する。
【００４４】
ステップＳ３０３では、リリース時実行処理登録画面１２０１の実行ボタン１２０９が押下されたのを検知し、ステップＳ３０４では、リリース時実行処理登録画面１２０１からプログラム名称１２０８を取得し、ステップＳ３０５からステップＳ３０９をプログラム名称の数分繰り返す。
【００４５】
ステップＳ３０６では、リリース時実行処理定義テーブル１０２にレコードを追加する。追加するレコードの各項目の値は、リリース時実行処理登録画面１２０１の同名の項目をそれぞれセットする。即ち、リリースグループＩＤ１００１にはリリースグループＩＤ１２０２のフィールドの入力値を、実行タイミング１００２には実行タイミング１２０６のフィールドの入力値を、実行順１００３には実行順１２０７のフィールドの入力値を、プログラム名称１００４にはプログラム名称１２０８のフィールドの入力値をセットする。
【００４６】
ステップＳ３０７では、ＳＩ管理用サーバ２０のリリース時実行処理管理用ライブラリ１２２のパス名（図２２に示す、／ＳＩ＿ＫＡＮＲＩ／ｒｅｌｅａｓｅ＿ｅｘｅｃ／の例示参照）を取得し、リリース時実行処理登録画面１２０１のプログラム名称１２０８と名称が一致するファイルをＦＴＰでダウンロードする。
【００４７】
ステップＳ３０８では、本番用サーバ１０のリリース時実行処理用ライブラリ１０６のパス名（図２６に示す、／ｒｅｌｅａｓｅ＿ｅｘｅｃ／の例示参照）を取得し、ステップＳ３０７でダウンロードしたファイルを、本番用サーバ１０のリリース時実行処理用ライブラリ１０６へコピーする。そして、一連のリリース時実行処理登録の処理を終了する。
【００４８】
（プログラムリリースの処理）
図６から図８は、プログラムリリースの処理を示すフロー図である。図１３に示すリリース管理テーブル１０１を、適宜参照して説明する。プログラムリリースの処理は、メモリ１２に格納されるリリースグループ設定部１１１のプログラムをＣＰＵ１３が実行することで実現される。
【００４９】
図６に示すように、ＣＰＵ１３は、ステップＳ４０１にて、リリース管理テーブル１０１から、リリース日９０４＝システム日付、かつ、状態９０６＝「１」の条件を満たすレコードを検索し、全項目を取得する。ステップＳ４０２からステップＳ４０５は、取得したレコードの数分繰り返す。
【００５０】
ステップＳ４０３では、取得したレコードについて、リリース管理テーブル１０１のプログラム名称９０３と名称が一致するファイルを、本番稼動資源用ライブラリ１０３から資源退避用ライブラリ１０５へコピーする。ステップＳ４０４では、リリースグループＩＤ９０１とプログラム名称９０３をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「２」に更新する。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０３の状態になっている。
【００５１】
図７に示すように、ＣＰＵ１３は、ステップＳ４２１では、リリース管理テーブル１０１から、状態９０６＝「２」の条件を満たすレコードのリリースグループＩＤ９０１を取得する。ステップＳ４２２からステップＳ４２４は、取得されたリリースグループＩＤの数分繰り返す。ステップＳ４２３では、リリース管理テーブル１０１に、取得されたリリースグループＩＤ＝リリース管理テーブルのリリースグループＩＤ９０１、かつ、状態９０６が２以外のレコードが存在するか否かを判定する。存在した場合は（ステップＳ４２３，Ｙｅｓ）、ディスプレイ３３にプログラムリリースのＥｒｒｏｒ表示をし（ステップＳ４５０）、処理を終了する。存在しなかった場合は（ステップＳ４２３，Ｎｏ）、処理を続行する。
【００５２】
ここで、ステップＳ４２３での判定条件について具体的に説明する。リリース対象となるプログラムは、リリース管理テーブル１０１の状態９０６の項目が「２」となっているレコードのプログラム名称をもつプログラムであり、リリース処理はリリースグループ毎に実行される。もし、同じリリースグループＩＤを持つレコードに、状態が「１」のレコードが存在している場合には、何らかの異常な事態が発生している可能性があり、処理を直ちに停止する。
【００５３】
前記のような事態が発生するケースとして、以下の場合がある。プログラムリリース処理は重複して実行されることがないことを想定しているが、仮に重複して実行されたとして、一方でステップＳ４０３のプログラム退避を行っている最中に、他方でステップＳ４２３の条件判定が行われた場合である。
【００５４】
もし、ステップＳ４２３の条件判定をせずに以降の処理が流れ、図６に示すステップＳ４４２が実行されると、ステップＳ４０３のプログラム退避が完了していないリリースグループに対して、ステップＳ４４２でプログラムリリースをしてしまう可能性がある。このような事態を防止するため、ステップＳ４２３の条件判定を行っている。
【００５５】
ステップＳ４２５からステップＳ４４９は、ステップＳ４２１で取得されたリリースグループＩＤの数分繰り返す。
【００５６】
ステップＳ４２６は、リリース時実行処理定義テーブル１０２から、ステップＳ４２１で取得したリリースグループＩＤ＝リリース時実行処理定義テーブル１０２のリリースグループＩＤ１００１、かつ、実行タイミング１００２＝「１」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。
【００５７】
ステップＳ４２７からステップＳ４２９は、ステップＳ４２６で取得したレコードの数分繰り返す。ステップＳ４２８は、取得したリリース時実行処理定義テーブル１０２のプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。
【００５８】
ステップＳ４３０では、ステップＳ４２５で取得したリリースグループＩＤをキーにリリース管理テーブル１０１を検索し、プログラム名称９０３を取得する。
【００５９】
図８に示すように、ステップＳ４４１からステップＳ４４４は、ステップＳ４３０で取得したプログラム名称の数分繰り返す。ステップＳ４４２は、本番用サーバ１０のリリース前資源用ライブラリ１０４のパス名（図２４に示す、／ｒｅｌｅａｓｅ／の例示参照）および本番稼動資源用ライブラリ１０３のパス名（図２３に示す／ｕａｐ０１／ｂｉｎ／の例示参照）を取得し、プログラム名称９０３と名称が一致するファイルを、リリース前資源用ライブラリ１０４から本番稼動資源用ライブラリ１０３にコピーする。ステップＳ４４３では、リリースグループＩＤ９０１とプログラム名称９０３をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「３」に更新する。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０４の状態になっている。
【００６０】
ステップＳ４４５は、リリース時実行処理定義テーブル１０２から、ステップＳ４２１で取得されたリリースグループＩＤ＝リリースグループＩＤ１００１、かつ、実行タイミング１００２＝「２」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。
【００６１】
ステップＳ４４６からステップＳ４４８は、ステップＳ４４５で取得したレコードの数分繰り返す。ステップＳ４４７は、取得したリリース時実行処理定義テーブル１０２のプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。そして、一連のプログラムリリースの処理を終了する。
【００６２】
（異常終了調査の処理）
図９は、異常終了調査の処理を示すフロー図である。図１３に示すリリース管理テーブル１０１を、適宜参照して説明する。異常終了調査の処理は、メモリ１２に格納される異常終了調査処理部１１４のプログラムをＣＰＵ１３が実行することで実現される。ＣＰＵ１３は、ステップＳ５０１にて、一般的な障害監視システム５５０からの起動命令を検知すると、ステップＳ５０２では、異常終了時の各種ログを取得し、異常終了したプログラム名称を検出する。ステップＳ５０３では、リリース管理テーブル１０１から、異常終了したプログラム名称をキーに、状態９０６＝「３」の条件を満たすレコードを検索し、最も新しい監視期限日９０５を取得する。もし、条件を満たすレコードが存在しなければ「０」を取得する。ステップＳ５０４では、システム日付≦取得した監視期限日９０５か否かをチェックする。条件を満たさない場合は（ステップＳ５０４，Ｎｏ）、処理を終了する。条件を満たす場合（ステップＳ５０４，Ｙｅｓ）、ステップＳ５０５にて、「プログラム戻しを実行するか判定して下さい」のメッセージを作業用クライアント３０のディスプレイ３３に表示し、処理を終了する。
【００６３】
（プログラム戻しの処理）
図１０から図１２は、プログラム戻しの処理を示すフロー図である。図１３に示すリリース管理テーブル１０１および図１９に示すプログラム戻し処理画面表示例を、適宜参照して説明する。プログラム戻しの処理は、メモリ１２に格納されるプログラム戻し処理部１１５のプログラムをＣＰＵ１３が実行する。
【００６４】
図１９は、プログラム戻し処理画面例を示す説明図である。プログラム戻し処理画面１３０１は、プログラム戻し処理の実行時に作業用クライアント３０のディスプレイ３３に表示する画面表示例である。プログラム戻し処理画面１３０１には、リリースグループＩＤ１３０２、リリースグループ名１３０３、リリース日１３０４、監視期限日１３０５、プログラム名称１３０６のフィールド、メッセージ表示エリア１３０７、実行ボタン１３０８、システム日付１３１０のフィールドを有している。
【００６５】
図１０において、ＣＰＵ１３は、ステップＳ６０１では、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２の更新を検知し、ステップＳ６０２では、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２をキーにリリース管理テーブル１０１からリリースグループ名９０２、リリース日９０４、監視期限日９０５、プログラム名称９０３の項目を取得し、それぞれプログラム戻し処理画面１３０１の図１９におけるリリースグループ名１３０３のフィールド、リリース日１３０４のフィールド、監視期限日１３０５、プログラム名称１３０６のフィールドに表示する。
【００６６】
ステップＳ６０３では、プログラム戻し処理画面１３０１の実行ボタン１３０８が押下されたのを検知し、ステップＳ６０４では、プログラム戻し処理画面１３０１からリリースグループＩＤ１３０２を取得する。ステップＳ６０５では、リリース管理テーブル１０１から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２をキーに検索し、全項目を取得する。
【００６７】
ステップＳ６０６からステップＳ６１０は、ステップＳ６０５で取得したレコードの数分繰り返す。ステップＳ６０７は、リリース管理テーブル１０１から取得したレコードの監視期限日９０５＜システム日付を満たすか否かをチェックする。条件を満たさない場合（ステップＳ６０７，Ｎｏ）、すなわち、システム日付が監視期限日以内の場合、ステップＳ６０９以降の処理を続行する。条件を満たす場合（ステップＳ６０７，Ｙｅｓ）、すなわち、システム日付が監視期限日を過ぎている場合には、ステップＳ６０８にて、「監視期間外のためプログラム戻しはできません」のメッセージをプログラム戻し処理画面１３０１のメッセージ表示エリア１３０７に表示し、処理を終了する。
【００６８】
なお、図１９に示す例では、リリースグループＩＤはＢ０００１であり、図１３に示すリリース管理テーブル１０１の監視期限日は２００８年７月２８日であるが、システム日付は２００８年８月５日であり、すでに監視期限日をすぎている。このため、メッセージ表示エリア１３０７には、「監視期間外のためプログラム戻しはできません」が表示されている。
【００６９】
本実施形態によれば、リリースグループ回復処理要求の日が監視期限日を過ぎていないとき、リリースグループの回復処理をし、リリースグループ回復処理要求の日が前記監視期限日を過ぎているとき、リリースグループの回復処理をしない処理をしている。リリースグループ回復処理要求の日は、一般的にはシステム日付を用いるのがよい。なお、管理者が、強制的にプログラム戻しの処理をする必要がある場合には、システム日付に、過去の日付を入力することにより、プログラム戻しの処理も行うことができる。
【００７０】
図１０に戻り、ステップＳ６０９では、リリースグループＩＤ９０１とリリースグループ名９０２をキーにリリース管理テーブル９０１を検索し、ヒットしたレコードの状態９０６を「８」に更新する。この時点でのリリース管理テーブル１０１は、図１６に示すテーブル８０５の状態になっている。
【００７１】
図１１に示すように、ステップＳ６２１では、リリース時実行処理定義テーブル１０２から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２＝リリースグループＩＤ１００１、かつ、実行タイミング１００２＝「３」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。
【００７２】
ステップＳ６２２からステップＳ６２４は、ステップＳ６２１で取得したレコードの数分繰り返す。ステップＳ６２３は、取得したリリース時実行処理定義テーブル１０２のプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。
【００７３】
ステップＳ６２５では、リリース管理テーブル１０１から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２をキーにレコードを検索し、全項目を取得する。ステップＳ６２６からステップＳ６２９は、取得したレコードの数分繰り返す。
【００７４】
ステップＳ６２７では、本番用サーバ１０の資源退避用ライブラリ１０５のパス名（図２５に示す、／ｂａｃｋｕｐ／の例示参照）および本番稼動資源用ライブラリ１０３のパス名（図２３に示す、／ｕａｐ０１／ｂｉｎ／の例示参照）を取得し、ステップＳ６２５で取得したリリース管理テーブル１０１のレコードのプログラム名称９０３と名称が一致するファイルを、資源退避用ライブラリ１０５から本番稼動資源用ライブラリ１０３へコピーする。ステップＳ６２８では、リリースグループＩＤ９０１とプログラム名称９０３をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「９」に更新する。この時点でのリリース管理テーブル１０１は、図１６に示すテーブル８０６の状態になっている。
【００７５】
図１２に示すように、ステップＳ６４１では、リリース時実行処理定義テーブル１０２から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２＝リリースグループＩＤ１００１、かつ、実行タイミング１００２＝「４」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。ステップＳ６４２からステップＳ６４４は、ステップＳ６４１で取得したレコードの数分繰り返す。ステップＳ６４３は、リリース時実行処理定義テーブル１０２の取得したレコードのプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。そして、一連のプログラム戻しの処理を終了する。
【００７６】
図２０は、リリース管理テーブルの状態の内容を示す説明図である。図２０には、リリース管理テーブル１０１の状態９０６の内容が、各処理（リリースグループ設定の処理、リリース時実行処理登録の処理、プログラムリリースの処理、プログラム戻しの処理）において設定値を示す図である。図２０の列１４０１は状態９０６の設定値を示し、列１４０２はどの処理からどの処理までの間にその設定値が設定されるかを示している。
【００７７】
設定値「０」は、リリースグループ設定のステップＳ２２２から同処理のステップＳ２２７まで、設定値「１」は、リリースグループ設定のステップＳ２２７からプログラムリリース処理のステップＳ４０４まで、設定値「２」は、プログラムリリース処理のステップＳ４０４から同処理のステップＳ４４３まで、設定値「３」は、プログラムリリース処理のステップＳ４４３からプログラム戻し処理のステップＳ６０９までとなる。ただし、プログラム戻しを行わない場合は、設定値「３」のままである。設定値「８」はプログラム戻し処理のステップＳ６０９から同処理のステップＳ６２８まで、設定値「９」は、プログラム戻し処理のステップＳ６２８以降となる。
【００７８】
本実施形態によれば、従来の問題、すなわち、手動でプログラムの戻しを行った場合には、戻し手順の誤りなどの人為的なミスが発生して更に障害が深刻化する問題もある。また、人手で作業するには確認をとりながらの作業となるため時間もかかる問題がある。これらの問題を軽減することができる。また、リリースグループの登録処理、リリースグループの戻しなどの処理をシステム化するため、障害が発生した際の回復までの精度と時間の両面で効果がある。
【図面の簡単な説明】
【００７９】
【図１】本発明の実施形態に係わるプログラムリリース処理およびプログラム戻し処理を示す説明図である。
【図２】本発明の実施形態に係わるリリースプログラム管理システムを示す構成図である。
【図３】リリースグループ設定の処理を示すフロー図である。
【図４】リリースグループ設定の処理を示すフロー図である。
【図５】リリース時実行処理登録の処理を示すフロー図である。
【図６】プログラムリリースの処理を示すフロー図である。
【図７】プログラムリリースの処理を示すフロー図である。
【図８】プログラムリリースの処理を示すフロー図である。
【図９】異常終了調査の処理を示すフロー図である。
【図１０】プログラム戻しの処理を示すフロー図である。
【図１１】プログラム戻しの処理を示すフロー図である。
【図１２】プログラム戻しの処理を示すフロー図である。
【図１３】リリース管理テーブルの一例を示す説明図である。
【図１４】リリース時実行処理定義テーブルの一例を示す説明図である。
【図１５】リリース管理テーブルのデータ例を示した説明図である。
【図１６】リリース管理テーブルのデータ例を示した説明図である。
【図１７】リリースグループ設定画面例を示す説明図である。
【図１８】リリース時実行処理登録画面表示例を示す説明図である。
【図１９】プログラム戻し処理画面例を示す説明図である。
【図２０】リリース管理テーブルの状態の内容を示す説明図である。
【図２１】ＳＩ管理用ライブラリの構成例を示す説明図である。
【図２２】リリース時実行処理管理ライブラリの構成例を示す説明図である。
【図２３】本番稼動資源用ライブラリの構成例を示す説明図である。
【図２４】リリース前資源用ライブラリの構成例を示す説明図である。
【図２５】資源退避用ライブラリの構成例を示す説明図である。
【図２６】リリース時実行処理用ライブラリの構成例を示す説明図である。
【図２７】比較例を示す説明図である。
【符号の説明】
【００８０】
１０ 本番用サーバ（管理サーバ）
１１ 記憶装置（記憶部）
１２，２３，３２ メモリ
１３ ＣＰＵ（処理部）
１４，２４，３６ 通信部
２０ ＳＩ管理用サーバ
２１ 記憶装置
２２，３１ ＣＰＵ
３０ 作業用クライアント（クライアント）
３３ ディスプレイ
４０ ＬＡＮ
１０１ リリース管理テーブル（リリース管理情報）
１０２ リリース時実行処理定義テーブル
１０３ 本番稼動資源用ライブラリ
１０４ リリース前資源用ライブラリ
１０５ 資源退避用ライブラリ
１０６ リリース時実行処理用ライブラリ
１１１ リリースグループ設定部
１１２ リリース時実行処理登録部
１１３ プログラムリリース処理部
１１４ 異常終了調査処理部
１１５ プログラム戻し処理部
１２１ ＳＩ管理用ライブラリ
１２２ リリース時実行処理管理用ライブラリ
１１０１ リリースグループ設定画面
１２０１ リリース時実行処理登録画面
１３０１ プログラム戻し処理画面
【技術分野】
【０００１】
本発明は、システム開発・運用・保守において、本番環境へリリースしたリリースプログラムの管理方法およびリリースプログラム管理システムに関する。
【背景技術】
【０００２】
従来技術において、プログラムを本番環境へリリースする仕組みについて、様々な検討がなされてきた。開発者から修正オブジェクトのリリース依頼があると、システム管理装置は、オブジェクトファイルが修正されているか否かを判定し、修正されていると判定した場合には、リリース対象オブジェクトファイルを、本番用オブジェクトファイルへリリースする（例えば、特許文献１参照）。なお、オブジェクトファイルとは、コンパイラがプログラムのソースコードをもとに生成したモジュールのことである。
【０００３】
また、一方で、プログラムのバージョンを戻す仕組みについても検討がなされてきた。リリース後にクライアントのプログラムの戻しが必要な事態が発生した場合には、サーバからクライアントへ戻すよう命令を発行し、クライアントではリリース前のバックアップを使用して元に戻すという方法がある（例えば、特許文献２参照）。
【特許文献１】特開平１１−２９６３５０号公報
【特許文献２】特開２００１−３５０６３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
前記した特許文献２に開示された技術によれば、クライアントは、機能毎に独立したプログラムの場合にはサーバからの指示によって戻すことができる。しかしながら、サーバから配布されるプログラムは、多数の機能が複雑に入り組んだプログラムが多く、サーバからの差し戻しの指示が問題となる。
【０００５】
システム管理者が、一旦プログラムをリリースした後でプログラムの戻しをする際に、戻す対象のプログラムを手動で選別したり、プログラムを戻す作業を手動で実行したりしてしまうと、手動のために人為的なミスが発生する可能性があり、更に障害が拡大する恐れがある。
【０００６】
プログラムをリリースする仕組みにおいては、整合性をとってリリースしたり安全にリリースしたりするための仕組みは検討されてきたが、万一リリースしたプログラムに不備があった場合に、それを整合性をとって戻す仕組みが十分に検討された例は無かった。
【０００７】
本発明は、前記の課題を解決するための発明であって、一旦リリースしたプログラムに不備があった場合に、プログラムの回復処理をするか否かを判定し管理することができるリリースプログラム管理方法およびリリースプログラム管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記目的を達成するために、記憶部（例えば、記憶装置１１）、処理部（例えば、ＣＰＵ１３）を有する管理サーバ（例えば、本番用サーバ１０）を備える情報処理システム（リリースプログラム管理システム）において、リリースするプログラムの管理をするリリースプログラム管理方法は、プログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報（例えば、リリースグループＩＤ）、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理情報（例えば、リリース管理テーブル１０１）が記憶部に記憶されており、
処理部は、クライアントから前記リリースグループに障害があった際に、以前のリリースグループに回復する処理要求であるリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、リリースグループ識別情報をもとにリリース管理情報を検索し、リリースグループ識別情報に関連付けられた監視期限日を取得し、リリースグループ回復処理要求の日が監視期限日を過ぎていないとき、リリースグループの回復処理（例えば、プログラム戻しの処理）をし、リリースグループ回復処理要求の日が監視期限日を過ぎているとき、リリースグループの回復処理をしないことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、一旦リリースしたプログラムに不備（障害）があった場合に、プログラムの回復処理をするか否かを判定し管理することができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施形態について、図面を参照して説明する。
図１は、本発明の実施形態に係わるプログラムリリース処理およびプログラム戻し処理を示す説明図である。プログラムリリース処理（図６から図８参照）およびプログラム戻し処理（図１０から図１２参照）の詳細については後述するものとし、図１においては概要のみ説明する。
【００１１】
本実施形態によれば、一旦プログラムをリリースした後にプログラム戻しの処理をする際に、関連性のある複数のプログラムをまとめて元の状態に戻すことのできるよう、リリースグループという概念を採用している。リリースグループとは、ある機能に対応するためにリリースされるプログラム群であり、プログラムをリリースする際には、リリースする機能毎に１つのリリースグループＩＤ（リリースグループ識別情報）を定義し、その機能のためにバージョンアップされる全てのプログラムはそのリリースグループに属するように設定する。リリース後にその機能に関連するプログラムの戻しをする際には、そのリリースグループに属する全てのプログラムを、予め退避していたリリース前のプログラムに戻すことができる。以下、具体的に説明する。
【００１２】
処理部（図２参照、ＣＰＵ１３）は、リリース日になりリリース処理要求を受理すると、プログラムリリース処理を開始する。ステップＳ７０１にて、リリース日になりリリース処理要求を受理すると、プログラムの処理要求をリリース管理テーブル１０１（リリース管理情報）からリリース対象となるプログラム名称、リリースグループＩＤ（リリースグループ識別情報）を取得する。プログラムをリリースする際には、リリースする機能毎に１つのリリースグループＩＤを定義し、その機能のためにバージョンアップされる全てのプログラムは、そのリリースグループに属するように設定されている。
【００１３】
ステップＳ７０２にて、バックアップとして、現在リリースされているリリース対象のリリースグループに属するプログラムを、本番稼動資源用ライブラリ１０３から、資源退避用ライブラリ１０５にコピーしてバックアップを取得する。ステップＳ７０３にて、今回リリースするリリース対象のリリースグループに属するプログラムを、リリース前資源用ライブラリ１０４から、本番稼動資源用ライブラリ１０３へコピーし、コピーされた本番稼動資源用ライブラリ１０３のプログラムをリリースする。
【００１４】
処理部は、プログラム戻し要求を受理すると、プログラム戻し処理を開始する。ステップＳ７０４にて、プログラム戻し処理画面１３０１（図１９参照）から、戻す対象のリリースグループＩＤを取得する。ステップＳ７０５にて、取得したリリースグループＩＤに属するプログラムを、資源退避用ライブラリ１０５から本番稼動資源用ライブラリ１０３に戻し、リリースすることにより、プログラムのバックアップの戻しを行う。
【００１５】
具体的には、リリースグループを、Ｂ０００１、Ｂ０００２、Ｂ０００３として説明する。プログラムリリース処理において、今回のリリースされるグループがＢ０００３であると、今回のリリース前においては、リリース前資源用ライブラリ１０４には、Ｂ０００３が格納されており、本番稼動資源用ライブラリ１０３には、Ｂ０００２が格納されており、資源退避用ライブラリ１０５には、Ｂ０００１が格納されている。
【００１６】
プログラムリリース処理により、本番稼動資源用ライブラリ１０３から、資源退避用ライブラリ１０５にコピーしてバックアップを取得し、Ｂ０００２が格納される。また、リリース前資源用ライブラリ１０４から、本番稼動資源用ライブラリ１０３へコピーし、本番稼動資源用ライブラリ１０３には、Ｂ０００３が格納される。そして、Ｂ０００３がリリースされる。一方、プログラム戻し処理においては、資源退避用ライブラリ１０５から本番稼動資源用ライブラリ１０３に戻し、Ｂ０００２がリリースされる。
【００１７】
図２は、本発明の実施形態に係わるリリースプログラム管理システムを示す構成図である。リリースプログラム管理システム（情報処理システム）は、本番用サーバ１０（管理サーバ）、ＳＩ管理用サーバ２０、作業用クライアント３０（クライアント）を有し、本番用サーバ１０、ＳＩ管理用サーバ２０、作業用クライアント３０は、ＬＡＮ（Local Area Network）４０などのネットワークで相互に接続されている。なお、ＳＩはSystem Integratorの略である。
【００１８】
本番用サーバ１０は、記憶装置１１、メモリ１２、ＣＰＵ１３（処理部）、通信部１４を有している。記憶装置１１は、本番用サーバ１０が処理を実行するための各種データを保存する。メモリ１２は、本番用サーバ１０が処理を実行する各種プログラムおよび一時的なデータを保持する。ＣＰＵ１３は、メモリ１２に格納される各種プログラムを実行する。通信部１４は、ＬＡＮ４０を介して、他の装置と各種データやコマンドを交換する。
【００１９】
メモリ１２には、プログラムをリリースする際にリリースする機能毎に１つのリリースグループＩＤとして設定するリリースグループ設定部１１１、リリースする際に前処理・後処理などの実行処理を登録するリリース時実行処理登録部１１２、所定日時になるとプログラムリリースの処理をするプログラムリリース処理部１１３、障害監視システムからの起動命令により異常終了調査の処理をする異常終了調査処理部１１４、リリースプログラムの戻し処理をするプログラム戻し処理部１１５が格納される。
【００２０】
記憶装置１１には、リリースプログラムの管理テーブルであるリリース管理テーブル１０１（図１３参照）、リリース時の実行処理の定義テーブルであるリリース時実行処理定義テーブル１０２（図１４参照）、本番稼動のリリースプログラムを格納する本番稼動資源用ライブラリ１０３（図２３参照）、次回リリースするリリース前のリリースプログラムを記憶するリリース前資源用ライブラリ１０４（図２４参照）、本番稼動資源用ライブラリのバックアップを記憶する資源退避用ライブラリ１０５（図２５参照）、リリース時の実行処理用プログラムを記憶するリリース時実行処理用ライブラリ１０６（図２６参照）が格納される。
【００２１】
ＳＩ管理用サーバ２０は、記憶装置２１、ＣＰＵ２２、メモリ２３、通信部２４を有している。記憶装置２１には、リリースプログラムの管理ライブラリであるＳＩ管理用ライブラリ１２１（図２１参照）、リリース時の実行処理シェル、プログラムなどの管理ライブラリであるリリース時実行処理管理用ライブラリ１２２（図２２参照）が格納されており、ＣＰＵ２２で実行されている処理から必要に応じて読み込まれる。通信部２４は、ＬＡＮ４０を介して、他の装置と各種データやコマンドを交換する。
【００２２】
作業用クライアント３０は、ＣＰＵ３１、メモリ３２、通信部３６を有し、ディスプレイ３３、キーボード３４、マウス３５を接続している。作業者は、ディスプレイ３３に表示される画面を見て、キーボード３４およびマウス３５を使用して操作を行う。ディスプレイ３３には、リリースグループ設定画面１１０１（図１７参照）、リリース時実行処理登録画面１２０１（図１８参照）、プログラム戻し処理画面１３０１（図１９参照）が表示され、状況に応じて、本番用サーバ１０で実行されるリリースグループ設定部１１１、リリース時実行処理登録部１１２、異常終了調査処理部１１４、プログラム戻し処理部１１５と、通信部１４，３６およびＬＡＮ４０を介して通信を行う。
【００２３】
図１３は、リリース管理テーブルの一例を示す説明図である。リリース管理テーブル１０１は、リリースグループＩＤ９０１、リリースグループ名９０２、プログラム名称９０３、リリース日９０４、監視期限日９０５、後述する図２０で示される状態９０６を有している。例えば、リリースグループＩＤ９０１がＢ０００１の場合は、マスタの項目を追加対応するリリースグループ名であり、プログラムとしては、ＰＡ１１．ｅｘｅ、ＰＡ１２．ｅｘｅ、ＳＡ１１．ｃｓｈなどがある。
【００２４】
監視期限日９０５は、本実施形態の特徴とする項目であり、繰り返しリリースされるプログラムの日程管理をするための項目である。一度、リリースされたプログラムを再度リリースする際に、同じプログラム名称があるとき、最も新しい監視期限日を取得し、リリースグループ設定部１１１が受理したリリース日が最も新しい監視期限日を過ぎているとき、該当するプログラムをリリースグループに設定登録することができる。具体的には、ＰＡ１１．ｅｘｅのプログラムを次回リリースする場合には、リリースグループ設定部１１１は、リリース管理テーブル１０１を検索し、レコード９１１およびレコード９１２を抽出し、レコード９１２に示される監視期限日が最も新しい日である２００８年８月４日（２００８／０８／０４）を取得する。したがって、次回リリース日は、２００８年８月５日以降であれば設定登録することができる。例えば、ＰＡ１１．ｅｘｅのプログラムの場合、レコード９１１の監視期限日は２００８年７月２８日であるので、レコード９１２において、リリース日は、２００８年７月２９日として登録されていることがわかる。
【００２５】
図１４は、リリース時実行処理定義テーブルの一例を示す説明図である。リリース時実行処理定義テーブル１０２は、リリースグループＩＤ１００１、実行タイミング１００２、実行順１００３、プログラム名称１００４を有している。例えば、レコード１０１１に示すＢ０００１＿１１．ｃｓｈのプログラムの場合、リリースされる前の前処理のプログラムを意味し、レコード１０１２のＢ０００１＿２１．ｃｓｈのプログラムの場合、リリース後の後処理のプログラムを意味する。
【００２６】
次に処理フローについて説明する。
（リリースグループ設定の処理）
図３および図４は、リリースグループ設定の処理を示すフロー図である。図１３に示すリリース管理テーブル１０１および図１７に示すリリースグループ設定画面表示例を、適宜参照して説明する。リリースグループ設定の処理は、メモリ１２に格納されるリリースグループ設定部１１１のプログラムをＣＰＵ１３が実行することで実現される。
【００２７】
図１７は、リリースグループ設定画面例を示す説明図である。図１７（ａ）に示すリリースグループ設定画面１１０１は、リリースグループ設定処理の実行時に作業用クライアント３０のディスプレイ３３に表示する画面表示例である。リリースグループ設定画面１１０１には、リリースグループＩＤ１１０２、リリースグループ名１１０３、リリース日１１０４、監視期限日１１０５、プログラム名称１１０６のフィールド、メッセージ表示エリア１１０７、実行ボタン１１０８、システム日付１１１０のフィールドを有している。なお、図１７（ｂ）の画面については後述する。
【００２８】
図３に戻り、ＣＰＵ１３（処理部）は、ステップＳ２０１において、リリースグループ設定画面１１０１の実行ボタン１１０８が押下されたのを検知すると、ステップＳ２０２において、リリースグループ設定画面１１０１のリリース日１１０４、プログラム名称１１０６のフィールドに入力されたデータを取得し、ステップＳ２０３からステップＳ２０７までの処理を、取得したプログラム名称の数分繰り返す。
【００２９】
ステップＳ２０４において、リリース管理テーブル１０１を、リリースグループ設定画面から取得したプログラム名称１１０６をキーに検索し、リリース管理テーブル１０１から、ヒットしたリリース管理テーブル１０１のレコードの中から最も新しい監視期限日９０５を取得する。もし該当するレコードがリリース管理テーブル１０１に存在しない場合には、「０」を取得する。ステップＳ２０５では、ステップＳ２０４で取得した監視期限日が画面のリリース日１１０４以降であるか否かを条件判定する。条件を満たす場合には（ステップＳ２０５，Ｙｅｓ）、「監視期間中のためリリース登録できません」のメッセージをリリースグループ設定画面１１０１のメッセージ表示エリア１１０７に表示し（ステップＳ２０６）、処理を終了する。条件を満たさない場合には（ステップＳ２０５，Ｎｏ）、処理を続行する。
【００３０】
図１７（ｂ）には、ステップＳ２０６での画面表示例を示している。図１７（ｂ）においては、リリースグループＩＤがＢ０００３を、システム日付１１１０が２００８年８月１日に、その日のうちにリリースグループ設定を試みた場合である。この場合、ステップＳ２０４において、プログラム名称１１０６中のＰＡ１１．ｅｘｅをキーとしてリリース管理テーブル１０１（図１３参照）のレコードの中から最も新しい監視期限日９０５を取得すると、２００８年８月４日である。ステップＳ２０５において、リリース日１１０４の２００８年８月１日は、取得した監視期限日（２００８年８月４日）以前のために、ステップＳ２０６において、メッセージ表示エリア１１０７に「監視期間中のためリリース登録できません（ＰＡ１１．ｅｘｅ）」が表示されている。なお、メッセージ表示エリア１１０７には、どのプログラムが監視期間中であるかも表示されており、作業者は容易に、どのプログラムが適切でないかを知ることができる。
【００３１】
ここで、ステップＳ２０５のチェックを実施している理由を具体的に、図２７を参照して説明する。監視期限日は、リリースされるプログラムの管理と、リリースプログラムを戻すか否かの判断とに利用される。
【００３２】
図２７は、比較例を示す説明図である。比較例では、以下のような現象が想定される。なお、以下のプログラム名称などは例示として示す。また、リリースされるリリースグループは、Ａ０００１およびＡ０００２があるとして説明する。Ａ０００１およびＡ０００２は、複数のプログラムのまとめたリリースグループであり、同じプログラム「ＰＡ０１．ｅｘｅ」を含んでいる。リリースグループのＡ０００１は、リリース日が２００８年９月１日（２００８／０９／０１）であり、リリースグループのＡ０００２は、リリース日が２００８年９月８日（２００８／０９／０８）とする。
【００３３】
仮に、２００８年９月１２日（２００８／０９／１２）に、リリースグループのＡ０００１に含まれる他のプログラム「ＰＡ０２．ｅｘｅ」に不具合があることが判明し、それを元のバージョンに戻してシステムを動かしたいとする。元のバージョンの「ＰＡ０２．ｅｘｅ」が動くためには、リリースグループのＡ０００１のリリース時にリリースした他のプログラムも元のバージョンに戻しておかないとプログラム間の整合性が取れなくなるおそれがあるため、リリースグループのＡ０００１に含まれる全プログラムの戻しを行う必要がある。
【００３４】
しかし、リリースグループのＡ０００１に含まれる全プログラムをＡ０００１のリリース前のプログラムに戻してしまうと、リリースグループのＡ０００２で修正した内容が反映されていない２００８年９月１日より前のバージョンの「ＰＡ０１．ｅｘｅ」が戻されてしまうことになり、そのバージョンのプログラム「ＰＡ０１．ｅｘｅ」はシステム日付が２００８年９月１２日の時点の環境では正常に動作しない可能性がある。
【００３５】
具体的には、リリースグループのＡ０００１のリリース時に、ある業務マスタ１、業務マスタ２の両者にＡという項目を追加し、リリースグループのＡ０００２のリリース時に、ある業務マスタ２、業務マスタ３の両者にＢという項目を追加した場合である。例えば、リリースグループのＡ０００２のリリース後は、業務マスタ２には項目Ａ，Ｂ両方がある状態だが、２００８年９月１日より前の「ＰＡ０１．ｅｘｅ」は、項目Ａ，Ｂのどちらもない時点のプログラムであるため、リリースグループのＡ０００１のプログラム戻し時に業務マスタ１、業務マスタ２からＡという項目を削除したとしても、業務マスタ２にはＢという項目が残ったままのため、マスタの読み込みなどで不具合の発生する可能性がある。
【００３６】
このとき、リリースグループのＡ０００１の全プログラムを戻すだけでなく（対策１参照）、更にリリースグループのＡ０００２の全プログラムも戻す（対策２参照）、という方法も考えられる。しかし、リリースグループのＡ０００２に含まれる他のプログラムが、更に、リリースグループのＡ０００１のリリース日以降にリリースされた他のリリースグループに入っている可能性もあり、その場合はそのリリースグループの全プログラムも元に戻さないとプログラム間の整合性が取れなくなる可能性が出てくる。このように、リリースグループのプログラムを戻すには他のリリースグループの戻しも必要になることがある。これらの影響調査をシステム的に実装すると複雑になる。
【００３７】
本実施形態によれば、ステップＳ２０５の制限を課し、しかも、後述するプログラム戻しの処理をするときには、ステップＳ６０７（図１０参照）の制限を課すことにより、リリースプログラムの管理を容易にすることができる。
【００３８】
図４において、ステップＳ２２１からステップＳ２２３は、リリースグループ設定画面１１０１のプログラム名称１１０６の数分繰り返す。ステップＳ２２２では、リリース管理テーブル１０１にレコードを追加する。追加するレコードには、リリースグループ設定画面１１０１の同名の項目をそれぞれセットする。即ち、リリースグループＩＤ９０１の項目にはリリースグループＩＤ１１０２のフィールドの入力値を、リリースグループ名９０２の項目にはリリースグループ名１１０３のフィールドの入力値、プログラム名称９０３にはプログラム名称１１０６のフィールドの入力値、リリース日９０４にはリリース日１１０４のフィールドの入力値、監視期限日９０５には監視期限日１１０５のフィールドの入力値をそれぞれセットする。また、状態９０６の項目は「０」をセットする。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０１の状態になっている。
【００３９】
ステップＳ２２４からステップＳ２２８については、リリースグループ設定画面１１０１のプログラム名称１１０６の数分繰り返す。ステップＳ２２５では、ＳＩ管理用サーバ２０のＳＩ管理用ライブラリ１２１のパス名（図２１に示す、／ＳＩ＿ＫＡＮＲＩ／ｂｉｎ／ の例示参照）を取得し、リリースグループ設定画面１１０１のプログラム名称１１０６と名称が一致するファイルをＦＴＰでダウンロードする。
【００４０】
ステップＳ２２６では、本番用サーバ１０のリリース前資源用ライブラリ１０４のパス名（図２４に示す、／ｒｅｌｅａｓｅ／の例示参照）を取得し、ステップＳ２２５でダウンロードしたファイルを、本番用サーバ１０のリリース前資源用ライブラリ１０４へコピーする。ステップＳ２２７では、リリースグループ設定画面１１０１のリリースグループＩＤ１１０２、プログラム名称１１０６をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「１」に更新する。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０２の状態になっている。そして、一連のリリースグループ設定の処理を終了する。
【００４１】
（リリース時実行処理登録の処理）
図５は、リリース時実行処理登録の処理を示すフロー図である。図１３に示すリリース管理テーブル１０１、図１４に示すリリース時実行処理定義テーブル１０２および図１８に示すリリース時実行処理登録画面表示例を、適宜参照して説明する。リリース時実行処理登録の処理は、メモリ１２に格納されるリリース時実行処理登録部１１２のプログラムをＣＰＵ１３が実行することで実現される。
【００４２】
図１８は、リリース時実行処理登録画面表示例を示す説明図である。リリース時実行処理登録画面１２０１は、リリース時実行処理登録の実行時に作業用クライアント３０のディスプレイ３３に表示する画面表示例である。リリース時実行処理登録画面１２０１には、リリースグループＩＤ１２０２、リリースグループ名１２０３、リリース日１２０４、監視期限日１２０５、実行タイミング１２０６、実行順１２０７、プログラム名称１２０８のフィールド、実行ボタン１２０９、システム日付１２１０のフィールドを有している。
【００４３】
図５に戻り、ＣＰＵ１３は、ステップＳ３０１では、リリース時実行処理登録画面１２０１のリリースグループＩＤ１２０２が更新されたのを検知し、ステップＳ３０２では、リリース時実行処理登録画面１２０１のリリースグループＩＤ１２０２をキーにリリース管理テーブル１０１からリリースグループ名９０２、リリース日９０４、監視期限日９０５の項目を取得し、それぞれリリース時実行処理登録画面１２０１の図１８におけるリリースグループ名１２０３のフィールド、リリース日１２０４のフィールド、監視期限日１２０５のフィールドに表示する。
【００４４】
ステップＳ３０３では、リリース時実行処理登録画面１２０１の実行ボタン１２０９が押下されたのを検知し、ステップＳ３０４では、リリース時実行処理登録画面１２０１からプログラム名称１２０８を取得し、ステップＳ３０５からステップＳ３０９をプログラム名称の数分繰り返す。
【００４５】
ステップＳ３０６では、リリース時実行処理定義テーブル１０２にレコードを追加する。追加するレコードの各項目の値は、リリース時実行処理登録画面１２０１の同名の項目をそれぞれセットする。即ち、リリースグループＩＤ１００１にはリリースグループＩＤ１２０２のフィールドの入力値を、実行タイミング１００２には実行タイミング１２０６のフィールドの入力値を、実行順１００３には実行順１２０７のフィールドの入力値を、プログラム名称１００４にはプログラム名称１２０８のフィールドの入力値をセットする。
【００４６】
ステップＳ３０７では、ＳＩ管理用サーバ２０のリリース時実行処理管理用ライブラリ１２２のパス名（図２２に示す、／ＳＩ＿ＫＡＮＲＩ／ｒｅｌｅａｓｅ＿ｅｘｅｃ／の例示参照）を取得し、リリース時実行処理登録画面１２０１のプログラム名称１２０８と名称が一致するファイルをＦＴＰでダウンロードする。
【００４７】
ステップＳ３０８では、本番用サーバ１０のリリース時実行処理用ライブラリ１０６のパス名（図２６に示す、／ｒｅｌｅａｓｅ＿ｅｘｅｃ／の例示参照）を取得し、ステップＳ３０７でダウンロードしたファイルを、本番用サーバ１０のリリース時実行処理用ライブラリ１０６へコピーする。そして、一連のリリース時実行処理登録の処理を終了する。
【００４８】
（プログラムリリースの処理）
図６から図８は、プログラムリリースの処理を示すフロー図である。図１３に示すリリース管理テーブル１０１を、適宜参照して説明する。プログラムリリースの処理は、メモリ１２に格納されるリリースグループ設定部１１１のプログラムをＣＰＵ１３が実行することで実現される。
【００４９】
図６に示すように、ＣＰＵ１３は、ステップＳ４０１にて、リリース管理テーブル１０１から、リリース日９０４＝システム日付、かつ、状態９０６＝「１」の条件を満たすレコードを検索し、全項目を取得する。ステップＳ４０２からステップＳ４０５は、取得したレコードの数分繰り返す。
【００５０】
ステップＳ４０３では、取得したレコードについて、リリース管理テーブル１０１のプログラム名称９０３と名称が一致するファイルを、本番稼動資源用ライブラリ１０３から資源退避用ライブラリ１０５へコピーする。ステップＳ４０４では、リリースグループＩＤ９０１とプログラム名称９０３をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「２」に更新する。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０３の状態になっている。
【００５１】
図７に示すように、ＣＰＵ１３は、ステップＳ４２１では、リリース管理テーブル１０１から、状態９０６＝「２」の条件を満たすレコードのリリースグループＩＤ９０１を取得する。ステップＳ４２２からステップＳ４２４は、取得されたリリースグループＩＤの数分繰り返す。ステップＳ４２３では、リリース管理テーブル１０１に、取得されたリリースグループＩＤ＝リリース管理テーブルのリリースグループＩＤ９０１、かつ、状態９０６が２以外のレコードが存在するか否かを判定する。存在した場合は（ステップＳ４２３，Ｙｅｓ）、ディスプレイ３３にプログラムリリースのＥｒｒｏｒ表示をし（ステップＳ４５０）、処理を終了する。存在しなかった場合は（ステップＳ４２３，Ｎｏ）、処理を続行する。
【００５２】
ここで、ステップＳ４２３での判定条件について具体的に説明する。リリース対象となるプログラムは、リリース管理テーブル１０１の状態９０６の項目が「２」となっているレコードのプログラム名称をもつプログラムであり、リリース処理はリリースグループ毎に実行される。もし、同じリリースグループＩＤを持つレコードに、状態が「１」のレコードが存在している場合には、何らかの異常な事態が発生している可能性があり、処理を直ちに停止する。
【００５３】
前記のような事態が発生するケースとして、以下の場合がある。プログラムリリース処理は重複して実行されることがないことを想定しているが、仮に重複して実行されたとして、一方でステップＳ４０３のプログラム退避を行っている最中に、他方でステップＳ４２３の条件判定が行われた場合である。
【００５４】
もし、ステップＳ４２３の条件判定をせずに以降の処理が流れ、図６に示すステップＳ４４２が実行されると、ステップＳ４０３のプログラム退避が完了していないリリースグループに対して、ステップＳ４４２でプログラムリリースをしてしまう可能性がある。このような事態を防止するため、ステップＳ４２３の条件判定を行っている。
【００５５】
ステップＳ４２５からステップＳ４４９は、ステップＳ４２１で取得されたリリースグループＩＤの数分繰り返す。
【００５６】
ステップＳ４２６は、リリース時実行処理定義テーブル１０２から、ステップＳ４２１で取得したリリースグループＩＤ＝リリース時実行処理定義テーブル１０２のリリースグループＩＤ１００１、かつ、実行タイミング１００２＝「１」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。
【００５７】
ステップＳ４２７からステップＳ４２９は、ステップＳ４２６で取得したレコードの数分繰り返す。ステップＳ４２８は、取得したリリース時実行処理定義テーブル１０２のプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。
【００５８】
ステップＳ４３０では、ステップＳ４２５で取得したリリースグループＩＤをキーにリリース管理テーブル１０１を検索し、プログラム名称９０３を取得する。
【００５９】
図８に示すように、ステップＳ４４１からステップＳ４４４は、ステップＳ４３０で取得したプログラム名称の数分繰り返す。ステップＳ４４２は、本番用サーバ１０のリリース前資源用ライブラリ１０４のパス名（図２４に示す、／ｒｅｌｅａｓｅ／の例示参照）および本番稼動資源用ライブラリ１０３のパス名（図２３に示す／ｕａｐ０１／ｂｉｎ／の例示参照）を取得し、プログラム名称９０３と名称が一致するファイルを、リリース前資源用ライブラリ１０４から本番稼動資源用ライブラリ１０３にコピーする。ステップＳ４４３では、リリースグループＩＤ９０１とプログラム名称９０３をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「３」に更新する。この時点でのリリース管理テーブル１０１は、図１５に示すテーブル８０４の状態になっている。
【００６０】
ステップＳ４４５は、リリース時実行処理定義テーブル１０２から、ステップＳ４２１で取得されたリリースグループＩＤ＝リリースグループＩＤ１００１、かつ、実行タイミング１００２＝「２」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。
【００６１】
ステップＳ４４６からステップＳ４４８は、ステップＳ４４５で取得したレコードの数分繰り返す。ステップＳ４４７は、取得したリリース時実行処理定義テーブル１０２のプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。そして、一連のプログラムリリースの処理を終了する。
【００６２】
（異常終了調査の処理）
図９は、異常終了調査の処理を示すフロー図である。図１３に示すリリース管理テーブル１０１を、適宜参照して説明する。異常終了調査の処理は、メモリ１２に格納される異常終了調査処理部１１４のプログラムをＣＰＵ１３が実行することで実現される。ＣＰＵ１３は、ステップＳ５０１にて、一般的な障害監視システム５５０からの起動命令を検知すると、ステップＳ５０２では、異常終了時の各種ログを取得し、異常終了したプログラム名称を検出する。ステップＳ５０３では、リリース管理テーブル１０１から、異常終了したプログラム名称をキーに、状態９０６＝「３」の条件を満たすレコードを検索し、最も新しい監視期限日９０５を取得する。もし、条件を満たすレコードが存在しなければ「０」を取得する。ステップＳ５０４では、システム日付≦取得した監視期限日９０５か否かをチェックする。条件を満たさない場合は（ステップＳ５０４，Ｎｏ）、処理を終了する。条件を満たす場合（ステップＳ５０４，Ｙｅｓ）、ステップＳ５０５にて、「プログラム戻しを実行するか判定して下さい」のメッセージを作業用クライアント３０のディスプレイ３３に表示し、処理を終了する。
【００６３】
（プログラム戻しの処理）
図１０から図１２は、プログラム戻しの処理を示すフロー図である。図１３に示すリリース管理テーブル１０１および図１９に示すプログラム戻し処理画面表示例を、適宜参照して説明する。プログラム戻しの処理は、メモリ１２に格納されるプログラム戻し処理部１１５のプログラムをＣＰＵ１３が実行する。
【００６４】
図１９は、プログラム戻し処理画面例を示す説明図である。プログラム戻し処理画面１３０１は、プログラム戻し処理の実行時に作業用クライアント３０のディスプレイ３３に表示する画面表示例である。プログラム戻し処理画面１３０１には、リリースグループＩＤ１３０２、リリースグループ名１３０３、リリース日１３０４、監視期限日１３０５、プログラム名称１３０６のフィールド、メッセージ表示エリア１３０７、実行ボタン１３０８、システム日付１３１０のフィールドを有している。
【００６５】
図１０において、ＣＰＵ１３は、ステップＳ６０１では、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２の更新を検知し、ステップＳ６０２では、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２をキーにリリース管理テーブル１０１からリリースグループ名９０２、リリース日９０４、監視期限日９０５、プログラム名称９０３の項目を取得し、それぞれプログラム戻し処理画面１３０１の図１９におけるリリースグループ名１３０３のフィールド、リリース日１３０４のフィールド、監視期限日１３０５、プログラム名称１３０６のフィールドに表示する。
【００６６】
ステップＳ６０３では、プログラム戻し処理画面１３０１の実行ボタン１３０８が押下されたのを検知し、ステップＳ６０４では、プログラム戻し処理画面１３０１からリリースグループＩＤ１３０２を取得する。ステップＳ６０５では、リリース管理テーブル１０１から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２をキーに検索し、全項目を取得する。
【００６７】
ステップＳ６０６からステップＳ６１０は、ステップＳ６０５で取得したレコードの数分繰り返す。ステップＳ６０７は、リリース管理テーブル１０１から取得したレコードの監視期限日９０５＜システム日付を満たすか否かをチェックする。条件を満たさない場合（ステップＳ６０７，Ｎｏ）、すなわち、システム日付が監視期限日以内の場合、ステップＳ６０９以降の処理を続行する。条件を満たす場合（ステップＳ６０７，Ｙｅｓ）、すなわち、システム日付が監視期限日を過ぎている場合には、ステップＳ６０８にて、「監視期間外のためプログラム戻しはできません」のメッセージをプログラム戻し処理画面１３０１のメッセージ表示エリア１３０７に表示し、処理を終了する。
【００６８】
なお、図１９に示す例では、リリースグループＩＤはＢ０００１であり、図１３に示すリリース管理テーブル１０１の監視期限日は２００８年７月２８日であるが、システム日付は２００８年８月５日であり、すでに監視期限日をすぎている。このため、メッセージ表示エリア１３０７には、「監視期間外のためプログラム戻しはできません」が表示されている。
【００６９】
本実施形態によれば、リリースグループ回復処理要求の日が監視期限日を過ぎていないとき、リリースグループの回復処理をし、リリースグループ回復処理要求の日が前記監視期限日を過ぎているとき、リリースグループの回復処理をしない処理をしている。リリースグループ回復処理要求の日は、一般的にはシステム日付を用いるのがよい。なお、管理者が、強制的にプログラム戻しの処理をする必要がある場合には、システム日付に、過去の日付を入力することにより、プログラム戻しの処理も行うことができる。
【００７０】
図１０に戻り、ステップＳ６０９では、リリースグループＩＤ９０１とリリースグループ名９０２をキーにリリース管理テーブル９０１を検索し、ヒットしたレコードの状態９０６を「８」に更新する。この時点でのリリース管理テーブル１０１は、図１６に示すテーブル８０５の状態になっている。
【００７１】
図１１に示すように、ステップＳ６２１では、リリース時実行処理定義テーブル１０２から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２＝リリースグループＩＤ１００１、かつ、実行タイミング１００２＝「３」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。
【００７２】
ステップＳ６２２からステップＳ６２４は、ステップＳ６２１で取得したレコードの数分繰り返す。ステップＳ６２３は、取得したリリース時実行処理定義テーブル１０２のプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。
【００７３】
ステップＳ６２５では、リリース管理テーブル１０１から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２をキーにレコードを検索し、全項目を取得する。ステップＳ６２６からステップＳ６２９は、取得したレコードの数分繰り返す。
【００７４】
ステップＳ６２７では、本番用サーバ１０の資源退避用ライブラリ１０５のパス名（図２５に示す、／ｂａｃｋｕｐ／の例示参照）および本番稼動資源用ライブラリ１０３のパス名（図２３に示す、／ｕａｐ０１／ｂｉｎ／の例示参照）を取得し、ステップＳ６２５で取得したリリース管理テーブル１０１のレコードのプログラム名称９０３と名称が一致するファイルを、資源退避用ライブラリ１０５から本番稼動資源用ライブラリ１０３へコピーする。ステップＳ６２８では、リリースグループＩＤ９０１とプログラム名称９０３をキーにリリース管理テーブル１０１を検索し、ヒットしたレコードの状態９０６の項目を「９」に更新する。この時点でのリリース管理テーブル１０１は、図１６に示すテーブル８０６の状態になっている。
【００７５】
図１２に示すように、ステップＳ６４１では、リリース時実行処理定義テーブル１０２から、プログラム戻し処理画面１３０１のリリースグループＩＤ１３０２＝リリースグループＩＤ１００１、かつ、実行タイミング１００２＝「４」の条件を満たすレコードを、実行順１００３で昇順にソートして検索し、全項目を取得する。ステップＳ６４２からステップＳ６４４は、ステップＳ６４１で取得したレコードの数分繰り返す。ステップＳ６４３は、リリース時実行処理定義テーブル１０２の取得したレコードのプログラム名称１００４と名称が一致するリリース時実行処理用ライブラリ１０６のプログラムを、メモリ１２に読み込んで実行する。そして、一連のプログラム戻しの処理を終了する。
【００７６】
図２０は、リリース管理テーブルの状態の内容を示す説明図である。図２０には、リリース管理テーブル１０１の状態９０６の内容が、各処理（リリースグループ設定の処理、リリース時実行処理登録の処理、プログラムリリースの処理、プログラム戻しの処理）において設定値を示す図である。図２０の列１４０１は状態９０６の設定値を示し、列１４０２はどの処理からどの処理までの間にその設定値が設定されるかを示している。
【００７７】
設定値「０」は、リリースグループ設定のステップＳ２２２から同処理のステップＳ２２７まで、設定値「１」は、リリースグループ設定のステップＳ２２７からプログラムリリース処理のステップＳ４０４まで、設定値「２」は、プログラムリリース処理のステップＳ４０４から同処理のステップＳ４４３まで、設定値「３」は、プログラムリリース処理のステップＳ４４３からプログラム戻し処理のステップＳ６０９までとなる。ただし、プログラム戻しを行わない場合は、設定値「３」のままである。設定値「８」はプログラム戻し処理のステップＳ６０９から同処理のステップＳ６２８まで、設定値「９」は、プログラム戻し処理のステップＳ６２８以降となる。
【００７８】
本実施形態によれば、従来の問題、すなわち、手動でプログラムの戻しを行った場合には、戻し手順の誤りなどの人為的なミスが発生して更に障害が深刻化する問題もある。また、人手で作業するには確認をとりながらの作業となるため時間もかかる問題がある。これらの問題を軽減することができる。また、リリースグループの登録処理、リリースグループの戻しなどの処理をシステム化するため、障害が発生した際の回復までの精度と時間の両面で効果がある。
【図面の簡単な説明】
【００７９】
【図１】本発明の実施形態に係わるプログラムリリース処理およびプログラム戻し処理を示す説明図である。
【図２】本発明の実施形態に係わるリリースプログラム管理システムを示す構成図である。
【図３】リリースグループ設定の処理を示すフロー図である。
【図４】リリースグループ設定の処理を示すフロー図である。
【図５】リリース時実行処理登録の処理を示すフロー図である。
【図６】プログラムリリースの処理を示すフロー図である。
【図７】プログラムリリースの処理を示すフロー図である。
【図８】プログラムリリースの処理を示すフロー図である。
【図９】異常終了調査の処理を示すフロー図である。
【図１０】プログラム戻しの処理を示すフロー図である。
【図１１】プログラム戻しの処理を示すフロー図である。
【図１２】プログラム戻しの処理を示すフロー図である。
【図１３】リリース管理テーブルの一例を示す説明図である。
【図１４】リリース時実行処理定義テーブルの一例を示す説明図である。
【図１５】リリース管理テーブルのデータ例を示した説明図である。
【図１６】リリース管理テーブルのデータ例を示した説明図である。
【図１７】リリースグループ設定画面例を示す説明図である。
【図１８】リリース時実行処理登録画面表示例を示す説明図である。
【図１９】プログラム戻し処理画面例を示す説明図である。
【図２０】リリース管理テーブルの状態の内容を示す説明図である。
【図２１】ＳＩ管理用ライブラリの構成例を示す説明図である。
【図２２】リリース時実行処理管理ライブラリの構成例を示す説明図である。
【図２３】本番稼動資源用ライブラリの構成例を示す説明図である。
【図２４】リリース前資源用ライブラリの構成例を示す説明図である。
【図２５】資源退避用ライブラリの構成例を示す説明図である。
【図２６】リリース時実行処理用ライブラリの構成例を示す説明図である。
【図２７】比較例を示す説明図である。
【符号の説明】
【００８０】
１０ 本番用サーバ（管理サーバ）
１１ 記憶装置（記憶部）
１２，２３，３２ メモリ
１３ ＣＰＵ（処理部）
１４，２４，３６ 通信部
２０ ＳＩ管理用サーバ
２１ 記憶装置
２２，３１ ＣＰＵ
３０ 作業用クライアント（クライアント）
３３ ディスプレイ
４０ ＬＡＮ
１０１ リリース管理テーブル（リリース管理情報）
１０２ リリース時実行処理定義テーブル
１０３ 本番稼動資源用ライブラリ
１０４ リリース前資源用ライブラリ
１０５ 資源退避用ライブラリ
１０６ リリース時実行処理用ライブラリ
１１１ リリースグループ設定部
１１２ リリース時実行処理登録部
１１３ プログラムリリース処理部
１１４ 異常終了調査処理部
１１５ プログラム戻し処理部
１２１ ＳＩ管理用ライブラリ
１２２ リリース時実行処理管理用ライブラリ
１１０１ リリースグループ設定画面
１２０１ リリース時実行処理登録画面
１３０１ プログラム戻し処理画面
【特許請求の範囲】
【請求項１】
記憶部、処理部を有する管理サーバを備える情報処理システムにおいて、リリースするプログラムの管理をするリリースプログラム管理方法であって、
前記管理サーバは、
プログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理情報が前記記憶部に記憶されており、
前記処理部は、
クライアントから前記リリースグループに障害があった際に、以前のリリースグループに回復する処理要求であるリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、
前記リリースグループ識別情報をもとに前記リリース管理情報を検索し、
前記リリースグループ識別情報に関連付けられた監視期限日を取得し、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎていないとき、
リリースグループの回復処理をし、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎているとき、
リリースグループの回復処理をしない
ことを特徴とするリリースプログラム管理方法。
【請求項２】
前記処理部が、リリースグループ設定処理要求を受理すると、
前記クライアントから入力されたプログラム名称を、前記リリース管理情報から検索し、
同じプログラム名称があるとき、最も新しい監視期限日を取得し、
前記入力部から入力された今回設定するリリース日が前記最も新しい監視期限日を
過ぎているとき、該当するプログラムをリリースグループに設定登録する
ことを特徴とする請求項１に記載のリリースプログラム管理方法。
【請求項３】
前記リリースグループの回復処理は、
リリース後にプログラムをリリース前の状態に戻す必要が発生したとき、
前記処理部が、リリース時に退避しておいたプログラムのバックアップを
リリースグループ識別情報の単位で戻すこと
を特徴とする請求項１に記載のリリースプログラム管理方法。
【請求項４】
記憶部、処理部を有する管理サーバを備え、リリースするプログラムの管理をするリリースプログラム管理システムであって、
前記管理サーバは、
プログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理情報が前記記憶部に記憶されており、
前記処理部は、
クライアントから前記リリースグループに障害があった際に、以前のリリースグループに回復する処理要求であるリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、
前記リリースグループ識別情報をもとに前記リリース管理情報を検索し、
前記リリースグループ識別情報に関連付けられた監視期限日を取得し、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎていないとき、
リリースグループの回復処理をし、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎているとき、
リリースグループの回復処理をしない
ことを特徴とするリリースプログラム管理システム。
【請求項５】
前記処理部が、リリースグループ設定処理要求を受理すると、
前記クライアントから入力されたプログラム名称を、前記リリース管理情報から検索し、
同じプログラム名称があるとき、最も新しい監視期限日を取得し、
前記入力部から入力された今回設定するリリース日が前記最も新しい監視期限日を
過ぎているとき、該当するプログラムをリリースグループに設定登録する
ことを特徴とする請求項４に記載のリリースプログラム管理システム。
【請求項６】
前記リリースグループの回復処理は、
リリース後にプログラムをリリース前の状態に戻す必要が発生したとき、
前記処理部が、リリース時に退避しておいたプログラムのバックアップを
リリースグループ識別情報の単位で戻すこと
を特徴とする請求項４に記載のリリースプログラム管理システム。
【請求項１】
記憶部、処理部を有する管理サーバを備える情報処理システムにおいて、リリースするプログラムの管理をするリリースプログラム管理方法であって、
前記管理サーバは、
プログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理情報が前記記憶部に記憶されており、
前記処理部は、
クライアントから前記リリースグループに障害があった際に、以前のリリースグループに回復する処理要求であるリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、
前記リリースグループ識別情報をもとに前記リリース管理情報を検索し、
前記リリースグループ識別情報に関連付けられた監視期限日を取得し、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎていないとき、
リリースグループの回復処理をし、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎているとき、
リリースグループの回復処理をしない
ことを特徴とするリリースプログラム管理方法。
【請求項２】
前記処理部が、リリースグループ設定処理要求を受理すると、
前記クライアントから入力されたプログラム名称を、前記リリース管理情報から検索し、
同じプログラム名称があるとき、最も新しい監視期限日を取得し、
前記入力部から入力された今回設定するリリース日が前記最も新しい監視期限日を
過ぎているとき、該当するプログラムをリリースグループに設定登録する
ことを特徴とする請求項１に記載のリリースプログラム管理方法。
【請求項３】
前記リリースグループの回復処理は、
リリース後にプログラムをリリース前の状態に戻す必要が発生したとき、
前記処理部が、リリース時に退避しておいたプログラムのバックアップを
リリースグループ識別情報の単位で戻すこと
を特徴とする請求項１に記載のリリースプログラム管理方法。
【請求項４】
記憶部、処理部を有する管理サーバを備え、リリースするプログラムの管理をするリリースプログラム管理システムであって、
前記管理サーバは、
プログラムをリリースする際にひとつ以上のプログラムをリリースグループとして識別するリリースグループ識別情報、プログラム名称、リリース日、および監視期限日を関連付けたリリース管理情報が前記記憶部に記憶されており、
前記処理部は、
クライアントから前記リリースグループに障害があった際に、以前のリリースグループに回復する処理要求であるリリースグループ回復処理要求およびリリースグループ識別情報を受理すると、
前記リリースグループ識別情報をもとに前記リリース管理情報を検索し、
前記リリースグループ識別情報に関連付けられた監視期限日を取得し、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎていないとき、
リリースグループの回復処理をし、
前記リリースグループ回復処理要求の日が前記監視期限日を過ぎているとき、
リリースグループの回復処理をしない
ことを特徴とするリリースプログラム管理システム。
【請求項５】
前記処理部が、リリースグループ設定処理要求を受理すると、
前記クライアントから入力されたプログラム名称を、前記リリース管理情報から検索し、
同じプログラム名称があるとき、最も新しい監視期限日を取得し、
前記入力部から入力された今回設定するリリース日が前記最も新しい監視期限日を
過ぎているとき、該当するプログラムをリリースグループに設定登録する
ことを特徴とする請求項４に記載のリリースプログラム管理システム。
【請求項６】
前記リリースグループの回復処理は、
リリース後にプログラムをリリース前の状態に戻す必要が発生したとき、
前記処理部が、リリース時に退避しておいたプログラムのバックアップを
リリースグループ識別情報の単位で戻すこと
を特徴とする請求項４に記載のリリースプログラム管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【公開番号】特開２０１０−１３４８１３（Ｐ２０１０−１３４８１３Ａ）
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願番号】特願２００８−３１１７８２（Ｐ２００８−３１１７８２）
【出願日】平成２０年１２月８日（２００８．１２．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願日】平成２０年１２月８日（２００８．１２．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]