リリースバージョン管理サーバ、方法及びプログラム
【課題】ソフトウェア開発におけるリリース管理について、漏れやミスのない運用を低コストで実現する。
【解決手段】リリースバージョン管理サーバ１０１は、ソフトウェアプログラムのリリースバージョン管理をする機能を有する。利用者からのソフトウェアプログラムの改訂要望の起票を受け付けるＲＶ管理テーブル２０１と、本番環境と開発環境のプログラムの差異をチェックし、差異情報を起票された改訂要望に記述する差異チェック部２０２と、実際にリリースの指示があった場合、改訂要望を参照して改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック部２０３と、を備え、ＲＶ管理テーブル２０１は、修正検証完了のチェックがあれば、開発環境サーバから本番環境サーバへとソフトウェアプログラムの自動リリースを行う。
【解決手段】リリースバージョン管理サーバ１０１は、ソフトウェアプログラムのリリースバージョン管理をする機能を有する。利用者からのソフトウェアプログラムの改訂要望の起票を受け付けるＲＶ管理テーブル２０１と、本番環境と開発環境のプログラムの差異をチェックし、差異情報を起票された改訂要望に記述する差異チェック部２０２と、実際にリリースの指示があった場合、改訂要望を参照して改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック部２０３と、を備え、ＲＶ管理テーブル２０１は、修正検証完了のチェックがあれば、開発環境サーバから本番環境サーバへとソフトウェアプログラムの自動リリースを行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リリースバージョン管理サーバ、方法及びプログラムに関し、特に、リリースバージョン管理における人為的ミスを低減する技術に関する。
【背景技術】
【０００２】
ソフトウェアプログラムの開発においては、プログラムソースに改良を重ねて、リリースを複数回繰り返す場合がある。ところが、リリースミスや、プログラムソース保全忘れ等による、人為的な「リリース時の品質」に問題が発生する場合があり、リリースまでの流れにおいて人為的ミスを低減しなければならないという課題があった。
【０００３】
ソフトウェアプログラムのリリースバージョンの管理に関する技術としては、例えば、特許文献１に開示されている技術がある。特許文献１の段落００１９等を参照すると、プログラムを更新して、バージョンアップする技術について記載されている。
【特許文献１】特開２００１−１１７７６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の技術は、プログラムのリリース管理のみを目的としているに過ぎず、プログラムのリリース管理に加え、リリース前のプログラム、ソース群の保存、管理までを１セットとして実施することを目的とする観点に立つものではなかった。
【０００５】
そこで本発明は、上記実情に鑑みて、ソフトウェア開発におけるリリース管理について、漏れやミスのない運用を低コストで実現することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明のリリースバージョン管理サーバは、ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理サーバであって、利用者からのソフトウェアプログラムの改訂要望の起票を受け付けるリリースバージョン管理手段と、本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック手段と、リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック手段と、を備え、前記リリースバージョン管理手段は、前記修正検証完了のチェックがあれば、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行うことを特徴とする。
【０００７】
また、本発明のリリースバージョン管理方法は、ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理方法であって、利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録工程と、本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック工程と、リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック工程と、前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース工程と、を含むことを特徴とする。
【０００８】
また、本発明のリリースバージョン管理プログラムは、情報処理装置に、利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録処理と、本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック処理と、リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック処理と、前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース処理と、を実行させることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ソフトウェア開発におけるリリース管理について、漏れやミスのない運用を低コストで実現することが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の好適な実施の形態について図面を参照して説明する。
図１を参照すると、本実施形態の構成例が示されている。本実施形態のソフトウェアのリリースバージョン自動管理システム１００は、ＲＶ（リリースバージョン）管理サーバ１０１と、開発環境サーバ１０２と、本番環境サーバ１０３を含む。
【００１１】
各サーバは、ローカルエリアネットワーク（以下、ＬＡＮという）で通信可能に接続されている。ＬＡＮには開発者端末１０４と、管理者端末１０５と、利用者端末１０６も接続されていて、各端末は、各サーバにファイルをアップロードしたり、各サーバを操作したりするクライアント端末として機能する。
【００１２】
なお、本実施形態は、図１に限定されることはなく、例えば、セキュリティ向上のために、利用者端末１０６から開発環境サーバ１０２へのアクセスができないように変形して構成してもよい。
【００１３】
図２を参照すると、図１に示したＲＶ管理サーバ１０１の構成例が示されている。図２において、ＲＶ管理サーバ１０１は、ＲＶ管理テーブル２０１、差異チェック部２０２、リリースチェック部２０３、バックアップ部２０４を含む構成である。
【００１４】
ＲＶ管理テーブル２０１は、開発者端末１０４、管理者端末１０５、利用者端末１０６からアクセスすることができるサーバアプリケーションであるが、一部の機能は開発者端末１０４や管理者端末１０５からしか利用することができないよう構成して、セキュリティを高めてもよい。ＲＶ管理テーブル２０１は、プログラム単位にバージョン情報を管理し（管理するソフトウェアプログラムは複数である可能性がある）、プログラムのリリース、バックアップを自動化する機能を有する他、利用者端末１０６からの、本番環境サーバ１０３で稼働中ソフトウェアプログラムに関する改訂要望の起票を受け付ける機能等を有する。
【００１５】
差異チェック部２０２は、本番環境サーバ１０３と開発環境サーバ１０２で稼働中のソフトウェアプログラムのバージョンの違いによる差異を抽出し、チェックする機能を有する。また、差異があった場合には、それを改訂情報として、ＲＶ管理テーブル２０１に起票されている改訂要望に記述する機能も有する。
【００１６】
リリースチェック部２０３は、管理者端末１０５から新バージョンのリリースの指示があった場合に、ＲＶ管理テーブル２０１に起票されている改訂要望を参照して、差異チェック部２０２が検出し改訂要望に記述した改訂情報が記述されているか否かをチェックする機能を有する。このリリースチェック部２０３が、当該機能を有するため、利用者による修正検証が完了している場合は自動的にリリースに関する後段の処理に移ることができ、完了していない場合は移ることができない。したがって、本実施形態は、人為的ミス（ヒューマンエラー）を低減することができる。
【００１７】
バックアップ部２０４は、ＲＶ管理テーブル２０１により新バージョンのリリースがあった場合、自動的に、本番環境サーバ１０３で稼働中の旧バージョンのバックアップと、開発環境サーバ１０２において開発された新バージョンのプログラムソースの保全を行う機能を有する。本実施形態では、プログラム単位で更新管理を行っており、対象となるプログラムの異なるバージョン全てのソース群を保存している。
【００１８】
図３のフローチャートを参照し、本実施形態を利用したプログラムリリースの流れについて詳細に説明する。
【００１９】
図３において、利用者はシステムの不具合、要望事項をＲＶ管理テーブル２０１に起票する（ステップＳ１０１）。管理者は、ＲＶ管理テーブル２０１の起票を確認し、プログラムを改訂すべきか否か判断したのち（ステップＳ１０２）、開発者への改定の指示を行う（ステップＳ１０３）。
【００２０】
開発者は起票にしたがってプログラムを改定、テスト実施後（ステップＳ１０４）、利用者に動作検証を依頼する（ステップＳ１０５）。利用者はシステムの改定内容を確認し、動作検証・確認が完了するとその旨を開発者に連絡する（ステップＳ１０６）。この動作検証完了の連絡は、利用者がＲＶ管理テーブル２０１に起票されている改訂要望にチェックすることで行われる。
【００２１】
その後、開発者は利用者による動作検証が完了したことを確認（ステップＳ１０７）後、ＲＶ管理テーブル２０１の［チェック］ボタンを押下すると、修正プログラムがＲＶ管理テーブル２０１に自動的に登録される（ステップＳ１０８）。
【００２２】
これを受けて、ＲＶ管理テーブル２０１は、差異チェック部２０２を用いて本番環境サーバ１０３と開発環境サーバ１０２の差異をチェックし、自動的に新バージョンを検出する（ステップＳ１０９）ため、ＲＶ管理テーブル２０１は、改定情報（改訂事由等）を記述する（ステップＳ１１０）。
【００２３】
次に、管理者は、ＲＶ管理管理テーブル２０１から新バージョンを選択し、［リリース］ボタンを押下する。改訂情報が入力されていると、「修正検証完了」が自動チェックされ、問題なければ開発環境サーバの対象ファイルが本番環境サーバに自動リリースされる（ステップＳ１１１）。この際、旧バージョンのバックアップと新バージョンの生成ソース保全も自動で行われる（ステップＳ１１２）。
【００２４】
以上に説明したプログラムリリースの流れを、ＲＶ管理サーバ１０１の動作によって説明する。図４を参照すると、ＲＶ管理サーバ１０１の動作が示されている。
【００２５】
図４において、ＲＶ管理テーブル２０１は、利用者による改訂要望の起票があると、起票を受け付ける（ステップＳ２０１）。次に、ＲＶ管理テーブル２０１は、管理者から開発者への改訂の指示を受け付け（ステップＳ２０２）、改訂の指示がある場合は、開発者に改定依頼を自動送付する（ステップＳ２０３）。
【００２６】
開発者と利用者の間で改訂プログラムの開発とその検証が完了した場合、利用者が動作検証完了をチェックするので、ＲＶ管理テーブル２０１は、動作検証完了の連絡を受け付け（ステップＳ２０４）、開発者に修正したプログラムの登録を許可する旨、連絡する（ステップＳ２０５）。
【００２７】
また、ＲＶ管理テーブル２０１は、修正したプログラムの登録を受け付け（ステップＳ２０６）、登録があった場合、差異チェック部２０２を用いて、開発環境サーバ１０４のソフトウェアプログラムと、本番環境サーバ１０３で稼働中のソフトウェアプログラムの差異をチェックする。また、その際、差異があった場合には、それを改訂情報として、ＲＶ管理テーブル２０１に起票されている改訂要望に記述する（ステップＳ２０７）。すなわち、改訂情報の内容は、差異チェック部２０２が検出した、旧バージョンと新バージョンとの差異情報等である。
【００２８】
その後、ＲＶ管理テーブル２０１は、管理者による新バージョンのリリース指示を受け付ける（ステップＳ２０８）。指示があった場合は、ＲＶ管理テーブル２０１は、リリースチェック部２０３を用いて、リリースチェックを行う。リリースチェック部２０３は、ＲＶ管理テーブル２０１に起票されている改訂要望を参照して、差異チェック部２０２が検出し改訂要望に記述した改訂情報が記述されているか否かをチェックする（ステップＳ２０９）。記述されている場合、修正検証完了とする。
【００２９】
修正検証完了の場合、ＲＶ管理テーブル２０１は、バックアップ部２０４を用いて、開発環境サーバ１０２から本番環境サーバ１０３への新バージョンのリリースをし、また、新バージョンのソース保全と、旧バージョンのバックアップと、を実行する（ステップＳ２１０）。
【００３０】
上述した本実施形態によれば、リリースミスや、プログラムソース保全忘れ等の発生を抑止できる。また、リリース管理とバージョン管理が効率化され、管理コストを低減できる。なお、本発明は、システム管理者がプログラムリリース作業を行う場面の全てに利用ができる。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態に係るソフトウェアリリース自動管理システムの構成例を示すブロック図である。
【図２】図１のＲＶ管理サーバの構成例を示すブロック図である。
【図３】本発明の実施形態を利用した場合の流れを示すフローチャートである。
【図４】本発明の実施形態の動作を示すフローチャートである。
【符号の説明】
【００３２】
１００ リリースバージョン管理システム
１０１ ＲＶ（リリースバージョン）管理サーバ
１０２ 開発環境サーバ
１０３ 本番環境サーバ
１０４ 開発者端末
１０５ 管理者端末
１０６ 利用者端末
２０１ ＲＶ管理テーブル
２０２ 差異チェック部
２０３ リリースチェック部
２０４ バックアップ部
【技術分野】
【０００１】
本発明は、リリースバージョン管理サーバ、方法及びプログラムに関し、特に、リリースバージョン管理における人為的ミスを低減する技術に関する。
【背景技術】
【０００２】
ソフトウェアプログラムの開発においては、プログラムソースに改良を重ねて、リリースを複数回繰り返す場合がある。ところが、リリースミスや、プログラムソース保全忘れ等による、人為的な「リリース時の品質」に問題が発生する場合があり、リリースまでの流れにおいて人為的ミスを低減しなければならないという課題があった。
【０００３】
ソフトウェアプログラムのリリースバージョンの管理に関する技術としては、例えば、特許文献１に開示されている技術がある。特許文献１の段落００１９等を参照すると、プログラムを更新して、バージョンアップする技術について記載されている。
【特許文献１】特開２００１−１１７７６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の技術は、プログラムのリリース管理のみを目的としているに過ぎず、プログラムのリリース管理に加え、リリース前のプログラム、ソース群の保存、管理までを１セットとして実施することを目的とする観点に立つものではなかった。
【０００５】
そこで本発明は、上記実情に鑑みて、ソフトウェア開発におけるリリース管理について、漏れやミスのない運用を低コストで実現することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明のリリースバージョン管理サーバは、ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理サーバであって、利用者からのソフトウェアプログラムの改訂要望の起票を受け付けるリリースバージョン管理手段と、本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック手段と、リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック手段と、を備え、前記リリースバージョン管理手段は、前記修正検証完了のチェックがあれば、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行うことを特徴とする。
【０００７】
また、本発明のリリースバージョン管理方法は、ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理方法であって、利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録工程と、本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック工程と、リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック工程と、前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース工程と、を含むことを特徴とする。
【０００８】
また、本発明のリリースバージョン管理プログラムは、情報処理装置に、利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録処理と、本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック処理と、リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック処理と、前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース処理と、を実行させることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ソフトウェア開発におけるリリース管理について、漏れやミスのない運用を低コストで実現することが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の好適な実施の形態について図面を参照して説明する。
図１を参照すると、本実施形態の構成例が示されている。本実施形態のソフトウェアのリリースバージョン自動管理システム１００は、ＲＶ（リリースバージョン）管理サーバ１０１と、開発環境サーバ１０２と、本番環境サーバ１０３を含む。
【００１１】
各サーバは、ローカルエリアネットワーク（以下、ＬＡＮという）で通信可能に接続されている。ＬＡＮには開発者端末１０４と、管理者端末１０５と、利用者端末１０６も接続されていて、各端末は、各サーバにファイルをアップロードしたり、各サーバを操作したりするクライアント端末として機能する。
【００１２】
なお、本実施形態は、図１に限定されることはなく、例えば、セキュリティ向上のために、利用者端末１０６から開発環境サーバ１０２へのアクセスができないように変形して構成してもよい。
【００１３】
図２を参照すると、図１に示したＲＶ管理サーバ１０１の構成例が示されている。図２において、ＲＶ管理サーバ１０１は、ＲＶ管理テーブル２０１、差異チェック部２０２、リリースチェック部２０３、バックアップ部２０４を含む構成である。
【００１４】
ＲＶ管理テーブル２０１は、開発者端末１０４、管理者端末１０５、利用者端末１０６からアクセスすることができるサーバアプリケーションであるが、一部の機能は開発者端末１０４や管理者端末１０５からしか利用することができないよう構成して、セキュリティを高めてもよい。ＲＶ管理テーブル２０１は、プログラム単位にバージョン情報を管理し（管理するソフトウェアプログラムは複数である可能性がある）、プログラムのリリース、バックアップを自動化する機能を有する他、利用者端末１０６からの、本番環境サーバ１０３で稼働中ソフトウェアプログラムに関する改訂要望の起票を受け付ける機能等を有する。
【００１５】
差異チェック部２０２は、本番環境サーバ１０３と開発環境サーバ１０２で稼働中のソフトウェアプログラムのバージョンの違いによる差異を抽出し、チェックする機能を有する。また、差異があった場合には、それを改訂情報として、ＲＶ管理テーブル２０１に起票されている改訂要望に記述する機能も有する。
【００１６】
リリースチェック部２０３は、管理者端末１０５から新バージョンのリリースの指示があった場合に、ＲＶ管理テーブル２０１に起票されている改訂要望を参照して、差異チェック部２０２が検出し改訂要望に記述した改訂情報が記述されているか否かをチェックする機能を有する。このリリースチェック部２０３が、当該機能を有するため、利用者による修正検証が完了している場合は自動的にリリースに関する後段の処理に移ることができ、完了していない場合は移ることができない。したがって、本実施形態は、人為的ミス（ヒューマンエラー）を低減することができる。
【００１７】
バックアップ部２０４は、ＲＶ管理テーブル２０１により新バージョンのリリースがあった場合、自動的に、本番環境サーバ１０３で稼働中の旧バージョンのバックアップと、開発環境サーバ１０２において開発された新バージョンのプログラムソースの保全を行う機能を有する。本実施形態では、プログラム単位で更新管理を行っており、対象となるプログラムの異なるバージョン全てのソース群を保存している。
【００１８】
図３のフローチャートを参照し、本実施形態を利用したプログラムリリースの流れについて詳細に説明する。
【００１９】
図３において、利用者はシステムの不具合、要望事項をＲＶ管理テーブル２０１に起票する（ステップＳ１０１）。管理者は、ＲＶ管理テーブル２０１の起票を確認し、プログラムを改訂すべきか否か判断したのち（ステップＳ１０２）、開発者への改定の指示を行う（ステップＳ１０３）。
【００２０】
開発者は起票にしたがってプログラムを改定、テスト実施後（ステップＳ１０４）、利用者に動作検証を依頼する（ステップＳ１０５）。利用者はシステムの改定内容を確認し、動作検証・確認が完了するとその旨を開発者に連絡する（ステップＳ１０６）。この動作検証完了の連絡は、利用者がＲＶ管理テーブル２０１に起票されている改訂要望にチェックすることで行われる。
【００２１】
その後、開発者は利用者による動作検証が完了したことを確認（ステップＳ１０７）後、ＲＶ管理テーブル２０１の［チェック］ボタンを押下すると、修正プログラムがＲＶ管理テーブル２０１に自動的に登録される（ステップＳ１０８）。
【００２２】
これを受けて、ＲＶ管理テーブル２０１は、差異チェック部２０２を用いて本番環境サーバ１０３と開発環境サーバ１０２の差異をチェックし、自動的に新バージョンを検出する（ステップＳ１０９）ため、ＲＶ管理テーブル２０１は、改定情報（改訂事由等）を記述する（ステップＳ１１０）。
【００２３】
次に、管理者は、ＲＶ管理管理テーブル２０１から新バージョンを選択し、［リリース］ボタンを押下する。改訂情報が入力されていると、「修正検証完了」が自動チェックされ、問題なければ開発環境サーバの対象ファイルが本番環境サーバに自動リリースされる（ステップＳ１１１）。この際、旧バージョンのバックアップと新バージョンの生成ソース保全も自動で行われる（ステップＳ１１２）。
【００２４】
以上に説明したプログラムリリースの流れを、ＲＶ管理サーバ１０１の動作によって説明する。図４を参照すると、ＲＶ管理サーバ１０１の動作が示されている。
【００２５】
図４において、ＲＶ管理テーブル２０１は、利用者による改訂要望の起票があると、起票を受け付ける（ステップＳ２０１）。次に、ＲＶ管理テーブル２０１は、管理者から開発者への改訂の指示を受け付け（ステップＳ２０２）、改訂の指示がある場合は、開発者に改定依頼を自動送付する（ステップＳ２０３）。
【００２６】
開発者と利用者の間で改訂プログラムの開発とその検証が完了した場合、利用者が動作検証完了をチェックするので、ＲＶ管理テーブル２０１は、動作検証完了の連絡を受け付け（ステップＳ２０４）、開発者に修正したプログラムの登録を許可する旨、連絡する（ステップＳ２０５）。
【００２７】
また、ＲＶ管理テーブル２０１は、修正したプログラムの登録を受け付け（ステップＳ２０６）、登録があった場合、差異チェック部２０２を用いて、開発環境サーバ１０４のソフトウェアプログラムと、本番環境サーバ１０３で稼働中のソフトウェアプログラムの差異をチェックする。また、その際、差異があった場合には、それを改訂情報として、ＲＶ管理テーブル２０１に起票されている改訂要望に記述する（ステップＳ２０７）。すなわち、改訂情報の内容は、差異チェック部２０２が検出した、旧バージョンと新バージョンとの差異情報等である。
【００２８】
その後、ＲＶ管理テーブル２０１は、管理者による新バージョンのリリース指示を受け付ける（ステップＳ２０８）。指示があった場合は、ＲＶ管理テーブル２０１は、リリースチェック部２０３を用いて、リリースチェックを行う。リリースチェック部２０３は、ＲＶ管理テーブル２０１に起票されている改訂要望を参照して、差異チェック部２０２が検出し改訂要望に記述した改訂情報が記述されているか否かをチェックする（ステップＳ２０９）。記述されている場合、修正検証完了とする。
【００２９】
修正検証完了の場合、ＲＶ管理テーブル２０１は、バックアップ部２０４を用いて、開発環境サーバ１０２から本番環境サーバ１０３への新バージョンのリリースをし、また、新バージョンのソース保全と、旧バージョンのバックアップと、を実行する（ステップＳ２１０）。
【００３０】
上述した本実施形態によれば、リリースミスや、プログラムソース保全忘れ等の発生を抑止できる。また、リリース管理とバージョン管理が効率化され、管理コストを低減できる。なお、本発明は、システム管理者がプログラムリリース作業を行う場面の全てに利用ができる。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態に係るソフトウェアリリース自動管理システムの構成例を示すブロック図である。
【図２】図１のＲＶ管理サーバの構成例を示すブロック図である。
【図３】本発明の実施形態を利用した場合の流れを示すフローチャートである。
【図４】本発明の実施形態の動作を示すフローチャートである。
【符号の説明】
【００３２】
１００ リリースバージョン管理システム
１０１ ＲＶ（リリースバージョン）管理サーバ
１０２ 開発環境サーバ
１０３ 本番環境サーバ
１０４ 開発者端末
１０５ 管理者端末
１０６ 利用者端末
２０１ ＲＶ管理テーブル
２０２ 差異チェック部
２０３ リリースチェック部
２０４ バックアップ部
【特許請求の範囲】
【請求項１】
ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理サーバであって、
利用者からのソフトウェアプログラムの改訂要望の起票を受け付けるリリースバージョン管理手段と、
本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック手段と、
リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック手段と、を備え、
前記リリースバージョン管理手段は、前記修正検証完了のチェックがあれば、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行うことを特徴とする、リリースバージョン管理サーバ。
【請求項２】
前記リリースバージョン管理手段が前記自動リリースを行った場合、前記開発環境サーバのソフトウェアプログラムの生成ソースと、前記本番環境サーバのソフトウェアプログラムと、をバックアップするバックアップ手段を、備えることを特徴とする請求項１記載のリリースバージョン管理サーバ。
【請求項３】
前記リリースバージョン管理手段は、前記起票を受け付けた場合、ソフトウェアプログラムの開発者に改訂要望があった旨の通知を行い、
前記利用者から動作検証完了の操作を受け付け、当該動作検証完了の操作があった場合に限り、前記開発者に、新バージョンの登録を許可することを特徴とする請求項１又は２記載のリリースバージョン管理サーバ。
【請求項４】
ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理方法であって、
利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録工程と、
本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック工程と、
リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック工程と、
前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース工程と、
を含むことを特徴とするリリースバージョン管理方法。
【請求項５】
前記自動リリース工程の後、前記開発環境サーバのソフトウェアプログラムの生成ソースと、前記本番環境サーバのソフトウェアプログラムと、をバックアップするバックアップ工程を有することを特徴とする請求項４記載のリリースバージョン管理方法。
【請求項６】
情報処理装置に、
利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録処理と、
本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック処理と、
リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック処理と、
前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース処理と、
を実行させることを特徴とするリリースバージョン管理プログラム。
【請求項１】
ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理サーバであって、
利用者からのソフトウェアプログラムの改訂要望の起票を受け付けるリリースバージョン管理手段と、
本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック手段と、
リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック手段と、を備え、
前記リリースバージョン管理手段は、前記修正検証完了のチェックがあれば、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行うことを特徴とする、リリースバージョン管理サーバ。
【請求項２】
前記リリースバージョン管理手段が前記自動リリースを行った場合、前記開発環境サーバのソフトウェアプログラムの生成ソースと、前記本番環境サーバのソフトウェアプログラムと、をバックアップするバックアップ手段を、備えることを特徴とする請求項１記載のリリースバージョン管理サーバ。
【請求項３】
前記リリースバージョン管理手段は、前記起票を受け付けた場合、ソフトウェアプログラムの開発者に改訂要望があった旨の通知を行い、
前記利用者から動作検証完了の操作を受け付け、当該動作検証完了の操作があった場合に限り、前記開発者に、新バージョンの登録を許可することを特徴とする請求項１又は２記載のリリースバージョン管理サーバ。
【請求項４】
ソフトウェアプログラムのリリースバージョン管理をするリリースバージョン管理方法であって、
利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録工程と、
本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック工程と、
リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック工程と、
前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース工程と、
を含むことを特徴とするリリースバージョン管理方法。
【請求項５】
前記自動リリース工程の後、前記開発環境サーバのソフトウェアプログラムの生成ソースと、前記本番環境サーバのソフトウェアプログラムと、をバックアップするバックアップ工程を有することを特徴とする請求項４記載のリリースバージョン管理方法。
【請求項６】
情報処理装置に、
利用者からのソフトウェアプログラムの改訂要望の起票を受け付ける改訂要望登録処理と、
本番環境サーバのソフトウェアプログラムと、開発環境サーバのソフトウェアプログラムと、の差異をチェックし、差異があった場合、当該差異に関する差異情報を起票された前記改訂要望に記述する差異チェック処理と、
リリースの指示があった場合、前記改訂要望を参照して前記改訂情報が記述されていれば、修正検証完了とするチェックを行うリリースチェック処理と、
前記修正検証完了のチェックがある場合に、前記開発環境サーバから前記本番環境サーバへとソフトウェアプログラムの自動リリースを行う自動リリース処理と、
を実行させることを特徴とするリリースバージョン管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００９−１９９２２９（Ｐ２００９−１９９２２９Ａ）
【公開日】平成２１年９月３日（２００９．９．３）
【国際特許分類】
【出願番号】特願２００８−３８７６９（Ｐ２００８−３８７６９）
【出願日】平成２０年２月２０日（２００８．２．２０）
【出願人】（０００２１３３０１）中部日本電気ソフトウェア株式会社 (56)
【Ｆターム（参考）】
【公開日】平成２１年９月３日（２００９．９．３）
【国際特許分類】
【出願日】平成２０年２月２０日（２００８．２．２０）
【出願人】（０００２１３３０１）中部日本電気ソフトウェア株式会社 (56)
【Ｆターム（参考）】
[ Back to top ]