JP6960216B2 - 計算機システム及びプログラムのリリース管理方法 - Google Patents

Description

本発明は、プログラムのリリースを管理するシステム及び方法に関する。

アプリケーションシステム開発において、開発したプログラムを試験用の実行環境又は本番用の実行環境にリリースする場合に、プログラムのバージョンの取り違い及びプログラムの漏れがないように管理する必要である。

プログラムのバージョンの取り違いを防ぐための技術として、開発したプログラムをデータベース又はファイルシステムに格納する場合に、プログラムに対してリビジョン番号を一意に割り当て、明示的にバージョン管理を行う技術が広く普及している。また、特許文献１及び特許文献２に記載の技術も知られている。

特許文献１には、「プログラム開発管理装置１００において、テーマ別プログラムテーブル１０は、開発すべきプログラムとリリース条件とを開発テーマごとに管理する。ディレクトリ生成部１３０は、テーマ別プログラムテーブル１０を参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリをリリース記憶領域１７０に生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納する。」ことが記載されている。

また、特許文献２には、「リリース管理システム１０は、開発側領域３８及び本番側領域４０に区画された記憶装置と制御部３６を備えたネットワーク接続ストレージ２６と、開発者端末１２と、承認者端末１４と、ライブラリアン端末１６と、リリース端末１８と、本番機３４と、転送サーバ２４と、リリースサーバ３２とを備える。転送サーバ２４は、ライブラリアン端末１６からのコマンド入力に基づいて、開発側領域３８に格納された特定のプログラムを本番側領域４０に転送させるコマンドを制御部３６に発行する。リリースサーバ３２は、リリース端末１８からのコマンド入力に基づいて、本番側領域４０に格納されたプログラムを取得するコマンドを制御部３６に発行し、取得したプログラムを本番機３４に転送する。」ことが記載されている。

特開２００９−２４４９７４号公報 特開２０１１−５９８４７号公報

結合試験及び総合試験において不良が検出された場合、プログラムの開発者は、プログラムの修正及び単体試験を行う。また、プログラムの開発者は、単体試験が完了したプログラムに対して再度結合試験又は総合試験を行うために、試験用の実行環境へのプログラムのリリースをリリース担当者に依頼する。

前述した一連の開発プロセスにおいて、プログラムのリリース管理が不十分であることが原因で修正されたプログラムがリリース資材にすべて含まれていなかったり、また、単体試験が完了していないプログラムがリリース資材に混入したりするケースがある。また、リリース対象のプログラムが明示されておらず、かつ、承認プロセスに基づく承認者の判断がされないまま実行環境にプログラムがリリースされてしまうケースがある。

このようなケースが発生した場合、試験の進行を阻害し、ひいてはシステム障害の原因となる。そのため、これらのケースが発生した場合、不良及びプログラムの管理状況の見直し、リリースのやり直し、及び試験のやり直し等が行われるため、試験工数の増大を招き、開発現場が混乱する。したがって、昨今増加傾向にある大規模なシステム開発や納期が短いシステム開発において、ビジネスの成否を分ける致命的な問題となる。

特許文献１に記載の技術では、リリース条件毎にプログラムの格納先を分けることによって、不適切なプログラムがリリースされる可能性を低減できる。また、特許文献２に記載の技術では、承認者の判断がなされないままプログラムが実行環境にリリースされるケース、及び、不正なプログラムがリリース資材に混入するケースを防ぐことができる。

しかし、特許文献１及び特許文献２に記載の技術では、開発タスクとプログラムを実行環境にリリースするための操作であるリリース申請とが関連付けて管理されていないため、開発者等の操作ミス及び判断ミス等に起因するリリースの誤りを防ぐことができない。

本発明は、開発タスク及びリリース申請を自動的に関連づけて管理し、必要十分なプログラムが実行環境にリリースされるよう制御するシステム及び方法を提供することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の計算機を備える計算機システムであって、前記計算機システムは、開発対象のプログラムを格納する第１のリポジトリと、実行環境にリリースするプログラムを格納する第２のリポジトリと、を含み、前記複数の計算機の少なくとも一つの計算機は、プログラムの開発タスクに割り当てられるチケット番号、及び前記プログラムの開発タスクの進捗状態から構成されるレコードを含むチケット管理情報と、前記第１のリポジトリに格納されるプログラムに割り当てられるリビジョン番号、及び前記プログラムの識別情報から構成されるレコードを含むリポジトリ管理情報と、を保持し、前記実行環境への前記第２のリポジトリに格納されるプログラムのリリースを制御する統合管理モジュールを有し、前記統合管理モジュールは、前記開発対象のプログラムを前記実行環境にリリースするための操作であるリリース申請を識別するための申請番号、前記チケット番号、及び前記リビジョン番号から構成されるレコードを含む統合管理情報を管理し、第１のプログラムに割り当てられた第１のリビジョン番号及び前記第１のプログラムの開発タスクに割り当てられた第１のチケット番号を含む第１のリリース申請を受け付けた場合、前記第１のリリース申請の申請番号、前記第１のチケット番号、及び前記第１のリビジョン番号から構成される第１のレコードを前記統合管理情報に追加し、前記第１のリリース申請の識別情報を含む、前記第１のリリース申請を許可するための操作である第１の承認を受け付けた場合、前記第１の承認を行えるか否かを判定し、前記第１の承認を行えると判定された場合、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって前記第１のプログラムを取得し、前記第１のプログラムを前記第２のリポジトリに格納し、前記統合管理情報に基づいて前記チケット管理情報にアクセスすることによって前記第１のプログラムの開発タスクの進捗状態をリリースが完了したことを示す値に更新することを特徴とする。

本発明によれば、プログラムの開発タスク及びリリース申請を自動的に関連付けて管理することによって、リリースの誤りを防ぐことができる。これによって、試験の進行阻害及び試験工数の増加を抑止できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

実施例１の計算機システムの構成例を示す図である。 実施例１のプログラム統合管理サーバ及び開発者端末の構成を示す図である。 実施例１のチケット管理情報の一例を示す図である。 実施例１の開発リポジトリ管理情報の一例を示す図である。 実施例１のプログラム統合管理情報の一例を示す図である。 実施例１のサーバ間の入出力の一例を示す図である。 実施例１の計算機システムにおける処理の流れを説明するシーケンス図である。 実施例１の計算機システムにおける処理の流れを説明するシーケンス図である。 実施例１の計算機システムにおける処理の流れを説明するシーケンス図である。 実施例１の計算機システムにおける処理の流れを説明するシーケンス図である。 実施例１の出力装置に表示される画面の一例を示す図である。 実施例１の出力装置に表示される画面の一例を示す図である。 実施例１の出力装置に表示される画面の一例を示す図である。 実施例１の出力装置に表示される画面の一例を示す図である。 実施例１のプログラム統合管理サーバがリリース申請の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。 実施例１のプログラム統合管理サーバが申請承認の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。

開発タスクとプログラムを実行環境にリリースするための操作であるリリース申請とが関連付けて管理されていないために発生するリリースの誤りとしては、例えば、以下のようなものがある。

（１）承認者が、リリース申請が行われたプログラムをリリースしてよい状況であるか否かを正しく判断できない。（２）複数の開発者からリリース申請が行われた場合、リリース担当者と開発者との間で、どのリリース申請まで（どの不良の対応まで）がリリース資材に取り込まれたのかを共有できない。（３）承認者は、リリース資材に含まれているべきプログラムが全てそろっているか否かを確認できないため、リリース資材にプログラムの漏れが発生する可能性がある。（４）リリース申請に係るプログラムの数が多い場合、開発者がリリースすべきプログラムを漏らしてしまう可能性がある。

以下、図面を用いて実施例を説明する。各図において共通の構成については同一の参照符号が付されている。

図１は、実施例１の計算機システムの構成例を示す図である。

実施例１の計算機システムは、チケット管理サーバ１０１、開発リポジトリサーバ１０２、リリースリポジトリサーバ１０３、プログラム統合管理サーバ１０４、開発者端末１１１、承認者端末１１２、及びリリース管理者端末１１３を備える。各サーバは、サーバセグメント１００に存在し、他のサーバと通信可能なように接続される。また、各端末は、ユーザ端末セグメント１１０に存在する。各端末は、ユーザ端末セグメント１１０からネットワーク１２０を介して、サーバセグメント１００に接続する。

チケット管理サーバ１０１は、プログラムの開発タスクを管理する。本実施例では、チケット管理サーバ１０１は、不良等に基づくプログラムの開発タスクをチケットと呼称する単位で管理する。

開発リポジトリサーバ１０２は、開発対象のプログラムを格納する開発リポジトリを管理する。具体的には、開発リポジトリサーバ１０２は、開発者端末１１１がコミットと呼称される格納操作を行った場合、プログラムを開発リポジトリに格納する。開発リポジトリへのプログラムの格納時には、リビジョン番号がプログラムに付与される。なお、コミットは、一つのプログラムに対して行われてもよいし、複数のプログラムに対して行われてもよい。

リリースリポジトリサーバ１０３は、承認者によって承認されたプログラムのみを格納するリリースリポジトリを管理する。リリースリポジトリは、リリースするプログラムを格納するリポジトリであり、開発者に対しては公開されない。後述するように、承認者端末１１２によってリリース申請を許可する操作である承認が行われたプログラムのみが開発リポジトリからリリースリポジトリにコピーされ、さらに、リリースリポジトリに格納されるプログラムが実行環境へリリースされる。

プログラム統合管理サーバ１０４は、リリース申請、リリース申請に対応するプログラム、及び当該プログラムの開発タスクを管理するチケットを関連付けて管理する。具体的には、プログラム統合管理サーバ１０４は、開発者端末１１１からリリース申請を受け付けた場合、リリース申請の識別番号、リリース申請に対応するプログラムのリビジョン番号、及び当該プログラムに対応する開発タスクを管理するチケットのチケット番号を関連付けて記憶する。

開発者端末１１１は、プログラムを開発する開発者が操作する端末である。承認者端末１１２は、リリース申請の承認を行う承認者が操作する端末である。リリース管理者端末１１３は、実行環境へのプログラムのリリースを管理するリリース管理者が操作する端末である。

図２は、実施例１のプログラム統合管理サーバ１０４及び開発者端末１１１の構成を示す図である。

プログラム統合管理サーバ１０４は、ＣＰＵ２１１、メモリ２１２、記憶装置２１３、及びネットワークインタフェース（ＮＷ Ｉ／Ｆ）２１４を有し、各装置はデータバス２１５を介して互いに接続される。各装置は、データバス２１５を介して他の装置と通信する。なお、プログラム統合管理サーバ１０４は、入力装置及び出力装置等と接続するＩＯ Ｉ／Ｆを有してもよい。

ＣＰＵ２１１は、少なくとも一つのコアを有する演算装置であり、メモリ２１２に格納されるプログラムを実行する。ＣＰＵ２１１がプログラムを実行することによって、所定の機能を有するモジュールを実現する。以下の説明では、モジュールを主語に処理を説明する場合、ＣＰＵ２１１が当該モジュールを実現するプログラムを実行していることを示す。

メモリ２１２は、ＣＰＵ２１１が実行するプログラム及び当該プログラムに必要な情報を格納する。また、メモリ２１２は、モジュールが一時的に使用するワークエリアを含む。メモリ２１２は、不揮発性の記憶素子から構成されるＲＯＭ、及び揮発性の記憶素子から構成されるＲＡＭ等が考えられる。メモリ２１２に格納されるプログラムについては後述する。

記憶装置２１３は、プログラム及び情報を格納する。記憶装置２１３は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等が考えられる。なお、メモリ２１２に格納されるプログラム及び情報は、記憶装置２１３に格納されてもよい。この場合、ＣＰＵ２１１は、記憶装置２１３からプログラム及び情報を読み出し、メモリ２１２にプログラム及び情報をロードする。記憶装置２１３に格納される情報については後述する。

ＮＷ Ｉ／Ｆ２１４は、ネットワークを介して外部装置と接続するためのインタフェースである。

なお、チケット管理サーバ１０１、開発リポジトリサーバ１０２、リリースリポジトリサーバ１０３のハードウェア構成は、プログラム統合管理サーバ１０４のハードウェア構成と同一である。

ここで、各サーバのメモリ２１２に格納されるプログラム及び記憶装置２１３に格納される情報について説明する。

プログラム統合管理サーバ１０４のメモリ２１２は、統合管理モジュール２２０を実現するプログラムを格納する。統合管理モジュール２２０は、プログラム統合管理サーバ１０４を制御するモジュールであり、複数のモジュールを含む。具体的には、統合管理モジュール２２０は、入出力モジュール２２１、判定モジュール２２２、登録モジュール２２３、及びコピー実行モジュール２２４を含む。

入出力モジュール２２１は、外部から入力されたデータを受信し、また、外部へ出力するデータを送信する。判定モジュール２２２は、チケット管理サーバ１０１及び開発リポジトリサーバ１０２が保持する情報にリリース申請の対象に関連するデータが格納されているか否かを判定する。登録モジュール２２３は、データの更新及びデータの登録を行う。コピー実行モジュール２２４は、開発リポジトリとリリースリポジトリとの間のコピー処理を制御する。

プログラム統合管理サーバ１０４の記憶装置２１３は、プログラム統合管理情報２３０を格納する。プログラム統合管理情報２３０は、リリース申請と、リリース申請に関連するプログラムの開発タスクとの対応関係を管理する情報である。プログラム統合管理情報２３０の詳細は、図５を用いて説明する。記憶装置２１３に格納される情報は、メモリ２１２に格納されてもよい。

なお、プログラム統合管理サーバ１０４の記憶装置２１３には、開発者、承認者、及びリリース管理者を区別するためのユーザ情報（図示省略）が格納される。ユーザ情報は、ユーザの名称、アカウントの種別、及び操作権限等から構成されるレコードを含む。

チケット管理サーバ１０１、開発リポジトリサーバ１０２、及びリリースリポジトリサーバ１０３のそれぞれのメモリ２１２は、各サーバを制御する制御モジュール６０１、６０２、６０３（図６参照）を実現するプログラムを格納する。

チケット管理サーバ１０１の記憶装置２１３は、チケット管理情報３００を格納する。チケット管理情報３００は、プログラムの開発タスクを管理する情報である。チケット管理情報３００の詳細は、図３を用いて説明する。

開発リポジトリサーバ１０２の記憶装置２１３は、開発リポジトリ管理情報４００を格納する。開発リポジトリ管理情報４００は、開発リポジトリに格納されるプログラムを管理する情報である。開発リポジトリ管理情報４００の詳細は、図４を用いて説明する。

次に、開発者端末１１１について説明する。開発者端末１１１は、ＣＰＵ２５１、メモリ２５２、ＮＷ Ｉ／Ｆ２５３、及びＩＯ Ｉ／Ｆ２５４を有し、各装置はデータバス２５５を介して互いに接続される。

ＣＰＵ２５１、メモリ２５２、及びＮＷ Ｉ／Ｆ２５３は、ＣＰＵ２１１、メモリ２１２、及びＮＷ Ｉ／Ｆ２１４と同様のものである。

ＩＯ Ｉ／Ｆ２５４は、外部装置と接続するインタフェースである。本実施例では、ＩＯ Ｉ／Ｆ２５４は、入力装置２５６及び出力装置２５７と接続する。

入力装置２５６は、各種データを入力するために用いられる装置であり、例えば、マウス、キーボード、及びタッチパネルが考えられる。出力装置２５７は、データを出力するために用いられる装置であり、例えば、ディスプレイ及びタッチパネル等が考えられる。

なお、承認者端末１１２及びリリース管理者端末１１３のハードウェア構成は、開発者端末１１１のハードウェア構成と同一である。

図３は、実施例１のチケット管理情報３００の一例を示す図である。

チケット管理情報３００は、チケット番号３０１、ステータス３０２、チケット内容３０３、担当チーム３０４、担当者３０５、及び期日３０６から構成されるレコードを含む。なお、レコードには、前述した以外のカラムが含まれてもよい。

チケット番号３０１は、開発タスクの管理単位であるチケットの識別情報である。チケット番号３０１は、チケット管理情報３００のレコードを識別するための識別情報としても用いられる。本実施例では、自動採番機能に基づいて算出された番号がチケット番号３０１に設定される。

ステータス３０２は、開発タスクの進捗状態を示す情報である。ステータス３０２には、「リリース申請前」、「リリース受付済」、「リリース待ち」、「リリース済」、及び「試験完了」等が格納される。ステータス３０２は、開発タスクの進捗に応じて更新される。

なお、「試験完了」は、試験用の実行環境において、リリースされたプログラムを用いた結合試験又や総合試験が完了した情報を示す。本実施例では、関連する全てのチケットのステータス３０２が「試験完了」となった場合に本番用の実行環境へのリリースが行われる。これによって、不良の対応漏れ等を防止することができる。

チケット内容３０３は、承認者が承認するか否かを判断する場合に判断材料となる情報である。例えば、チケット内容３０３には、具体的な不良の内容及び対策方法等が格納される。

担当チーム３０４及び担当者３０５は、プログラムを開発するチーム及び担当者の情報である。なお、担当チーム３０４及び担当者３０５に設定される情報は、ユーザ情報から取得できる。期日３０６は、プログラムの開発期日である。

図４は、実施例１の開発リポジトリ管理情報４００の一例を示す図である。

開発リポジトリ管理情報４００は、リビジョン番号４０１、プログラム名４０２、プログラム格納パス４０３、及びコミットユーザ４０４から構成されるレコードを含む。なお、レコードには、前述した以外のカラムが含まれてもよい。

リビジョン番号４０１は、開発リポジトリに格納されるプログラムを識別するための識別情報である。リビジョン番号４０１は、開発リポジトリ管理情報４００のレコードを識別するための識別情報としても用いられる。本実施例では、自動採番機能に基づいて算出された番号がリビジョン番号４０１に設定される。

プログラム名４０２は、開発リポジトリに格納されるプログラムの名称である。

プログラム格納パス４０３は、開発リポジトリにおけるプログラムの格納場所を示すパスである。

コミットユーザ４０４は、コミットを行ったユーザの名称である。コミットユーザ４０４には、担当者３０５に設定された名称が格納される。

図５は、実施例１のプログラム統合管理情報２３０の一例を示す図である。

プログラム統合管理情報２３０は、申請番号５０１、チケット番号５０２、リビジョン番号５０３、申請者５０４、承認ステータス５０５、及びリリースステータス５０６から構成されるレコードを含む。なお、レコードには、前述した以外のカラムが含まれてもよい。

申請番号５０１は、リリース申請を識別するための識別情報である。申請番号５０１は、プログラム統合管理情報２３０のレコードを識別するための識別情報としても用いられる。本実施例では、自動採番機能に基づいて算出された番号が申請番号５０１に設定される。

チケット番号５０２は、リリース申請の対象となるプログラムの開発タスクに割り当てられたチケットの識別番号である。チケット番号５０２には、チケット番号３０１に設定された識別情報が格納される。

リビジョン番号５０３は、リリース申請の対象となるプログラムのリビジョン番号である。リビジョン番号５０３には、リビジョン番号４０１に設定された識別情報が格納される。

申請者５０４は、リリース申請を行ったユーザの名称である。申請者５０４には、担当者３０５に設定された名称が格納される。なお、申請者５０４に設定される名称は、ユーザ情報から取得できる。

承認ステータス５０５は、リリース申請の承認の進捗状態を示す情報である。承認ステータス５０５には、「未」及び「済」のいずれかが格納される。

リリースステータス５０６は、リリースの進捗状態を示す情報である。リリースステータス５０６には、「未」、「対応中」、及び「済」のいずれかが格納される。なお、「対応中」は、リリースが行われている最中であることを示す。

チケット管理情報３００、開発リポジトリ管理情報４００、及びプログラム統合管理情報２３０は、テーブル形式の情報として説明したがこれに限定されない。ＣＳＶ形式等のデータ形式でもよい。

図６は、実施例１のサーバ間の入出力の一例を示す図である。図７Ａ、図７Ｂ、図７Ｃ、及び図７Ｄは、実施例１の計算機システムにおける処理の流れを説明するシーケンス図である。図８Ａ、図８Ｂ、図８Ｃ、及び図８Ｄは、実施例１の出力装置２５７に表示される画面の一例を示す図である。

図７Ａに示す処理の流れについて説明する。開発者は、結合試験又は統合試験においてプログラムの不良を検出した場合、開発者端末１１１を用いて、該当するプログラムの開発タスクを管理するためのチケットの登録指示をチケット管理サーバ１０１に送信する（ステップＳ７０１）。なお、登録指示には、担当チーム、担当者、及び期日等の情報が含まれる。

チケット管理サーバ１０１は、登録指示を受け付けた場合、チケット登録処理を実行する（ステップＳ７０２）。

具体的には、チケット管理サーバ１０１は、チケット管理情報３００にレコードを追加し、追加されたレコードのチケット番号３０１にチケット番号を設定する。また、チケット管理サーバ１０１は、追加されたレコードのステータス３０２、チケット内容３０３、担当チーム３０４、担当者３０５、及び期日３０６に値を設定する。

チケット管理サーバ１０１は、チケット登録処理が終了した後、開発者端末１１１に応答を送信する（ステップＳ７０３）。当該応答にはチケット番号等が含まれる。

開発者は、開発タスクの進捗に応じて、チケットの更新指示を開発者端末１１１を用いてチケット管理サーバ１０１に送信する（ステップＳ７０４）。当該更新指示には、ステータス３０２に設定する値及びチケット番号が含まれる。なお、更新指示には、他の情報が含まれてもよい。

チケット管理サーバ１０１は、更新指示を受け付けた場合、チケット更新処理を実行する（ステップＳ７０５）。

具体的には、チケット管理サーバ１０１は、チケット管理情報３００を参照して、チケット番号３０１が更新指示に含まれるチケット番号に一致するレコードを検索し、当該レコードのステータス３０２を更新する。

チケット管理サーバ１０１は、チケット更新処理が終了した後、開発者端末１１１に応答を送信する（ステップＳ７０６）。

開発者は、修正したプログラムの単体試験が完了し、再度、試験用の実行環境にプログラムをリリースできる状態になった場合、対応するチケットのステータス３０２を「リリース申請前」に更新する。その後、開発者は、開発者端末１１１を用いて、プログラムのコミット指示を開発リポジトリサーバ１０２に送信する（ステップＳ７０７）。コミット指示には、プログラム、及び当該プログラムの名称等が含まれる。

開発リポジトリサーバ１０２は、コミット指示を受け付けた場合、コミット処理を実行する（ステップＳ７０８）。

具体的には、開発リポジトリサーバ１０２は、開発リポジトリにプログラムを格納する。開発リポジトリサーバ１０２は、開発リポジトリ管理情報４００にレコードを追加し、追加されたレコードのリビジョン番号４０１にリビジョン番号を設定する。また、開発リポジトリサーバ１０２は、追加されたレコードのプログラム名４０２にコミット指示に含まれる値を設定し、また、プログラム格納パス４０３に開発リポジトリに格納されたプログラムのパスを設定する。また、開発リポジトリサーバ１０２は、追加されたレコードのコミットユーザ４０４に、ユーザ情報から取得した開発者の名称を設定する。

開発リポジトリサーバ１０２は、コミット処理が終了した後、開発者端末１１１に応答を送信する（ステップＳ７０９）。当該応答にはリビジョン番号が含まれる。

次に、図７Ｂに示す処理の流れについて説明する。開発者は、開発者端末１１１の出力装置２５７に表示されるリリース申請用画面８０１を操作して、リリース申請の指示をプログラム統合管理サーバ１０４に送信する（ステップＳ７１１）。

リリース申請用画面８０１は、リビジョン番号入力欄８１１、チケット番号入力欄８１２、及びリリース申請ボタン８１３を含む。なお、図８Ａの画面は一例であり、これに限定されない。開発者は、入力装置２５６を用いて、リビジョン番号入力欄８１１及びチケット番号入力欄８１２のそれぞれリビジョン番号及びチケット番号を設定し、リリース申請ボタン８１３を操作する。この場合、開発者端末１１１は、リビジョン番号及びチケット番号を含むリリース申請の指示をプログラム統合管理サーバ１０４に送信する。

プログラム統合管理サーバ１０４は、リリース申請の指示を受け付けた場合、チケット管理サーバ１０１にチケット確認処理の実行指示を送信し（ステップＳ７１２）、また、開発リポジトリサーバ１０２にプログラム確認処理の実行指示を送信する（ステップＳ７１５）。

具体的には、判定モジュール２２２が、チケット番号が含まれるチケット確認処理の実行指示を送信し、また、リビジョン番号が含まれるプログラム確認処理の実行指示を送信する。

チケット管理サーバ１０１は、チケット確認処理の実行指示を受け付けた場合、チケット確認処理を実行し（ステップＳ７１３）、実行結果を含む応答をプログラム統合管理サーバ１０４に送信する（ステップＳ７１４）。

具体的には、チケット管理サーバ１０１は、チケット管理情報３００を参照して、チケット番号３０１が実行指示に含まれるチケット番号に一致するレコードを検索する。前述の条件を満たすレコードが存在した場合、チケット管理サーバ１０１は、当該レコードのステータス３０２の値を実行結果としてプログラム統合管理サーバ１０４に送信する。前述の条件を満たすレコードが存在しなかった場合、チケット管理サーバ１０１は、エラーを示す実行結果をプログラム統合管理サーバ１０４に送信する。

開発リポジトリサーバ１０２は、プログラム確認処理の実行指示を受け付けた場合、プログラム確認処理を実行し（ステップＳ７１６）、実行結果を含む応答をプログラム統合管理サーバ１０４に送信する（ステップＳ７１７）。

具体的には、開発リポジトリサーバ１０２は、開発リポジトリ管理情報４００を参照して、リビジョン番号４０１が実行指示に含まれるリビジョン番号に一致するレコードを検索する。前述の条件を満たすレコードが存在した場合、開発リポジトリサーバ１０２は、当該レコードのプログラム名４０２の値を実行結果としてプログラム統合管理サーバ１０４に送信する。前述の条件を満たすレコードが存在しなかった場合、開発リポジトリサーバ１０２は、エラーを示す実行結果をプログラム統合管理サーバ１０４に送信する。

プログラム統合管理サーバ１０４は、チケット管理サーバ１０１及び開発リポジトリサーバ１０２から応答を受信した後、開発者に提示する表示情報を生成し、生成された表示情報を含む応答を開発者端末１１１に送信する（ステップＳ７１８）。表示情報には、例えば、チケット管理情報３００から取得したステータス３０２、及び開発リポジトリ管理情報４００から取得したプログラム名４０２が含まれる。開発者端末１１１は、応答に含まれる表示情報に基づいて出力装置２５７に画面を表示する。

開発者は、出力装置２５７に表示された画面を確認し、特に問題が無い場合、開発者端末１１１を用いて、プログラム統合管理サーバ１０４に申請内容確定の指示を送信する（ステップＳ７１９）。

プログラム統合管理サーバ１０４は、申請内容確定の指示を受け付けた場合、リリース申請を正式に受け付けたものとして、リリース申請及び開発タスクの対応関係をプログラム統合管理情報２３０に登録する。その後、プログラム統合管理サーバ１０４は、チケット管理サーバ１０１にチケット更新処理の実行指示を送信する（ステップＳ７２０）。

具体的には、登録モジュール２２３が、ステータス３０２に設定する値「リリース受付済」、及びチケット番号を含む実行指示を送信する。

チケット管理サーバ１０１は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する（ステップＳ７２１）。また、チケット管理サーバ１０１は、チケット更新処理が終了した後、プログラム統合管理サーバ１０４に応答を送信する（ステップＳ７２２）。

チケット更新処理では、チケット管理サーバ１０１は、チケット管理情報３００を参照して、チケット番号３０１が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス３０２を「リリース申請前」から「リリース受付済」に更新する。

プログラム統合管理サーバ１０４は、チケット管理サーバ１０１から応答を受け付けた場合、開発者端末１１１に応答を送信する（ステップＳ７２３）。

リリース申請時におけるプログラム統合管理サーバ１０４の処理の詳細は、図９を用いて説明する。

次に、図７Ｃに示す処理の流れについて説明する。承認者は、リリース申請の承認する場合、承認者端末１１２を用いてプログラム統合管理サーバ１０４に接続する。プログラム統合管理サーバ１０４は、承認者端末１１２からの接続を検出した場合、リリース申請を受けたプログラムの一覧である申請一覧を提示する（ステップＳ７３１）。具体的には、図８Ｂに示す承認用画面８０２が出力装置２５７に表示される。

承認用画面８０２は、申請番号８２２、リビジョン番号８２３、プログラム名８２４、チケット内容８２５、担当チーム８２６、及び担当者８２７を含む申請一覧８２１、承認ボタン８２８、並びに差戻しボタン８２９を含む。なお、図８Ｂの画面は一例であり、これに限定されない。例えば、申請一覧８２１に期日のカラムが含まれてもよい。

ここで、承認用画面８０２を表示するための処理について説明する。プログラム統合管理サーバ１０４は、プログラム統合管理情報２３０を参照し、承認ステータス５０５が「未」となっているレコードを検索する。プログラム統合管理サーバ１０４は、検索されたレコードのチケット番号５０２を含む問合せをチケット管理サーバ１０１に送信する。これによって、チケット内容３０３、担当チーム３０４、及び担当者３０５等の値を取得できる。また、プログラム統合管理サーバ１０４は、検索されたレコードのリビジョン番号５０３を含む問合せを開発リポジトリサーバ１０２に送信する。これによって、プログラム名４０２等の値を取得できる。プログラム統合管理サーバ１０４は、取得した値を用いて申請一覧８２１等を表示するための表示情報を作成し、リリース管理者端末１１３に当該表示情報を送信する。

まず、承認用画面８０２において承認ボタン８２８が操作された場合の処理の流れについて説明する。

承認者は、申請一覧８２１から許可するリリース申請を選択し、承認ボタン８２８を操作する。なお、選択するリリース申請の数は、一つでもよいし、また、複数でもよい。承認者端末１１２は、承認ボタン８２８が操作された場合、プログラム統合管理サーバ１０４に申請承認の指示を送信する（ステップＳ７３２）。当該指示には、申請番号が含まれる。

プログラム統合管理サーバ１０４は、申請承認の指示を受け付けた場合、開発リポジトリサーバ１０２にプログラムコピー処理の実行指示を送信する（ステップＳ７３３）。当該実行指示には、リビジョン番号が含まれる。なお、プログラム統合管理サーバ１０４は、申請承認の指示に含まれる申請番号に基づいてプログラム統合管理情報２３０を参照することによってリビジョン番号を取得できる。

開発リポジトリサーバ１０２は、プログラムコピー処理の実行指示を受け付けた場合、プログラムコピー処理を実行する（ステップＳ７３４）。また、開発リポジトリサーバ１０２は、プログラムコピー処理が終了した後、プログラム統合管理サーバ１０４に応答を送信する（ステップＳ７３５）。

具体的には、開発リポジトリサーバ１０２は、開発リポジトリ管理情報４００を参照し、リビジョン番号４０１が実行指示に含まれるリビジョン番号に一致するレコードを検索する。開発リポジトリサーバ１０２は、検索されたレコードのプログラム格納パス４０３に基づいて、開発リポジトリからリリース対象のプログラムを読み出し、リリースリポジトリサーバ１０３に当該プログラムを送信する。これによって、リリースリポジトリに、リリース対象のプログラムがコピーされる。本実施例では、リリースリポジトリに格納されるプログラムは、プログラムコピー処理によってのみ更新される。

なお、後述するように、プログラム統合管理サーバ１０４は、申請承認の指示を受け付けた場合、リリースステータス５０６が「対応中」であるレコードが存在するか否かを判定する。リリースステータス５０６が「対応中」であるレコードが存在する場合、プログラム統合管理サーバ１０４は、承認者端末１１２に承認処理が実行できない旨のメッセージを送信する。

プログラム統合管理サーバ１０４は、開発リポジトリサーバ１０２応答を受け付けた場合、チケット管理サーバ１０１にチケット更新処理の実行指示を送信する（ステップＳ７３６）。

具体的には、登録モジュール２２３が、ステータス３０２に設定する値「リリース待ち」、及び承認者によって選択されたリリース申請に対応するチケット番号を含む実行指示を送信する。なお、登録モジュール２２３は、申請番号に基づいてプログラム統合管理情報２３０を参照することによってチケット番号を取得できる。

チケット管理サーバ１０１は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する（ステップＳ７３７）。また、チケット管理サーバ１０１は、チケット更新処理が終了した後、プログラム統合管理サーバ１０４に応答を送信する（ステップＳ７３８）。

チケット更新処理では、チケット管理サーバ１０１は、チケット管理情報３００を参照して、チケット番号３０１が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス３０２を「リリース受付済」から「リリース待ち」に更新する。

プログラム統合管理サーバ１０４は、チケット管理サーバ１０１から応答を受け付けた場合、承認者端末１１２に応答を送信する（ステップＳ７３９）。

次に、承認用画面８０２において差戻しボタン８２９が操作された場合の処理の流れについて説明する。

承認者は、申請一覧８２１から差戻しを行うリリース申請を選択し、差戻しボタン８２９を操作する。なお、選択するリリース申請の数は、一つでもよいし、また、複数でもよい。承認者端末１１２は、差戻しボタン８２９が操作された場合、プログラム統合管理サーバ１０４に申請差戻しの指示を送信する（ステップＳ７４１）。当該指示には、申請番号が含まれる。

プログラム統合管理サーバ１０４は、申請差戻しの指示を受け付けた場合、チケット管理サーバ１０１にチケット更新処理の実行指示を送信する（ステップＳ７４２）。

具体的には、登録モジュール２２３が、ステータス３０２に設定する値「リリース申請前」、及び承認者によって選択されたリリース申請に対応するチケット番号を含む実行指示を送信する。なお、登録モジュール２２３は、申請番号に基づいてプログラム統合管理情報２３０を参照することによってチケット番号を取得できる。

チケット管理サーバ１０１は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する（ステップＳ７４３）。また、チケット管理サーバ１０１は、チケット更新処理が終了した後、プログラム統合管理サーバ１０４に応答を送信する（ステップＳ７４４）。

チケット更新処理では、チケット管理サーバ１０１は、チケット管理情報３００を参照して、チケット番号３０１が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス３０２を「リリース受付済」から「リリース申請前」に更新する。

プログラム統合管理サーバ１０４は、チケット管理サーバ１０１から応答を受け付けた場合、差戻されたリリース申請の指示を送信する開発者端末１１１に差戻し通知を送信する（ステップＳ７４５）。

具体的には、プログラム統合管理サーバ１０４は、ステップＳ７４２において取得されたチケット番号を含む問合せをチケット管理サーバ１０１に送信することによって、担当チーム３０４及び担当者３０５の値を取得する。プログラム統合管理サーバ１０４は、取得された値及びユーザ情報に基づいて、差戻し通知を送信する開発者を特定する。プログラム統合管理サーバ１０４は、特定された開発者が操作する開発者端末１１１に差戻し通知を送信する。

リリース申請の承認時におけるプログラム統合管理サーバ１０４の処理の詳細は、図１０を用いて説明する。

次に、図７Ｄに示す処理の流れについて説明する。リリース管理者は、リリースを開始する場合、リリース管理者端末１１３を用いてプログラム統合管理サーバ１０４に接続する。プログラム統合管理サーバ１０４は、リリース管理者端末１１３からの接続を検出した場合、画面を提示する（ステップＳ７５１）。具体的には、図８Ｃに示すリリース開始用画面８０３が出力装置２５７に表示される。

リリース開始用画面８０３は、申請番号８３２、チケット番号８３３、リビジョン番号８３４、及び申請者８３５を含む申請一覧８３１、リリース開始ボタン８３６、並びに作成ボタン８３７を含む。なお、図８Ｃの画面は一例であり、これに限定されない。

ここで、リリース開始用画面８０３を表示するための処理について説明する。プログラム統合管理サーバ１０４は、プログラム統合管理情報２３０を参照し、承認ステータス５０５が「済」かつリリースステータス５０６が「未」となっているレコードを検索する。プログラム統合管理サーバ１０４は、検索されたレコードに基づいて申請一覧８３１等を表示するための表示情報を作成し、リリース管理者端末１１３に当該表示情報を送信する。

リリース管理者は、申請一覧８３１からリリースを行うリリース申請を選択し、リリース開始ボタン８３６を操作する。なお、選択するリリース申請の数は、一つでもよいし、また、複数でもよい。リリース管理者端末１１３は、リリース開始ボタン８３６が操作された場合、プログラム統合管理サーバ１０４にリリースステータスの変更指示を送信する（ステップＳ７５２）。当該指示には、申請番号が含まれる。

プログラム統合管理サーバ１０４は、リリースステータスの変更指示を受け付けた場合、リリースステータス変更処理を実行する（ステップＳ７５３）。また、プログラム統合管理サーバ１０４は、リリースステータス変更処理が終了した後、リリース管理者端末１１３に応答を送信する（ステップＳ７５４）。

具体的には、プログラム統合管理サーバ１０４は、プログラム統合管理情報２３０を参照し、申請番号５０１がリリースステータスの変更指示に含まれる申請番号に一致するレコードを検索する。プログラム統合管理サーバ１０４は、検索されたレコードのリリースステータス５０６を「未」から「対応中」に更新する。

リリースステータス５０６が「対応中」であるレコードが一つ以上存在する場合、プログラム統合管理サーバ１０４は、承認者によるリリース申請の承認が行われないように制御する。なぜならば、リリース管理者によってリリースが行われている最中であるためである。

リリース管理者は、リリース作業を開始するために、リリース管理者端末１１３を操作して、リリース資材を作成する（ステップＳ７５５）。例えば、リリース管理者は、リリース管理者端末１１３を用いてリリースリポジトリに格納されるプログラムに対するビルドを実行することによって、リリース資材を作成する。リリース管理者は、結合試験又は統合試験を実行するために、実行環境にリリース資材をリリースする。

リリース管理者は、リリース資材のリリースが完了した後、リリースの完了を通知するために、リリース管理者端末１１３を用いてプログラム統合管理サーバ１０４に接続する。プログラム統合管理サーバ１０４は、リリース管理者端末１１３からの接続を検出した場合、画面を提示する（ステップＳ７５６）。具体的には、図８Ｄに示すリリース完了登録用画面８０４が出力装置２５７に表示される。

リリース完了登録用画面８０４は、申請番号８４２、チケット番号８４３、リビジョン番号８４４、及び申請者８４５を含む申請一覧８４１、並びにリリース完了ボタン８４６を含む。なお、図８Ｄの画面は一例であり、これに限定されない。

ここで、リリース完了登録用画面８０４を表示するための処理について説明する。プログラム統合管理サーバ１０４は、プログラム統合管理情報２３０を参照し、リリースステータス５０６が「対応中」であるレコードを検索する。プログラム統合管理サーバ１０４は、検索されたレコードに基づいて申請一覧８４１等を表示するための表示情報を作成し、リリース管理者端末１１３に当該表示情報を送信する。

リリース管理者は、申請一覧８４１を参照し、リリース内容に誤りが無いか否かを確認する。リリース管理者は、リリース内容に誤りが無いと判断した場合、リリース完了ボタン８４６を操作する。リリース管理者端末１１３は、リリース完了ボタン８４６が操作された場合、プログラム統合管理サーバ１０４にリリース完了の登録指示を送信する（ステップＳ７５７）。

プログラム統合管理サーバ１０４は、リリース完了の登録指示を受け付けた場合、チケット管理サーバ１０１にチケット更新処理の実行指示を送信する（ステップＳ７５８）。

具体的には、登録モジュール２２３は、プログラム統合管理情報２３０を参照し、ステップＳ７５２においてリリースステータス５０６が「対応中」に更新されたレコードを検索する。登録モジュール２２３は、ステータス３０２に設定する値「リリース済」、及び検索されたレコードのチケット番号５０２を含む実行指示を送信する。

チケット管理サーバ１０１は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する（ステップＳ７５９）。また、チケット管理サーバ１０１は、チケット更新処理が終了した後、プログラム統合管理サーバ１０４に応答を送信する（ステップＳ７６０）。

チケット更新処理では、チケット管理サーバ１０１は、チケット管理情報３００を参照して、チケット番号３０１が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス３０２を「リリース待ち」から「リリース済」に更新する。

プログラム統合管理サーバ１０４は、チケット管理サーバ１０１から応答を受け付けた場合、プログラム統合管理情報２３０を更新し、また、開発者端末１１１にリリース完了通知を送信する（ステップＳ７６１）。なお、リリース完了通知には、申請番号が含まれる。

具体的には、プログラム統合管理サーバ１０４は、プログラム統合管理情報２３０を参照し、ステップＳ７５２においてリリースステータス５０６が「対応中」に更新されたレコードを検索し、当該レコードのリリースステータス５０６を「済」に更新する。

なお、プログラム統合管理サーバ１０４は、全ての開発者にリリース完了通知を送信してもよいし、リリースされたプログラムを開発した開発者にリリース完了通知を送信してもよい。

なお、プログラム統合管理サーバ１０４は、ユーザ情報を用いて、開発者、承認者、及びリリース管理者を区別し、各ユーザに割り当てられた権限に応じて、受付可能な操作を制御する。例えば、プログラム統合管理サーバ１０４は、承認者のみがリリース申請の承認を行えるように制御し、また、リリース管理者のみがリリースの開始及びリリースの完了を行えるように制御する。

図９は、実施例１のプログラム統合管理サーバ１０４がリリース申請の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。

プログラム統合管理サーバ１０４は、リリース申請の指示を受け付けた場合、以下の処理を実行する。

リリース申請の指示を受け付けた入出力モジュール２２１によって呼び出された判定モジュール２２２は、チケット番号が含まれるチケット確認処理の実行指示をチケット管理サーバ１０１に送信し、また、リビジョン番号が含まれるプログラム確認処理の実行指示を開発リポジトリサーバ１０２に送信する（ステップＳ９０１）。

具体的には、判定モジュール２２２は、入出力モジュール２２１に各実行指示の送信を指示する。判定モジュール２２２は、チケット管理サーバ１０１及び開発リポジトリサーバ１０２から応答を受け付けるまで待ち状態に移行する。

チケット管理サーバ１０１及び開発リポジトリサーバ１０２から応答を受け付けた場合、判定モジュール２２２は、エラーを示す実行結果を含む応答を受け付けたか否かを判定する（ステップＳ９０２）。二つの応答のうち、少なくとも一つの応答にエラーを示す実行結果が含まれる場合、判定モジュール２２２は、エラーを示す実行結果を含む応答を受け付けたと判定する。

エラーを示す実行結果を含む応答を受け付けたと判定された場合、判定モジュール２２２は、エラーメッセージを含む応答を開発者端末１１１に送信する（ステップＳ９０９）。その後、統合管理モジュール２２０は、処理を終了する。

エラーを示す実行結果を含む応答を受け付けていないと判定された場合、判定モジュール２２２は、リリース申請に関連するチケットのステータス３０２が「リリース申請前」であるか否かを判定する（ステップＳ９０３）。

具体的には、判定モジュール２２２は、チケット管理サーバ１０１から受信した応答に含まれるステータス３０２が「リリース申請前」であるか否かを判定する。なお、複数のプログラムに対するリリース申請を行う場合、全てのプログラムに対応するステータス３０２が「リリース申請前」であるか否かが判定される。

リリース申請に関連するチケットのステータス３０２が「リリース申請前」ではないと判定された場合、判定モジュール２２２は、エラーメッセージを含む応答を開発者端末１１１に送信する（ステップＳ９０９）。その後、統合管理モジュール２２０は、処理を終了する。

リリース申請に関連するチケットのステータス３０２が「リリース申請前」であると判定された場合、判定モジュール２２２は、表示情報を含む応答を開発者端末１１１に送信する（ステップＳ９０４）。

統合管理モジュール２２０は、申請内容確定の指示を受け付けたか否かを判定する（ステップＳ９０５）。例えば、統合管理モジュール２２０は、表示情報を含む応答を送信した後一定期間内に申請内容確定の指示を受け付けていない場合、申請内容確定指示を受け付けていないと判定する。

申請内容確定指示を受け付けていないと判定された場合、統合管理モジュール２２０は、処理を終了する。

申請内容確定指示を受け付けたと判定された場合、統合管理モジュール２２０は、登録モジュール２２３を呼び出す。登録モジュール２２３は、プログラム統合管理情報２３０を更新する（ステップＳ９０６）。

具体的には、登録モジュール２２３は、プログラム統合管理情報２３０にレコードを追加し、追加されたレコードの申請番号５０１に識別番号を設定する。登録モジュール２２３は、追加されたレコードのチケット番号５０２及びリビジョン番号５０３に、リリース申請に含まれるチケット番号及びリビジョン番号を設定する。登録モジュール２２３は、追加されたレコードの申請者５０４にチケット管理サーバ１０１から受け付けた応答に含まれる担当者３０５の値を設定する。さらに、登録モジュール２２３は、追加されたレコードの承認ステータス５０５及びリリースステータス５０６に「未」を設定する。

ステップＳ９０６の処理によって、リリース申請、プログラムの開発タスク、及び開発リポジトリに格納されるプログラムを関連付けて管理することができる。

登録モジュール２２３は、ステータス３０２に設定する値「リリース受付済」、及びチケット番号を含むチケット更新処理の実行指示を、チケット管理サーバ１０１に送信する（ステップＳ９０７）。

統合管理モジュール２２０は、チケット管理サーバ１０１から応答を受け付けた場合、開発者端末１１１に応答を送信する（ステップＳ９０８）。その後、統合管理モジュール２２０は、処理を終了する。

図１０は、実施例１のプログラム統合管理サーバ１０４が申請承認の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。

プログラム統合管理サーバ１０４は、承認者端末１１２からの接続を検出した場合、以下の処理を実行する。

承認者端末１１２からの接続を検出した入出力モジュール２２１によって呼び出されたコピー実行モジュール２２４は、プログラム統合管理情報２３０を参照し、リリースステータス５０６が「対応中」であるレコードが存在するか否か判定する（ステップＳ１００１）。

リリースステータス５０６が「対応中」であるレコードが存在すると判定された場合、コピー実行モジュール２２４は、承認者端末１１２に、リリース中であるため承認処理を実行できない旨を示すメッセージを送信する（ステップＳ１００８）。その後、統合管理モジュール２２０は、処理を終了する。

ステップＳ１００８の処理は、リリースの最中にリリース申請の承認が行われないように制御するために行われる。したがって、本実施例では、リリースされるプログラム及びリリース申請の対象となるプログラムが異なる場合であっても、承認が行われない。これによって、別々のリリース資材としてリリースされるプログラムが混在することを防ぐことができる。

リリースステータス５０６が「対応中」であるレコードが存在しないと判定された場合、コピー実行モジュール２２４は、開発リポジトリに名称が一致するプログラムが存在するか否かを判定する（ステップＳ１００２）。すなわち、リビジョン番号４０１が異なり、かつ、プログラム名４０２が同一であるレコードが存在するか否かが判定される。

具体的には、コピー実行モジュール２２４は、プログラム統合管理情報２３０の各レコードのリビジョン番号５０３を含むプログラム名の問合せを開発リポジトリサーバ１０２に送信する。コピー実行モジュール２２４は、開発リポジトリサーバ１０２から取得したプログラム名に基づいて、名称が一致するプログラムが存在するか否かを判定する。

開発リポジトリに名称が一致するプログラムが存在すると判定された場合、コピー実行モジュール２２４は、承認者端末１１２に、エラーメッセージを送信する（ステップＳ１００９）。その後、統合管理モジュール２２０は、処理を終了する。当該エラーメッセージには、リビジョン番号、プログラム名、及び申請者が含まれる。

一般的に、複数の開発者によってリリースされたプログラムを結合して一つの結合試験又は総合試験が行われる。したがって、リビジョン番号が異なる同一プログラムが開発リポジトリに存在する場合、どちらのプログラムをリリース資材に含めるかを決定する必要がある。そこで、本実施例では、前述したようなプログラムのコンフリクトが発生した場合、承認者に関係者間の調整を促すためのエラーメッセージを送信する。これによって、関係者間で速やかに調整が行われ、リリースの可否及びリリースするプログラムを決定することができる。

開発リポジトリに名称が一致するプログラムが存在しないと判定された場合、コピー実行モジュール２２４は、申請一覧を提示する（ステップＳ１００３）。

コピー実行モジュール２２４は、申請承認の指示を受け付けたか否かを判定する（ステップＳ１００４）。

申請承認の指示を受け付けたと判定された場合、コピー実行モジュール２２４は、開発リポジトリサーバ１０２にプログラムコピー処理の実行指示を送信する（ステップＳ１００５）。

コピー実行モジュール２２４は、開発リポジトリサーバ１０２から応答を受け付けた場合、登録モジュール２２３を呼び出す。登録モジュール２２３は、ステータス３０２に設定する値「リリース待ち」、及び承認者によって選択された申請番号に対応するチケット番号を含む実行指示を、チケット管理サーバ１０１に送信する（ステップＳ１００６）。

登録モジュール２２３は、プログラム統合管理情報２３０を更新する（ステップＳ１００７）。

具体的には、登録モジュール２２３は、プログラム統合管理情報２３０を参照し、ステップＳ１００４において選択されたレコードの承認ステータス５０５に「済」を設定する。

ステップＳ１００４において、申請差戻しの指示を受け付けたと判定された場合、コピー実行モジュール２２４は、登録モジュール２２３を呼び出す。登録モジュール２２３は、ステータス３０２に設定する値「リリース申請前」、及び承認者によって選択された申請番号に対応するチケット番号を含む実行指示を、チケット管理サーバ１０１に送信する（ステップＳ１０１０）。

登録モジュール２２３は、チケット管理サーバ１０１から応答を受け付けた場合、差戻されたリリース申請を行った開発者端末１１１に差戻し通知を送信する（ステップＳ１０１１）。その後、統合管理モジュール２２０は、処理を終了する。

本実施例によれば、リリース申請及び開発タスクが関連付けて管理されるため、開発タスク及びリリース申請が連携するようにプログラムのリリースにおける各種操作を制御することができる。これによって、開発者等の操作ミス及び判断ミス等に起因するリリースの誤りを防ぐことができため、試験工程が円滑に進行できる。

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

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるＣＰＵが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、コンピュータが備えるＣＰＵが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

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

１０１ チケット管理サーバ
１０２ 開発リポジトリサーバ
１０３ リリースリポジトリサーバ
１０４ プログラム統合管理サーバ
１１１ 開発者端末
１１２ 承認者端末
１１３ リリース管理者端末
２１１、２５１ ＣＰＵ
２１２、２５２ メモリ
２１３ 記憶装置
２１４、２５３ ＮＷ Ｉ／Ｆ
２１５、２５５ データバス
２２０ 統合管理モジュール
２２１ 入出力モジュール
２２２ 判定モジュール
２２３ 登録モジュール
２２４ コピー実行モジュール
２３０ プログラム統合管理情報
２５４ ＩＯ Ｉ／Ｆ
２５６ 入力装置
２５７ 出力装置
３００ チケット管理情報
４００ 開発リポジトリ管理情報
６０１、６０２、６０３ 制御モジュール

Claims (14)

1. 複数の計算機を備える計算機システムであって、
   前記計算機システムは、開発対象のプログラムを格納する第１のリポジトリと、実行環境にリリースするプログラムを格納する第２のリポジトリと、を含み、
   前記複数の計算機の少なくとも一つの計算機は、
   プログラムの開発タスクに割り当てられるチケット番号、及び前記プログラムの開発タスクの進捗状態から構成されるレコードを含むチケット管理情報と、
   前記第１のリポジトリに格納されるプログラムに割り当てられるリビジョン番号、及び前記プログラムの名称から構成されるレコードを含むリポジトリ管理情報と、を保持し、
   前記実行環境への前記第２のリポジトリに格納されるプログラムのリリースを制御する統合管理モジュールを有し、
   前記統合管理モジュールは、
   前記開発対象のプログラムを前記実行環境にリリースするための操作であるリリース申請を識別するための申請番号、前記チケット番号、及び前記リビジョン番号から構成されるレコードを含む統合管理情報を管理し、
   第１のプログラムに割り当てられた第１のリビジョン番号及び前記第１のプログラムの開発タスクに割り当てられた第１のチケット番号を含む第１のリリース申請を受け付けた場合、前記第１のリリース申請の申請番号、前記第１のチケット番号、及び前記第１のリビジョン番号から構成される第１のレコードを前記統合管理情報に追加し、
   前記第１のリリース申請の識別情報を含む、前記第１のリリース申請を許可するための操作である第１の承認を受け付けた場合、前記第１の承認を行えるか否かを判定し、
   前記第１の承認を行えると判定された場合、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって前記第１のプログラムを取得し、前記第１のプログラムを前記第２のリポジトリに格納し、
   前記統合管理情報に基づいて前記チケット管理情報にアクセスすることによって前記第１のプログラムの開発タスクの進捗状態をリリースが完了したことを示す値に更新することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記第１のリリース申請を受け付けた場合、前記第１のリリース申請に含まれる前記第１のチケット番号に基づいて、前記チケット管理情報から前記第１のプログラムの開発タスクの進捗状態を取得し、
   前記第１のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であるか否かを判定し、
   前記第１のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であると判定された場合、前記第１のレコードを前記統合管理情報に追加することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記統合管理情報に含まれるレコードは、リリースの進捗状態を示すリリース状態を含み、
   前記統合管理モジュールは、
   前記第１のレコードを追加する場合に、前記リリース状態にリリースが完了していないことを示す値を設定し、
   前記リリース状態に現在リリースが行われていることを示す値が設定されたレコードが前記統合管理情報に存在すると判定された場合、前記第１の承認を行えないと判定することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記統合管理モジュールは、
   前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって、前記第１のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第１のプログラムの名称と同一の名称であるプログラムが前記第１のリポジトリに格納されているか否かを判定し、
   前記第１のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第１のプログラムの名称と同一の名称であるプログラムが前記第１のリポジトリに格納されていると判定された場合、前記第１の承認を行えないと判定することを特徴とする計算機システム。
5. 請求項４に記載の計算機システムであって、
   前記統合管理モジュールは、
   前記第１の承認を行えないと判定された場合、前記第１の承認を行えない原因を提示するための第１の表示情報を生成し、
   前記第１の承認の可否を判断するユーザが使用する計算機に前記第１の表示情報を送信することを特徴とする計算機システム。
6. 請求項４に記載の計算機システムであって、
   前記統合管理情報に含まれるレコードは、前記リリース申請に対する承認の進捗状態を示す承認状態を含み、
   前記統合管理モジュールは、
   前記承認状態に前記承認が行われていないことを示す値が設定されたレコードを提示する承認用画面を表示するための第２の表示情報を生成して、前記第１の承認の可否を判断するユーザが使用する計算機に前記第２の表示情報を送信し、
   前記第２のリポジトリに前記第１のプログラムが登録された場合、前記第１のレコードの前記承認状態を、前記承認が行われたことを示す値に更新し、
   前記承認状態に前記承認が行われたことを示す値、及び前記リリース状態にリリースが完了していないことを示す値が設定されたレコードを提示するためのリリース開始用画面を表示するための第３の表示情報を生成して、前記第１の承認が行われた前記第１のプログラムのリリースの可否を判断するユーザが使用する計算機に前記第３の表示情報を送信し、
   前記第１の承認が行われた前記第１のリリース申請に基づくリリースを開始する場合、前記第１のレコードの前記リリース状態を、前記リリースの最中であることを示す値に更新し、
   前記第２のリポジトリに格納された前記第１のプログラムが前記実行環境にリリースされた後、前記第１のレコードの前記リリース状態を、リリースが完了したことを示す値に更新することを特徴とする計算機システム。
7. 請求項２に記載の計算機システムであって、
   前記統合管理モジュールは、
   前記第１のレコードが前記統合管理情報に追加された後、前記第１のチケット番号に基づいて前記チケット管理情報にアクセスし、
   前記第１のチケット番号に対応するレコードの前記プログラムの開発タスクの進捗状態を、前記リリース申請を受け付けたことを示す値に更新することを特徴とする計算機システム。
8. 複数の計算機を備える計算機システムにおけるプログラムのリリース管理方法であって、
   前記計算機システムは、開発対象のプログラムを格納する第１のリポジトリと、実行環境にリリースするプログラムを格納する第２のリポジトリと、を含み、
   前記複数の計算機の少なくとも一つの計算機は、
   プログラムの開発タスクに割り当てられるチケット番号、及び前記プログラムの開発タスクの進捗状態から構成されるレコードを含むチケット管理情報と、
   前記第１のリポジトリに格納されるプログラムに割り当てられるリビジョン番号、及び前記プログラムの名称から構成されるレコードを含むリポジトリ管理情報と、を保持し、
   前記実行環境への前記第２のリポジトリに格納されるプログラムのリリースを制御する統合管理モジュールを有し、
   前記統合管理モジュールは、前記開発対象のプログラムを前記実行環境にリリースするための操作であるリリース申請を識別するための申請番号、前記チケット番号、及び前記リビジョン番号から構成されるレコードを含む統合管理情報を管理し、
   前記リリース管理方法は、
   前記統合管理モジュールが、第１のプログラムに割り当てられた第１のリビジョン番号及び前記第１のプログラムの開発タスクに割り当てられた第１のチケット番号を含む第１のリリース申請を受け付けた場合、前記第１のリリース申請の申請番号、前記第１のチケット番号、及び前記第１のリビジョン番号から構成される第１のレコードを前記統合管理情報に追加する第１のステップと、
   前記統合管理モジュールが、前記第１のリリース申請の識別情報を含む、前記第１のリリース申請を許可するための操作である第１の承認を受け付けた場合、前記第１の承認を行えるか否かを判定する第２のステップと、
   前記統合管理モジュールが、前記第１の承認を行えると判定された場合、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって前記第１のプログラムを取得し、前記第１のプログラムを前記第２のリポジトリに格納する第３のステップと、
   前記統合管理モジュールが、前記統合管理情報に基づいて前記チケット管理情報にアクセスすることによって前記第１のプログラムの開発タスクの進捗状態をリリースが完了したことを示す値に更新する第４のステップと、を含むことを特徴とするプログラムのリリース管理方法。
9. 請求項８に記載のプログラムのリリース管理方法であって、
   前記第１のステップは、
   前記統合管理モジュールが、前記第１のリリース申請に含まれる前記第１のチケット番号に基づいて、前記チケット管理情報から前記第１のプログラムの開発タスクの進捗状態を取得するステップと、
   前記統合管理モジュールが、前記第１のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であるか否かを判定するステップと、
   前記統合管理モジュールが、前記第１のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であると判定された場合、前記第１のレコードを前記統合管理情報に追加するステップと、を含むことを特徴とするプログラムのリリース管理方法。
10. 請求項９に記載のプログラムのリリース管理方法であって、
    前記統合管理情報に含まれるレコードは、リリースの進捗状態を示すリリース状態を含み、
    前記第１のステップは、前記統合管理モジュールが、前記第１のレコードの前記リリース状態にリリースが完了していないことを示す値を設定するステップを含み、
    前記第２のステップは、
    前記統合管理モジュールが、前記リリース状態に現在リリースが行われていることを示す値が設定されたレコードが前記統合管理情報に存在するか否かを判定するステップと、
    前記統合管理モジュールが、前記リリース状態に現在リリースが行われていることを示す値が設定されたレコードが前記統合管理情報に存在すると判定された場合、前記第１の承認を行えないと判定するステップと、を含むことを特徴とするプログラムのリリース管理方法。
11. 請求項１０に記載のプログラムのリリース管理方法であって、
    前記第２のステップは、
    前記統合管理モジュールが、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって、前記第１のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第１のプログラムの名称と同一の名称であるプログラムが前記第１のリポジトリに格納されているか否かを判定するステップと、
    前記統合管理モジュールが、前記第１のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第１のプログラムの名称と同一の名称であるプログラムが前記第１のリポジトリに格納されていると判定された場合、前記第１の承認を行えないと判定するステップと、を含むことを特徴とするプログラムのリリース管理方法。
12. 請求項１１に記載のプログラムのリリース管理方法であって、
    前記統合管理モジュールが、前記第１の承認を行えないと判定された場合、前記第１の承認を行えない原因を提示するための第１の表示情報を生成するステップと、
    前記統合管理モジュールが、前記第１の承認の可否を判断するユーザが使用する計算機に前記第１の表示情報を送信するステップと、を含むことを特徴とするプログラムのリリース管理方法。
13. 請求項１１に記載のプログラムのリリース管理方法であって、
    前記統合管理情報に含まれるレコードは、前記リリース申請に対する承認の進捗状態を示す承認状態を含み、
    前記第３のステップは、前記統合管理モジュールが、前記第１のレコードの前記承認状態を、前記承認が行われたことを示す値に更新するステップを含み、
    前記プログラムのリリース管理方法は、
    前記統合管理モジュールが、前記承認状態に前記承認が行われていないことを示す値が設定されたレコードを提示する承認用画面を表示するための第２の表示情報を生成して、前記第１の承認の可否を判断するユーザが使用する計算機に前記第２の表示情報を送信するステップと、
    前記統合管理モジュールが、前記承認状態に前記承認が行われたことを示す値、及び前記リリース状態にリリースが完了していないことを示す値が設定されたレコードを提示するためのリリース開始用画面を表示するための第３の表示情報を生成して、前記第１の承認が行われた前記第１のプログラムのリリースの可否を判断するユーザが使用する計算機に前記第３の表示情報を送信するステップと、
    前記統合管理モジュールが、前記第１の承認が行われた前記第１のリリース申請に基づくリリースを開始する場合、前記第１のレコードの前記リリース状態を、前記リリースの最中であることを示す値に更新するステップと、
    前記統合管理モジュールが、前記第２のリポジトリに格納された前記第１のプログラムが前記実行環境にリリースされた後、前記第１のレコードの前記リリース状態を、リリースが完了したことを示す値に更新するステップと、を含むことを特徴とするプログラムのリリース管理方法。
14. 請求項９に記載のプログラムのリリース管理方法であって、
    前記第１のステップは、
    前記統合管理モジュールが、前記第１のレコードが前記統合管理情報に追加された後、前記第１のチケット番号に基づいて前記チケット管理情報にアクセスするステップと、
    前記統合管理モジュールが、前記第１のチケット番号に対応するレコードの前記プログラムの開発タスクの進捗状態を、前記リリース申請を受け付けたことを示す値に更新するステップと、を含むことを特徴とするプログラムのリリース管理方法。

Images