特許第6960216号(P6960216)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

特許6960216計算機システム及びプログラムのリリース管理方法
<>
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000002
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000003
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000004
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000005
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000006
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000007
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000008
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000009
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000010
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000011
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000012
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000013
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000014
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000015
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000016
  • 特許6960216-計算機システム及びプログラムのリリース管理方法 図000017
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6960216
(24)【登録日】2021年10月13日
(45)【発行日】2021年11月5日
(54)【発明の名称】計算機システム及びプログラムのリリース管理方法
(51)【国際特許分類】
   G06F 8/70 20180101AFI20211025BHJP
【FI】
   G06F8/70
【請求項の数】14
【全頁数】28
(21)【出願番号】特願2016-200783(P2016-200783)
(22)【出願日】2016年10月12日
(65)【公開番号】特開2018-63520(P2018-63520A)
(43)【公開日】2018年4月19日
【審査請求日】2019年9月11日
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001678
【氏名又は名称】特許業務法人藤央特許事務所
(72)【発明者】
【氏名】藤原 知也
(72)【発明者】
【氏名】安部 哲朗
【審査官】 渡辺 順哉
(56)【参考文献】
【文献】 特開2016−076181(JP,A)
【文献】 特開2011−065495(JP,A)
【文献】 特開2005−284594(JP,A)
【文献】 特開2006−099452(JP,A)
【文献】 特開2002−312169(JP,A)
【文献】 特開平04−080822(JP,A)
【文献】 米国特許第05907705(US,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 8/00−8/77
G06F 9/44−9/445
(57)【特許請求の範囲】
【請求項1】
複数の計算機を備える計算機システムであって、
前記計算機システムは、開発対象のプログラムを格納する第1のリポジトリと、実行環境にリリースするプログラムを格納する第2のリポジトリと、を含み、
前記複数の計算機の少なくとも一つの計算機は、
プログラムの開発タスクに割り当てられるチケット番号、及び前記プログラムの開発タスクの進捗状態から構成されるレコードを含むチケット管理情報と、
前記第1のリポジトリに格納されるプログラムに割り当てられるリビジョン番号、及び前記プログラムの名称から構成されるレコードを含むリポジトリ管理情報と、を保持し、
前記実行環境への前記第2のリポジトリに格納されるプログラムのリリースを制御する統合管理モジュールを有し、
前記統合管理モジュールは、
前記開発対象のプログラムを前記実行環境にリリースするための操作であるリリース申請を識別するための申請番号、前記チケット番号、及び前記リビジョン番号から構成されるレコードを含む統合管理情報を管理し、
第1のプログラムに割り当てられた第1のリビジョン番号及び前記第1のプログラムの開発タスクに割り当てられた第1のチケット番号を含む第1のリリース申請を受け付けた場合、前記第1のリリース申請の申請番号、前記第1のチケット番号、及び前記第1のリビジョン番号から構成される第1のレコードを前記統合管理情報に追加し、
前記第1のリリース申請の識別情報を含む、前記第1のリリース申請を許可するための操作である第1の承認を受け付けた場合、前記第1の承認を行えるか否かを判定し、
前記第1の承認を行えると判定された場合、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって前記第1のプログラムを取得し、前記第1のプログラムを前記第2のリポジトリに格納し、
前記統合管理情報に基づいて前記チケット管理情報にアクセスすることによって前記第1のプログラムの開発タスクの進捗状態をリリースが完了したことを示す値に更新することを特徴とする計算機システム。
【請求項2】
請求項1に記載の計算機システムであって、
前記第1のリリース申請を受け付けた場合、前記第1のリリース申請に含まれる前記第1のチケット番号に基づいて、前記チケット管理情報から前記第1のプログラムの開発タスクの進捗状態を取得し、
前記第1のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であるか否かを判定し、
前記第1のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であると判定された場合、前記第1のレコードを前記統合管理情報に追加することを特徴とする計算機システム。
【請求項3】
請求項2に記載の計算機システムであって、
前記統合管理情報に含まれるレコードは、リリースの進捗状態を示すリリース状態を含み、
前記統合管理モジュールは、
前記第1のレコードを追加する場合に、前記リリース状態にリリースが完了していないことを示す値を設定し、
前記リリース状態に現在リリースが行われていることを示す値が設定されたレコードが前記統合管理情報に存在すると判定された場合、前記第1の承認を行えないと判定することを特徴とする計算機システム。
【請求項4】
請求項3に記載の計算機システムであって、
前記統合管理モジュールは、
前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって、前記第1のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第1のプログラムの名称と同一の名称であるプログラムが前記第1のリポジトリに格納されているか否かを判定し、
前記第1のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第1のプログラムの名称と同一の名称であるプログラムが前記第1のリポジトリに格納されていると判定された場合、前記第1の承認を行えないと判定することを特徴とする計算機システム。
【請求項5】
請求項4に記載の計算機システムであって、
前記統合管理モジュールは、
前記第1の承認を行えないと判定された場合、前記第1の承認を行えない原因を提示するための第1の表示情報を生成し、
前記第1の承認の可否を判断するユーザが使用する計算機に前記第1の表示情報を送信することを特徴とする計算機システム。
【請求項6】
請求項4に記載の計算機システムであって、
前記統合管理情報に含まれるレコードは、前記リリース申請に対する承認の進捗状態を示す承認状態を含み、
前記統合管理モジュールは、
前記承認状態に前記承認が行われていないことを示す値が設定されたレコードを提示する承認用画面を表示するための第2の表示情報を生成して、前記第1の承認の可否を判断するユーザが使用する計算機に前記第2の表示情報を送信し、
前記第2のリポジトリに前記第1のプログラムが登録された場合、前記第1のレコードの前記承認状態を、前記承認が行われたことを示す値に更新し、
前記承認状態に前記承認が行われたことを示す値、及び前記リリース状態にリリースが完了していないことを示す値が設定されたレコードを提示するためのリリース開始用画面を表示するための第3の表示情報を生成して、前記第1の承認が行われた前記第1のプログラムのリリースの可否を判断するユーザが使用する計算機に前記第3の表示情報を送信し、
前記第1の承認が行われた前記第1のリリース申請に基づくリリースを開始する場合、前記第1のレコードの前記リリース状態を、前記リリースの最中であることを示す値に更新し、
前記第2のリポジトリに格納された前記第1のプログラムが前記実行環境にリリースされた後、前記第1のレコードの前記リリース状態を、リリースが完了したことを示す値に更新することを特徴とする計算機システム。
【請求項7】
請求項2に記載の計算機システムであって、
前記統合管理モジュールは、
前記第1のレコードが前記統合管理情報に追加された後、前記第1のチケット番号に基づいて前記チケット管理情報にアクセスし、
前記第1のチケット番号に対応するレコードの前記プログラムの開発タスクの進捗状態を、前記リリース申請を受け付けたことを示す値に更新することを特徴とする計算機システム。
【請求項8】
複数の計算機を備える計算機システムにおけるプログラムのリリース管理方法であって、
前記計算機システムは、開発対象のプログラムを格納する第1のリポジトリと、実行環境にリリースするプログラムを格納する第2のリポジトリと、を含み、
前記複数の計算機の少なくとも一つの計算機は、
プログラムの開発タスクに割り当てられるチケット番号、及び前記プログラムの開発タスクの進捗状態から構成されるレコードを含むチケット管理情報と、
前記第1のリポジトリに格納されるプログラムに割り当てられるリビジョン番号、及び前記プログラムの名称から構成されるレコードを含むリポジトリ管理情報と、を保持し、
前記実行環境への前記第2のリポジトリに格納されるプログラムのリリースを制御する統合管理モジュールを有し、
前記統合管理モジュールは、前記開発対象のプログラムを前記実行環境にリリースするための操作であるリリース申請を識別するための申請番号、前記チケット番号、及び前記リビジョン番号から構成されるレコードを含む統合管理情報を管理し、
前記リリース管理方法は、
前記統合管理モジュールが、第1のプログラムに割り当てられた第1のリビジョン番号及び前記第1のプログラムの開発タスクに割り当てられた第1のチケット番号を含む第1のリリース申請を受け付けた場合、前記第1のリリース申請の申請番号、前記第1のチケット番号、及び前記第1のリビジョン番号から構成される第1のレコードを前記統合管理情報に追加する第1のステップと、
前記統合管理モジュールが、前記第1のリリース申請の識別情報を含む、前記第1のリリース申請を許可するための操作である第1の承認を受け付けた場合、前記第1の承認を行えるか否かを判定する第2のステップと、
前記統合管理モジュールが、前記第1の承認を行えると判定された場合、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって前記第1のプログラムを取得し、前記第1のプログラムを前記第2のリポジトリに格納する第3のステップと、
前記統合管理モジュールが、前記統合管理情報に基づいて前記チケット管理情報にアクセスすることによって前記第1のプログラムの開発タスクの進捗状態をリリースが完了したことを示す値に更新する第4のステップと、を含むことを特徴とするプログラムのリリース管理方法。
【請求項9】
請求項8に記載のプログラムのリリース管理方法であって、
前記第1のステップは、
前記統合管理モジュールが、前記第1のリリース申請に含まれる前記第1のチケット番号に基づいて、前記チケット管理情報から前記第1のプログラムの開発タスクの進捗状態を取得するステップと、
前記統合管理モジュールが、前記第1のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であるか否かを判定するステップと、
前記統合管理モジュールが、前記第1のプログラムの開発タスクの進捗状態がリリース申請が可能であることを示す値であると判定された場合、前記第1のレコードを前記統合管理情報に追加するステップと、を含むことを特徴とするプログラムのリリース管理方法。
【請求項10】
請求項9に記載のプログラムのリリース管理方法であって、
前記統合管理情報に含まれるレコードは、リリースの進捗状態を示すリリース状態を含み、
前記第1のステップは、前記統合管理モジュールが、前記第1のレコードの前記リリース状態にリリースが完了していないことを示す値を設定するステップを含み、
前記第2のステップは、
前記統合管理モジュールが、前記リリース状態に現在リリースが行われていることを示す値が設定されたレコードが前記統合管理情報に存在するか否かを判定するステップと、
前記統合管理モジュールが、前記リリース状態に現在リリースが行われていることを示す値が設定されたレコードが前記統合管理情報に存在すると判定された場合、前記第1の承認を行えないと判定するステップと、を含むことを特徴とするプログラムのリリース管理方法。
【請求項11】
請求項10に記載のプログラムのリリース管理方法であって、
前記第2のステップは、
前記統合管理モジュールが、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって、前記第1のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第1のプログラムの名称と同一の名称であるプログラムが前記第1のリポジトリに格納されているか否かを判定するステップと、
前記統合管理モジュールが、前記第1のプログラムのリビジョン番号と異なるリビジョン番号であり、かつ、前記第1のプログラムの名称と同一の名称であるプログラムが前記第1のリポジトリに格納されていると判定された場合、前記第1の承認を行えないと判定するステップと、を含むことを特徴とするプログラムのリリース管理方法。
【請求項12】
請求項11に記載のプログラムのリリース管理方法であって、
前記統合管理モジュールが、前記第1の承認を行えないと判定された場合、前記第1の承認を行えない原因を提示するための第1の表示情報を生成するステップと、
前記統合管理モジュールが、前記第1の承認の可否を判断するユーザが使用する計算機に前記第1の表示情報を送信するステップと、を含むことを特徴とするプログラムのリリース管理方法。
【請求項13】
請求項11に記載のプログラムのリリース管理方法であって、
前記統合管理情報に含まれるレコードは、前記リリース申請に対する承認の進捗状態を示す承認状態を含み、
前記第3のステップは、前記統合管理モジュールが、前記第1のレコードの前記承認状態を、前記承認が行われたことを示す値に更新するステップを含み、
前記プログラムのリリース管理方法は、
前記統合管理モジュールが、前記承認状態に前記承認が行われていないことを示す値が設定されたレコードを提示する承認用画面を表示するための第2の表示情報を生成して、前記第1の承認の可否を判断するユーザが使用する計算機に前記第2の表示情報を送信するステップと、
前記統合管理モジュールが、前記承認状態に前記承認が行われたことを示す値、及び前記リリース状態にリリースが完了していないことを示す値が設定されたレコードを提示するためのリリース開始用画面を表示するための第3の表示情報を生成して、前記第1の承認が行われた前記第1のプログラムのリリースの可否を判断するユーザが使用する計算機に前記第3の表示情報を送信するステップと、
前記統合管理モジュールが、前記第1の承認が行われた前記第1のリリース申請に基づくリリースを開始する場合、前記第1のレコードの前記リリース状態を、前記リリースの最中であることを示す値に更新するステップと、
前記統合管理モジュールが、前記第2のリポジトリに格納された前記第1のプログラムが前記実行環境にリリースされた後、前記第1のレコードの前記リリース状態を、リリースが完了したことを示す値に更新するステップと、を含むことを特徴とするプログラムのリリース管理方法。
【請求項14】
請求項9に記載のプログラムのリリース管理方法であって、
前記第1のステップは、
前記統合管理モジュールが、前記第1のレコードが前記統合管理情報に追加された後、前記第1のチケット番号に基づいて前記チケット管理情報にアクセスするステップと、
前記統合管理モジュールが、前記第1のチケット番号に対応するレコードの前記プログラムの開発タスクの進捗状態を、前記リリース申請を受け付けたことを示す値に更新するステップと、を含むことを特徴とするプログラムのリリース管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラムのリリースを管理するシステム及び方法に関する。
【背景技術】
【0002】
アプリケーションシステム開発において、開発したプログラムを試験用の実行環境又は本番用の実行環境にリリースする場合に、プログラムのバージョンの取り違い及びプログラムの漏れがないように管理する必要である。
【0003】
プログラムのバージョンの取り違いを防ぐための技術として、開発したプログラムをデータベース又はファイルシステムに格納する場合に、プログラムに対してリビジョン番号を一意に割り当て、明示的にバージョン管理を行う技術が広く普及している。また、特許文献1及び特許文献2に記載の技術も知られている。
【0004】
特許文献1には、「プログラム開発管理装置100において、テーマ別プログラムテーブル10は、開発すべきプログラムとリリース条件とを開発テーマごとに管理する。ディレクトリ生成部130は、テーマ別プログラムテーブル10を参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリをリリース記憶領域170に生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納する。」ことが記載されている。
【0005】
また、特許文献2には、「リリース管理システム10は、開発側領域38及び本番側領域40に区画された記憶装置と制御部36を備えたネットワーク接続ストレージ26と、開発者端末12と、承認者端末14と、ライブラリアン端末16と、リリース端末18と、本番機34と、転送サーバ24と、リリースサーバ32とを備える。転送サーバ24は、ライブラリアン端末16からのコマンド入力に基づいて、開発側領域38に格納された特定のプログラムを本番側領域40に転送させるコマンドを制御部36に発行する。リリースサーバ32は、リリース端末18からのコマンド入力に基づいて、本番側領域40に格納されたプログラムを取得するコマンドを制御部36に発行し、取得したプログラムを本番機34に転送する。」ことが記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2009−244974号公報
【特許文献2】特開2011−59847号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
結合試験及び総合試験において不良が検出された場合、プログラムの開発者は、プログラムの修正及び単体試験を行う。また、プログラムの開発者は、単体試験が完了したプログラムに対して再度結合試験又は総合試験を行うために、試験用の実行環境へのプログラムのリリースをリリース担当者に依頼する。
【0008】
前述した一連の開発プロセスにおいて、プログラムのリリース管理が不十分であることが原因で修正されたプログラムがリリース資材にすべて含まれていなかったり、また、単体試験が完了していないプログラムがリリース資材に混入したりするケースがある。また、リリース対象のプログラムが明示されておらず、かつ、承認プロセスに基づく承認者の判断がされないまま実行環境にプログラムがリリースされてしまうケースがある。
【0009】
このようなケースが発生した場合、試験の進行を阻害し、ひいてはシステム障害の原因となる。そのため、これらのケースが発生した場合、不良及びプログラムの管理状況の見直し、リリースのやり直し、及び試験のやり直し等が行われるため、試験工数の増大を招き、開発現場が混乱する。したがって、昨今増加傾向にある大規模なシステム開発や納期が短いシステム開発において、ビジネスの成否を分ける致命的な問題となる。
【0010】
特許文献1に記載の技術では、リリース条件毎にプログラムの格納先を分けることによって、不適切なプログラムがリリースされる可能性を低減できる。また、特許文献2に記載の技術では、承認者の判断がなされないままプログラムが実行環境にリリースされるケース、及び、不正なプログラムがリリース資材に混入するケースを防ぐことができる。
【0011】
しかし、特許文献1及び特許文献2に記載の技術では、開発タスクとプログラムを実行環境にリリースするための操作であるリリース申請とが関連付けて管理されていないため、開発者等の操作ミス及び判断ミス等に起因するリリースの誤りを防ぐことができない。
【0012】
本発明は、開発タスク及びリリース申請を自動的に関連づけて管理し、必要十分なプログラムが実行環境にリリースされるよう制御するシステム及び方法を提供することを目的とする。
【課題を解決するための手段】
【0013】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の計算機を備える計算機システムであって、前記計算機システムは、開発対象のプログラムを格納する第1のリポジトリと、実行環境にリリースするプログラムを格納する第2のリポジトリと、を含み、前記複数の計算機の少なくとも一つの計算機は、プログラムの開発タスクに割り当てられるチケット番号、及び前記プログラムの開発タスクの進捗状態から構成されるレコードを含むチケット管理情報と、前記第1のリポジトリに格納されるプログラムに割り当てられるリビジョン番号、及び前記プログラムの識別情報から構成されるレコードを含むリポジトリ管理情報と、を保持し、前記実行環境への前記第2のリポジトリに格納されるプログラムのリリースを制御する統合管理モジュールを有し、前記統合管理モジュールは、前記開発対象のプログラムを前記実行環境にリリースするための操作であるリリース申請を識別するための申請番号、前記チケット番号、及び前記リビジョン番号から構成されるレコードを含む統合管理情報を管理し、第1のプログラムに割り当てられた第1のリビジョン番号及び前記第1のプログラムの開発タスクに割り当てられた第1のチケット番号を含む第1のリリース申請を受け付けた場合、前記第1のリリース申請の申請番号、前記第1のチケット番号、及び前記第1のリビジョン番号から構成される第1のレコードを前記統合管理情報に追加し、前記第1のリリース申請の識別情報を含む、前記第1のリリース申請を許可するための操作である第1の承認を受け付けた場合、前記第1の承認を行えるか否かを判定し、前記第1の承認を行えると判定された場合、前記統合管理情報に基づいて前記リポジトリ管理情報にアクセスすることによって前記第1のプログラムを取得し、前記第1のプログラムを前記第2のリポジトリに格納し、前記統合管理情報に基づいて前記チケット管理情報にアクセスすることによって前記第1のプログラムの開発タスクの進捗状態をリリースが完了したことを示す値に更新することを特徴とする。
【発明の効果】
【0014】
本発明によれば、プログラムの開発タスク及びリリース申請を自動的に関連付けて管理することによって、リリースの誤りを防ぐことができる。これによって、試験の進行阻害及び試験工数の増加を抑止できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。
【図面の簡単な説明】
【0015】
図1】実施例1の計算機システムの構成例を示す図である。
図2】実施例1のプログラム統合管理サーバ及び開発者端末の構成を示す図である。
図3】実施例1のチケット管理情報の一例を示す図である。
図4】実施例1の開発リポジトリ管理情報の一例を示す図である。
図5】実施例1のプログラム統合管理情報の一例を示す図である。
図6】実施例1のサーバ間の入出力の一例を示す図である。
図7A】実施例1の計算機システムにおける処理の流れを説明するシーケンス図である。
図7B】実施例1の計算機システムにおける処理の流れを説明するシーケンス図である。
図7C】実施例1の計算機システムにおける処理の流れを説明するシーケンス図である。
図7D】実施例1の計算機システムにおける処理の流れを説明するシーケンス図である。
図8A】実施例1の出力装置に表示される画面の一例を示す図である。
図8B】実施例1の出力装置に表示される画面の一例を示す図である。
図8C】実施例1の出力装置に表示される画面の一例を示す図である。
図8D】実施例1の出力装置に表示される画面の一例を示す図である。
図9】実施例1のプログラム統合管理サーバがリリース申請の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。
図10】実施例1のプログラム統合管理サーバが申請承認の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。
【発明を実施するための形態】
【0016】
開発タスクとプログラムを実行環境にリリースするための操作であるリリース申請とが関連付けて管理されていないために発生するリリースの誤りとしては、例えば、以下のようなものがある。
【0017】
(1)承認者が、リリース申請が行われたプログラムをリリースしてよい状況であるか否かを正しく判断できない。(2)複数の開発者からリリース申請が行われた場合、リリース担当者と開発者との間で、どのリリース申請まで(どの不良の対応まで)がリリース資材に取り込まれたのかを共有できない。(3)承認者は、リリース資材に含まれているべきプログラムが全てそろっているか否かを確認できないため、リリース資材にプログラムの漏れが発生する可能性がある。(4)リリース申請に係るプログラムの数が多い場合、開発者がリリースすべきプログラムを漏らしてしまう可能性がある。
【0018】
以下、図面を用いて実施例を説明する。各図において共通の構成については同一の参照符号が付されている。
【実施例1】
【0019】
図1は、実施例1の計算機システムの構成例を示す図である。
【0020】
実施例1の計算機システムは、チケット管理サーバ101、開発リポジトリサーバ102、リリースリポジトリサーバ103、プログラム統合管理サーバ104、開発者端末111、承認者端末112、及びリリース管理者端末113を備える。各サーバは、サーバセグメント100に存在し、他のサーバと通信可能なように接続される。また、各端末は、ユーザ端末セグメント110に存在する。各端末は、ユーザ端末セグメント110からネットワーク120を介して、サーバセグメント100に接続する。
【0021】
チケット管理サーバ101は、プログラムの開発タスクを管理する。本実施例では、チケット管理サーバ101は、不良等に基づくプログラムの開発タスクをチケットと呼称する単位で管理する。
【0022】
開発リポジトリサーバ102は、開発対象のプログラムを格納する開発リポジトリを管理する。具体的には、開発リポジトリサーバ102は、開発者端末111がコミットと呼称される格納操作を行った場合、プログラムを開発リポジトリに格納する。開発リポジトリへのプログラムの格納時には、リビジョン番号がプログラムに付与される。なお、コミットは、一つのプログラムに対して行われてもよいし、複数のプログラムに対して行われてもよい。
【0023】
リリースリポジトリサーバ103は、承認者によって承認されたプログラムのみを格納するリリースリポジトリを管理する。リリースリポジトリは、リリースするプログラムを格納するリポジトリであり、開発者に対しては公開されない。後述するように、承認者端末112によってリリース申請を許可する操作である承認が行われたプログラムのみが開発リポジトリからリリースリポジトリにコピーされ、さらに、リリースリポジトリに格納されるプログラムが実行環境へリリースされる。
【0024】
プログラム統合管理サーバ104は、リリース申請、リリース申請に対応するプログラム、及び当該プログラムの開発タスクを管理するチケットを関連付けて管理する。具体的には、プログラム統合管理サーバ104は、開発者端末111からリリース申請を受け付けた場合、リリース申請の識別番号、リリース申請に対応するプログラムのリビジョン番号、及び当該プログラムに対応する開発タスクを管理するチケットのチケット番号を関連付けて記憶する。
【0025】
開発者端末111は、プログラムを開発する開発者が操作する端末である。承認者端末112は、リリース申請の承認を行う承認者が操作する端末である。リリース管理者端末113は、実行環境へのプログラムのリリースを管理するリリース管理者が操作する端末である。
【0026】
図2は、実施例1のプログラム統合管理サーバ104及び開発者端末111の構成を示す図である。
【0027】
プログラム統合管理サーバ104は、CPU211、メモリ212、記憶装置213、及びネットワークインタフェース(NW I/F)214を有し、各装置はデータバス215を介して互いに接続される。各装置は、データバス215を介して他の装置と通信する。なお、プログラム統合管理サーバ104は、入力装置及び出力装置等と接続するIO I/Fを有してもよい。
【0028】
CPU211は、少なくとも一つのコアを有する演算装置であり、メモリ212に格納されるプログラムを実行する。CPU211がプログラムを実行することによって、所定の機能を有するモジュールを実現する。以下の説明では、モジュールを主語に処理を説明する場合、CPU211が当該モジュールを実現するプログラムを実行していることを示す。
【0029】
メモリ212は、CPU211が実行するプログラム及び当該プログラムに必要な情報を格納する。また、メモリ212は、モジュールが一時的に使用するワークエリアを含む。メモリ212は、不揮発性の記憶素子から構成されるROM、及び揮発性の記憶素子から構成されるRAM等が考えられる。メモリ212に格納されるプログラムについては後述する。
【0030】
記憶装置213は、プログラム及び情報を格納する。記憶装置213は、例えば、HDD(Hard Disk Drive)及びSSD(Solid State Drive)等が考えられる。なお、メモリ212に格納されるプログラム及び情報は、記憶装置213に格納されてもよい。この場合、CPU211は、記憶装置213からプログラム及び情報を読み出し、メモリ212にプログラム及び情報をロードする。記憶装置213に格納される情報については後述する。
【0031】
NW I/F214は、ネットワークを介して外部装置と接続するためのインタフェースである。
【0032】
なお、チケット管理サーバ101、開発リポジトリサーバ102、リリースリポジトリサーバ103のハードウェア構成は、プログラム統合管理サーバ104のハードウェア構成と同一である。
【0033】
ここで、各サーバのメモリ212に格納されるプログラム及び記憶装置213に格納される情報について説明する。
【0034】
プログラム統合管理サーバ104のメモリ212は、統合管理モジュール220を実現するプログラムを格納する。統合管理モジュール220は、プログラム統合管理サーバ104を制御するモジュールであり、複数のモジュールを含む。具体的には、統合管理モジュール220は、入出力モジュール221、判定モジュール222、登録モジュール223、及びコピー実行モジュール224を含む。
【0035】
入出力モジュール221は、外部から入力されたデータを受信し、また、外部へ出力するデータを送信する。判定モジュール222は、チケット管理サーバ101及び開発リポジトリサーバ102が保持する情報にリリース申請の対象に関連するデータが格納されているか否かを判定する。登録モジュール223は、データの更新及びデータの登録を行う。コピー実行モジュール224は、開発リポジトリとリリースリポジトリとの間のコピー処理を制御する。
【0036】
プログラム統合管理サーバ104の記憶装置213は、プログラム統合管理情報230を格納する。プログラム統合管理情報230は、リリース申請と、リリース申請に関連するプログラムの開発タスクとの対応関係を管理する情報である。プログラム統合管理情報230の詳細は、図5を用いて説明する。記憶装置213に格納される情報は、メモリ212に格納されてもよい。
【0037】
なお、プログラム統合管理サーバ104の記憶装置213には、開発者、承認者、及びリリース管理者を区別するためのユーザ情報(図示省略)が格納される。ユーザ情報は、ユーザの名称、アカウントの種別、及び操作権限等から構成されるレコードを含む。
【0038】
チケット管理サーバ101、開発リポジトリサーバ102、及びリリースリポジトリサーバ103のそれぞれのメモリ212は、各サーバを制御する制御モジュール601、602、603(図6参照)を実現するプログラムを格納する。
【0039】
チケット管理サーバ101の記憶装置213は、チケット管理情報300を格納する。チケット管理情報300は、プログラムの開発タスクを管理する情報である。チケット管理情報300の詳細は、図3を用いて説明する。
【0040】
開発リポジトリサーバ102の記憶装置213は、開発リポジトリ管理情報400を格納する。開発リポジトリ管理情報400は、開発リポジトリに格納されるプログラムを管理する情報である。開発リポジトリ管理情報400の詳細は、図4を用いて説明する。
【0041】
次に、開発者端末111について説明する。開発者端末111は、CPU251、メモリ252、NW I/F253、及びIO I/F254を有し、各装置はデータバス255を介して互いに接続される。
【0042】
CPU251、メモリ252、及びNW I/F253は、CPU211、メモリ212、及びNW I/F214と同様のものである。
【0043】
IO I/F254は、外部装置と接続するインタフェースである。本実施例では、IO I/F254は、入力装置256及び出力装置257と接続する。
【0044】
入力装置256は、各種データを入力するために用いられる装置であり、例えば、マウス、キーボード、及びタッチパネルが考えられる。出力装置257は、データを出力するために用いられる装置であり、例えば、ディスプレイ及びタッチパネル等が考えられる。
【0045】
なお、承認者端末112及びリリース管理者端末113のハードウェア構成は、開発者端末111のハードウェア構成と同一である。
【0046】
図3は、実施例1のチケット管理情報300の一例を示す図である。
【0047】
チケット管理情報300は、チケット番号301、ステータス302、チケット内容303、担当チーム304、担当者305、及び期日306から構成されるレコードを含む。なお、レコードには、前述した以外のカラムが含まれてもよい。
【0048】
チケット番号301は、開発タスクの管理単位であるチケットの識別情報である。チケット番号301は、チケット管理情報300のレコードを識別するための識別情報としても用いられる。本実施例では、自動採番機能に基づいて算出された番号がチケット番号301に設定される。
【0049】
ステータス302は、開発タスクの進捗状態を示す情報である。ステータス302には、「リリース申請前」、「リリース受付済」、「リリース待ち」、「リリース済」、及び「試験完了」等が格納される。ステータス302は、開発タスクの進捗に応じて更新される。
【0050】
なお、「試験完了」は、試験用の実行環境において、リリースされたプログラムを用いた結合試験又や総合試験が完了した情報を示す。本実施例では、関連する全てのチケットのステータス302が「試験完了」となった場合に本番用の実行環境へのリリースが行われる。これによって、不良の対応漏れ等を防止することができる。
【0051】
チケット内容303は、承認者が承認するか否かを判断する場合に判断材料となる情報である。例えば、チケット内容303には、具体的な不良の内容及び対策方法等が格納される。
【0052】
担当チーム304及び担当者305は、プログラムを開発するチーム及び担当者の情報である。なお、担当チーム304及び担当者305に設定される情報は、ユーザ情報から取得できる。期日306は、プログラムの開発期日である。
【0053】
図4は、実施例1の開発リポジトリ管理情報400の一例を示す図である。
【0054】
開発リポジトリ管理情報400は、リビジョン番号401、プログラム名402、プログラム格納パス403、及びコミットユーザ404から構成されるレコードを含む。なお、レコードには、前述した以外のカラムが含まれてもよい。
【0055】
リビジョン番号401は、開発リポジトリに格納されるプログラムを識別するための識別情報である。リビジョン番号401は、開発リポジトリ管理情報400のレコードを識別するための識別情報としても用いられる。本実施例では、自動採番機能に基づいて算出された番号がリビジョン番号401に設定される。
【0056】
プログラム名402は、開発リポジトリに格納されるプログラムの名称である。
【0057】
プログラム格納パス403は、開発リポジトリにおけるプログラムの格納場所を示すパスである。
【0058】
コミットユーザ404は、コミットを行ったユーザの名称である。コミットユーザ404には、担当者305に設定された名称が格納される。
【0059】
図5は、実施例1のプログラム統合管理情報230の一例を示す図である。
【0060】
プログラム統合管理情報230は、申請番号501、チケット番号502、リビジョン番号503、申請者504、承認ステータス505、及びリリースステータス506から構成されるレコードを含む。なお、レコードには、前述した以外のカラムが含まれてもよい。
【0061】
申請番号501は、リリース申請を識別するための識別情報である。申請番号501は、プログラム統合管理情報230のレコードを識別するための識別情報としても用いられる。本実施例では、自動採番機能に基づいて算出された番号が申請番号501に設定される。
【0062】
チケット番号502は、リリース申請の対象となるプログラムの開発タスクに割り当てられたチケットの識別番号である。チケット番号502には、チケット番号301に設定された識別情報が格納される。
【0063】
リビジョン番号503は、リリース申請の対象となるプログラムのリビジョン番号である。リビジョン番号503には、リビジョン番号401に設定された識別情報が格納される。
【0064】
申請者504は、リリース申請を行ったユーザの名称である。申請者504には、担当者305に設定された名称が格納される。なお、申請者504に設定される名称は、ユーザ情報から取得できる。
【0065】
承認ステータス505は、リリース申請の承認の進捗状態を示す情報である。承認ステータス505には、「未」及び「済」のいずれかが格納される。
【0066】
リリースステータス506は、リリースの進捗状態を示す情報である。リリースステータス506には、「未」、「対応中」、及び「済」のいずれかが格納される。なお、「対応中」は、リリースが行われている最中であることを示す。
【0067】
チケット管理情報300、開発リポジトリ管理情報400、及びプログラム統合管理情報230は、テーブル形式の情報として説明したがこれに限定されない。CSV形式等のデータ形式でもよい。
【0068】
図6は、実施例1のサーバ間の入出力の一例を示す図である。図7A図7B図7C、及び図7Dは、実施例1の計算機システムにおける処理の流れを説明するシーケンス図である。図8A図8B図8C、及び図8Dは、実施例1の出力装置257に表示される画面の一例を示す図である。
【0069】
図7Aに示す処理の流れについて説明する。開発者は、結合試験又は統合試験においてプログラムの不良を検出した場合、開発者端末111を用いて、該当するプログラムの開発タスクを管理するためのチケットの登録指示をチケット管理サーバ101に送信する(ステップS701)。なお、登録指示には、担当チーム、担当者、及び期日等の情報が含まれる。
【0070】
チケット管理サーバ101は、登録指示を受け付けた場合、チケット登録処理を実行する(ステップS702)。
【0071】
具体的には、チケット管理サーバ101は、チケット管理情報300にレコードを追加し、追加されたレコードのチケット番号301にチケット番号を設定する。また、チケット管理サーバ101は、追加されたレコードのステータス302、チケット内容303、担当チーム304、担当者305、及び期日306に値を設定する。
【0072】
チケット管理サーバ101は、チケット登録処理が終了した後、開発者端末111に応答を送信する(ステップS703)。当該応答にはチケット番号等が含まれる。
【0073】
開発者は、開発タスクの進捗に応じて、チケットの更新指示を開発者端末111を用いてチケット管理サーバ101に送信する(ステップS704)。当該更新指示には、ステータス302に設定する値及びチケット番号が含まれる。なお、更新指示には、他の情報が含まれてもよい。
【0074】
チケット管理サーバ101は、更新指示を受け付けた場合、チケット更新処理を実行する(ステップS705)。
【0075】
具体的には、チケット管理サーバ101は、チケット管理情報300を参照して、チケット番号301が更新指示に含まれるチケット番号に一致するレコードを検索し、当該レコードのステータス302を更新する。
【0076】
チケット管理サーバ101は、チケット更新処理が終了した後、開発者端末111に応答を送信する(ステップS706)。
【0077】
開発者は、修正したプログラムの単体試験が完了し、再度、試験用の実行環境にプログラムをリリースできる状態になった場合、対応するチケットのステータス302を「リリース申請前」に更新する。その後、開発者は、開発者端末111を用いて、プログラムのコミット指示を開発リポジトリサーバ102に送信する(ステップS707)。コミット指示には、プログラム、及び当該プログラムの名称等が含まれる。
【0078】
開発リポジトリサーバ102は、コミット指示を受け付けた場合、コミット処理を実行する(ステップS708)。
【0079】
具体的には、開発リポジトリサーバ102は、開発リポジトリにプログラムを格納する。開発リポジトリサーバ102は、開発リポジトリ管理情報400にレコードを追加し、追加されたレコードのリビジョン番号401にリビジョン番号を設定する。また、開発リポジトリサーバ102は、追加されたレコードのプログラム名402にコミット指示に含まれる値を設定し、また、プログラム格納パス403に開発リポジトリに格納されたプログラムのパスを設定する。また、開発リポジトリサーバ102は、追加されたレコードのコミットユーザ404に、ユーザ情報から取得した開発者の名称を設定する。
【0080】
開発リポジトリサーバ102は、コミット処理が終了した後、開発者端末111に応答を送信する(ステップS709)。当該応答にはリビジョン番号が含まれる。
【0081】
次に、図7Bに示す処理の流れについて説明する。開発者は、開発者端末111の出力装置257に表示されるリリース申請用画面801を操作して、リリース申請の指示をプログラム統合管理サーバ104に送信する(ステップS711)。
【0082】
リリース申請用画面801は、リビジョン番号入力欄811、チケット番号入力欄812、及びリリース申請ボタン813を含む。なお、図8Aの画面は一例であり、これに限定されない。開発者は、入力装置256を用いて、リビジョン番号入力欄811及びチケット番号入力欄812のそれぞれリビジョン番号及びチケット番号を設定し、リリース申請ボタン813を操作する。この場合、開発者端末111は、リビジョン番号及びチケット番号を含むリリース申請の指示をプログラム統合管理サーバ104に送信する。
【0083】
プログラム統合管理サーバ104は、リリース申請の指示を受け付けた場合、チケット管理サーバ101にチケット確認処理の実行指示を送信し(ステップS712)、また、開発リポジトリサーバ102にプログラム確認処理の実行指示を送信する(ステップS715)。
【0084】
具体的には、判定モジュール222が、チケット番号が含まれるチケット確認処理の実行指示を送信し、また、リビジョン番号が含まれるプログラム確認処理の実行指示を送信する。
【0085】
チケット管理サーバ101は、チケット確認処理の実行指示を受け付けた場合、チケット確認処理を実行し(ステップS713)、実行結果を含む応答をプログラム統合管理サーバ104に送信する(ステップS714)。
【0086】
具体的には、チケット管理サーバ101は、チケット管理情報300を参照して、チケット番号301が実行指示に含まれるチケット番号に一致するレコードを検索する。前述の条件を満たすレコードが存在した場合、チケット管理サーバ101は、当該レコードのステータス302の値を実行結果としてプログラム統合管理サーバ104に送信する。前述の条件を満たすレコードが存在しなかった場合、チケット管理サーバ101は、エラーを示す実行結果をプログラム統合管理サーバ104に送信する。
【0087】
開発リポジトリサーバ102は、プログラム確認処理の実行指示を受け付けた場合、プログラム確認処理を実行し(ステップS716)、実行結果を含む応答をプログラム統合管理サーバ104に送信する(ステップS717)。
【0088】
具体的には、開発リポジトリサーバ102は、開発リポジトリ管理情報400を参照して、リビジョン番号401が実行指示に含まれるリビジョン番号に一致するレコードを検索する。前述の条件を満たすレコードが存在した場合、開発リポジトリサーバ102は、当該レコードのプログラム名402の値を実行結果としてプログラム統合管理サーバ104に送信する。前述の条件を満たすレコードが存在しなかった場合、開発リポジトリサーバ102は、エラーを示す実行結果をプログラム統合管理サーバ104に送信する。
【0089】
プログラム統合管理サーバ104は、チケット管理サーバ101及び開発リポジトリサーバ102から応答を受信した後、開発者に提示する表示情報を生成し、生成された表示情報を含む応答を開発者端末111に送信する(ステップS718)。表示情報には、例えば、チケット管理情報300から取得したステータス302、及び開発リポジトリ管理情報400から取得したプログラム名402が含まれる。開発者端末111は、応答に含まれる表示情報に基づいて出力装置257に画面を表示する。
【0090】
開発者は、出力装置257に表示された画面を確認し、特に問題が無い場合、開発者端末111を用いて、プログラム統合管理サーバ104に申請内容確定の指示を送信する(ステップS719)。
【0091】
プログラム統合管理サーバ104は、申請内容確定の指示を受け付けた場合、リリース申請を正式に受け付けたものとして、リリース申請及び開発タスクの対応関係をプログラム統合管理情報230に登録する。その後、プログラム統合管理サーバ104は、チケット管理サーバ101にチケット更新処理の実行指示を送信する(ステップS720)。
【0092】
具体的には、登録モジュール223が、ステータス302に設定する値「リリース受付済」、及びチケット番号を含む実行指示を送信する。
【0093】
チケット管理サーバ101は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する(ステップS721)。また、チケット管理サーバ101は、チケット更新処理が終了した後、プログラム統合管理サーバ104に応答を送信する(ステップS722)。
【0094】
チケット更新処理では、チケット管理サーバ101は、チケット管理情報300を参照して、チケット番号301が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス302を「リリース申請前」から「リリース受付済」に更新する。
【0095】
プログラム統合管理サーバ104は、チケット管理サーバ101から応答を受け付けた場合、開発者端末111に応答を送信する(ステップS723)。
【0096】
リリース申請時におけるプログラム統合管理サーバ104の処理の詳細は、図9を用いて説明する。
【0097】
次に、図7Cに示す処理の流れについて説明する。承認者は、リリース申請の承認する場合、承認者端末112を用いてプログラム統合管理サーバ104に接続する。プログラム統合管理サーバ104は、承認者端末112からの接続を検出した場合、リリース申請を受けたプログラムの一覧である申請一覧を提示する(ステップS731)。具体的には、図8Bに示す承認用画面802が出力装置257に表示される。
【0098】
承認用画面802は、申請番号822、リビジョン番号823、プログラム名824、チケット内容825、担当チーム826、及び担当者827を含む申請一覧821、承認ボタン828、並びに差戻しボタン829を含む。なお、図8Bの画面は一例であり、これに限定されない。例えば、申請一覧821に期日のカラムが含まれてもよい。
【0099】
ここで、承認用画面802を表示するための処理について説明する。プログラム統合管理サーバ104は、プログラム統合管理情報230を参照し、承認ステータス505が「未」となっているレコードを検索する。プログラム統合管理サーバ104は、検索されたレコードのチケット番号502を含む問合せをチケット管理サーバ101に送信する。これによって、チケット内容303、担当チーム304、及び担当者305等の値を取得できる。また、プログラム統合管理サーバ104は、検索されたレコードのリビジョン番号503を含む問合せを開発リポジトリサーバ102に送信する。これによって、プログラム名402等の値を取得できる。プログラム統合管理サーバ104は、取得した値を用いて申請一覧821等を表示するための表示情報を作成し、リリース管理者端末113に当該表示情報を送信する。
【0100】
まず、承認用画面802において承認ボタン828が操作された場合の処理の流れについて説明する。
【0101】
承認者は、申請一覧821から許可するリリース申請を選択し、承認ボタン828を操作する。なお、選択するリリース申請の数は、一つでもよいし、また、複数でもよい。承認者端末112は、承認ボタン828が操作された場合、プログラム統合管理サーバ104に申請承認の指示を送信する(ステップS732)。当該指示には、申請番号が含まれる。
【0102】
プログラム統合管理サーバ104は、申請承認の指示を受け付けた場合、開発リポジトリサーバ102にプログラムコピー処理の実行指示を送信する(ステップS733)。当該実行指示には、リビジョン番号が含まれる。なお、プログラム統合管理サーバ104は、申請承認の指示に含まれる申請番号に基づいてプログラム統合管理情報230を参照することによってリビジョン番号を取得できる。
【0103】
開発リポジトリサーバ102は、プログラムコピー処理の実行指示を受け付けた場合、プログラムコピー処理を実行する(ステップS734)。また、開発リポジトリサーバ102は、プログラムコピー処理が終了した後、プログラム統合管理サーバ104に応答を送信する(ステップS735)。
【0104】
具体的には、開発リポジトリサーバ102は、開発リポジトリ管理情報400を参照し、リビジョン番号401が実行指示に含まれるリビジョン番号に一致するレコードを検索する。開発リポジトリサーバ102は、検索されたレコードのプログラム格納パス403に基づいて、開発リポジトリからリリース対象のプログラムを読み出し、リリースリポジトリサーバ103に当該プログラムを送信する。これによって、リリースリポジトリに、リリース対象のプログラムがコピーされる。本実施例では、リリースリポジトリに格納されるプログラムは、プログラムコピー処理によってのみ更新される。
【0105】
なお、後述するように、プログラム統合管理サーバ104は、申請承認の指示を受け付けた場合、リリースステータス506が「対応中」であるレコードが存在するか否かを判定する。リリースステータス506が「対応中」であるレコードが存在する場合、プログラム統合管理サーバ104は、承認者端末112に承認処理が実行できない旨のメッセージを送信する。
【0106】
プログラム統合管理サーバ104は、開発リポジトリサーバ102応答を受け付けた場合、チケット管理サーバ101にチケット更新処理の実行指示を送信する(ステップS736)。
【0107】
具体的には、登録モジュール223が、ステータス302に設定する値「リリース待ち」、及び承認者によって選択されたリリース申請に対応するチケット番号を含む実行指示を送信する。なお、登録モジュール223は、申請番号に基づいてプログラム統合管理情報230を参照することによってチケット番号を取得できる。
【0108】
チケット管理サーバ101は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する(ステップS737)。また、チケット管理サーバ101は、チケット更新処理が終了した後、プログラム統合管理サーバ104に応答を送信する(ステップS738)。
【0109】
チケット更新処理では、チケット管理サーバ101は、チケット管理情報300を参照して、チケット番号301が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス302を「リリース受付済」から「リリース待ち」に更新する。
【0110】
プログラム統合管理サーバ104は、チケット管理サーバ101から応答を受け付けた場合、承認者端末112に応答を送信する(ステップS739)。
【0111】
次に、承認用画面802において差戻しボタン829が操作された場合の処理の流れについて説明する。
【0112】
承認者は、申請一覧821から差戻しを行うリリース申請を選択し、差戻しボタン829を操作する。なお、選択するリリース申請の数は、一つでもよいし、また、複数でもよい。承認者端末112は、差戻しボタン829が操作された場合、プログラム統合管理サーバ104に申請差戻しの指示を送信する(ステップS741)。当該指示には、申請番号が含まれる。
【0113】
プログラム統合管理サーバ104は、申請差戻しの指示を受け付けた場合、チケット管理サーバ101にチケット更新処理の実行指示を送信する(ステップS742)。
【0114】
具体的には、登録モジュール223が、ステータス302に設定する値「リリース申請前」、及び承認者によって選択されたリリース申請に対応するチケット番号を含む実行指示を送信する。なお、登録モジュール223は、申請番号に基づいてプログラム統合管理情報230を参照することによってチケット番号を取得できる。
【0115】
チケット管理サーバ101は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する(ステップS743)。また、チケット管理サーバ101は、チケット更新処理が終了した後、プログラム統合管理サーバ104に応答を送信する(ステップS744)。
【0116】
チケット更新処理では、チケット管理サーバ101は、チケット管理情報300を参照して、チケット番号301が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス302を「リリース受付済」から「リリース申請前」に更新する。
【0117】
プログラム統合管理サーバ104は、チケット管理サーバ101から応答を受け付けた場合、差戻されたリリース申請の指示を送信する開発者端末111に差戻し通知を送信する(ステップS745)。
【0118】
具体的には、プログラム統合管理サーバ104は、ステップS742において取得されたチケット番号を含む問合せをチケット管理サーバ101に送信することによって、担当チーム304及び担当者305の値を取得する。プログラム統合管理サーバ104は、取得された値及びユーザ情報に基づいて、差戻し通知を送信する開発者を特定する。プログラム統合管理サーバ104は、特定された開発者が操作する開発者端末111に差戻し通知を送信する。
【0119】
リリース申請の承認時におけるプログラム統合管理サーバ104の処理の詳細は、図10を用いて説明する。
【0120】
次に、図7Dに示す処理の流れについて説明する。リリース管理者は、リリースを開始する場合、リリース管理者端末113を用いてプログラム統合管理サーバ104に接続する。プログラム統合管理サーバ104は、リリース管理者端末113からの接続を検出した場合、画面を提示する(ステップS751)。具体的には、図8Cに示すリリース開始用画面803が出力装置257に表示される。
【0121】
リリース開始用画面803は、申請番号832、チケット番号833、リビジョン番号834、及び申請者835を含む申請一覧831、リリース開始ボタン836、並びに作成ボタン837を含む。なお、図8Cの画面は一例であり、これに限定されない。
【0122】
ここで、リリース開始用画面803を表示するための処理について説明する。プログラム統合管理サーバ104は、プログラム統合管理情報230を参照し、承認ステータス505が「済」かつリリースステータス506が「未」となっているレコードを検索する。プログラム統合管理サーバ104は、検索されたレコードに基づいて申請一覧831等を表示するための表示情報を作成し、リリース管理者端末113に当該表示情報を送信する。
【0123】
リリース管理者は、申請一覧831からリリースを行うリリース申請を選択し、リリース開始ボタン836を操作する。なお、選択するリリース申請の数は、一つでもよいし、また、複数でもよい。リリース管理者端末113は、リリース開始ボタン836が操作された場合、プログラム統合管理サーバ104にリリースステータスの変更指示を送信する(ステップS752)。当該指示には、申請番号が含まれる。
【0124】
プログラム統合管理サーバ104は、リリースステータスの変更指示を受け付けた場合、リリースステータス変更処理を実行する(ステップS753)。また、プログラム統合管理サーバ104は、リリースステータス変更処理が終了した後、リリース管理者端末113に応答を送信する(ステップS754)。
【0125】
具体的には、プログラム統合管理サーバ104は、プログラム統合管理情報230を参照し、申請番号501がリリースステータスの変更指示に含まれる申請番号に一致するレコードを検索する。プログラム統合管理サーバ104は、検索されたレコードのリリースステータス506を「未」から「対応中」に更新する。
【0126】
リリースステータス506が「対応中」であるレコードが一つ以上存在する場合、プログラム統合管理サーバ104は、承認者によるリリース申請の承認が行われないように制御する。なぜならば、リリース管理者によってリリースが行われている最中であるためである。
【0127】
リリース管理者は、リリース作業を開始するために、リリース管理者端末113を操作して、リリース資材を作成する(ステップS755)。例えば、リリース管理者は、リリース管理者端末113を用いてリリースリポジトリに格納されるプログラムに対するビルドを実行することによって、リリース資材を作成する。リリース管理者は、結合試験又は統合試験を実行するために、実行環境にリリース資材をリリースする。
【0128】
リリース管理者は、リリース資材のリリースが完了した後、リリースの完了を通知するために、リリース管理者端末113を用いてプログラム統合管理サーバ104に接続する。プログラム統合管理サーバ104は、リリース管理者端末113からの接続を検出した場合、画面を提示する(ステップS756)。具体的には、図8Dに示すリリース完了登録用画面804が出力装置257に表示される。
【0129】
リリース完了登録用画面804は、申請番号842、チケット番号843、リビジョン番号844、及び申請者845を含む申請一覧841、並びにリリース完了ボタン846を含む。なお、図8Dの画面は一例であり、これに限定されない。
【0130】
ここで、リリース完了登録用画面804を表示するための処理について説明する。プログラム統合管理サーバ104は、プログラム統合管理情報230を参照し、リリースステータス506が「対応中」であるレコードを検索する。プログラム統合管理サーバ104は、検索されたレコードに基づいて申請一覧841等を表示するための表示情報を作成し、リリース管理者端末113に当該表示情報を送信する。
【0131】
リリース管理者は、申請一覧841を参照し、リリース内容に誤りが無いか否かを確認する。リリース管理者は、リリース内容に誤りが無いと判断した場合、リリース完了ボタン846を操作する。リリース管理者端末113は、リリース完了ボタン846が操作された場合、プログラム統合管理サーバ104にリリース完了の登録指示を送信する(ステップS757)。
【0132】
プログラム統合管理サーバ104は、リリース完了の登録指示を受け付けた場合、チケット管理サーバ101にチケット更新処理の実行指示を送信する(ステップS758)。
【0133】
具体的には、登録モジュール223は、プログラム統合管理情報230を参照し、ステップS752においてリリースステータス506が「対応中」に更新されたレコードを検索する。登録モジュール223は、ステータス302に設定する値「リリース済」、及び検索されたレコードのチケット番号502を含む実行指示を送信する。
【0134】
チケット管理サーバ101は、チケット更新処理の実行指示を受け付けた場合、チケット更新処理を実行する(ステップS759)。また、チケット管理サーバ101は、チケット更新処理が終了した後、プログラム統合管理サーバ104に応答を送信する(ステップS760)。
【0135】
チケット更新処理では、チケット管理サーバ101は、チケット管理情報300を参照して、チケット番号301が実行指示に含まれるチケット番号に一致するレコードを検索し、検索されたレコードのステータス302を「リリース待ち」から「リリース済」に更新する。
【0136】
プログラム統合管理サーバ104は、チケット管理サーバ101から応答を受け付けた場合、プログラム統合管理情報230を更新し、また、開発者端末111にリリース完了通知を送信する(ステップS761)。なお、リリース完了通知には、申請番号が含まれる。
【0137】
具体的には、プログラム統合管理サーバ104は、プログラム統合管理情報230を参照し、ステップS752においてリリースステータス506が「対応中」に更新されたレコードを検索し、当該レコードのリリースステータス506を「済」に更新する。
【0138】
なお、プログラム統合管理サーバ104は、全ての開発者にリリース完了通知を送信してもよいし、リリースされたプログラムを開発した開発者にリリース完了通知を送信してもよい。
【0139】
なお、プログラム統合管理サーバ104は、ユーザ情報を用いて、開発者、承認者、及びリリース管理者を区別し、各ユーザに割り当てられた権限に応じて、受付可能な操作を制御する。例えば、プログラム統合管理サーバ104は、承認者のみがリリース申請の承認を行えるように制御し、また、リリース管理者のみがリリースの開始及びリリースの完了を行えるように制御する。
【0140】
図9は、実施例1のプログラム統合管理サーバ104がリリース申請の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。
【0141】
プログラム統合管理サーバ104は、リリース申請の指示を受け付けた場合、以下の処理を実行する。
【0142】
リリース申請の指示を受け付けた入出力モジュール221によって呼び出された判定モジュール222は、チケット番号が含まれるチケット確認処理の実行指示をチケット管理サーバ101に送信し、また、リビジョン番号が含まれるプログラム確認処理の実行指示を開発リポジトリサーバ102に送信する(ステップS901)。
【0143】
具体的には、判定モジュール222は、入出力モジュール221に各実行指示の送信を指示する。判定モジュール222は、チケット管理サーバ101及び開発リポジトリサーバ102から応答を受け付けるまで待ち状態に移行する。
【0144】
チケット管理サーバ101及び開発リポジトリサーバ102から応答を受け付けた場合、判定モジュール222は、エラーを示す実行結果を含む応答を受け付けたか否かを判定する(ステップS902)。二つの応答のうち、少なくとも一つの応答にエラーを示す実行結果が含まれる場合、判定モジュール222は、エラーを示す実行結果を含む応答を受け付けたと判定する。
【0145】
エラーを示す実行結果を含む応答を受け付けたと判定された場合、判定モジュール222は、エラーメッセージを含む応答を開発者端末111に送信する(ステップS909)。その後、統合管理モジュール220は、処理を終了する。
【0146】
エラーを示す実行結果を含む応答を受け付けていないと判定された場合、判定モジュール222は、リリース申請に関連するチケットのステータス302が「リリース申請前」であるか否かを判定する(ステップS903)。
【0147】
具体的には、判定モジュール222は、チケット管理サーバ101から受信した応答に含まれるステータス302が「リリース申請前」であるか否かを判定する。なお、複数のプログラムに対するリリース申請を行う場合、全てのプログラムに対応するステータス302が「リリース申請前」であるか否かが判定される。
【0148】
リリース申請に関連するチケットのステータス302が「リリース申請前」ではないと判定された場合、判定モジュール222は、エラーメッセージを含む応答を開発者端末111に送信する(ステップS909)。その後、統合管理モジュール220は、処理を終了する。
【0149】
リリース申請に関連するチケットのステータス302が「リリース申請前」であると判定された場合、判定モジュール222は、表示情報を含む応答を開発者端末111に送信する(ステップS904)。
【0150】
統合管理モジュール220は、申請内容確定の指示を受け付けたか否かを判定する(ステップS905)。例えば、統合管理モジュール220は、表示情報を含む応答を送信した後一定期間内に申請内容確定の指示を受け付けていない場合、申請内容確定指示を受け付けていないと判定する。
【0151】
申請内容確定指示を受け付けていないと判定された場合、統合管理モジュール220は、処理を終了する。
【0152】
申請内容確定指示を受け付けたと判定された場合、統合管理モジュール220は、登録モジュール223を呼び出す。登録モジュール223は、プログラム統合管理情報230を更新する(ステップS906)。
【0153】
具体的には、登録モジュール223は、プログラム統合管理情報230にレコードを追加し、追加されたレコードの申請番号501に識別番号を設定する。登録モジュール223は、追加されたレコードのチケット番号502及びリビジョン番号503に、リリース申請に含まれるチケット番号及びリビジョン番号を設定する。登録モジュール223は、追加されたレコードの申請者504にチケット管理サーバ101から受け付けた応答に含まれる担当者305の値を設定する。さらに、登録モジュール223は、追加されたレコードの承認ステータス505及びリリースステータス506に「未」を設定する。
【0154】
ステップS906の処理によって、リリース申請、プログラムの開発タスク、及び開発リポジトリに格納されるプログラムを関連付けて管理することができる。
【0155】
登録モジュール223は、ステータス302に設定する値「リリース受付済」、及びチケット番号を含むチケット更新処理の実行指示を、チケット管理サーバ101に送信する(ステップS907)。
【0156】
統合管理モジュール220は、チケット管理サーバ101から応答を受け付けた場合、開発者端末111に応答を送信する(ステップS908)。その後、統合管理モジュール220は、処理を終了する。
【0157】
図10は、実施例1のプログラム統合管理サーバ104が申請承認の指示を受け付けた場合に実行する処理の一例を説明するフローチャートである。
【0158】
プログラム統合管理サーバ104は、承認者端末112からの接続を検出した場合、以下の処理を実行する。
【0159】
承認者端末112からの接続を検出した入出力モジュール221によって呼び出されたコピー実行モジュール224は、プログラム統合管理情報230を参照し、リリースステータス506が「対応中」であるレコードが存在するか否か判定する(ステップS1001)。
【0160】
リリースステータス506が「対応中」であるレコードが存在すると判定された場合、コピー実行モジュール224は、承認者端末112に、リリース中であるため承認処理を実行できない旨を示すメッセージを送信する(ステップS1008)。その後、統合管理モジュール220は、処理を終了する。
【0161】
ステップS1008の処理は、リリースの最中にリリース申請の承認が行われないように制御するために行われる。したがって、本実施例では、リリースされるプログラム及びリリース申請の対象となるプログラムが異なる場合であっても、承認が行われない。これによって、別々のリリース資材としてリリースされるプログラムが混在することを防ぐことができる。
【0162】
リリースステータス506が「対応中」であるレコードが存在しないと判定された場合、コピー実行モジュール224は、開発リポジトリに名称が一致するプログラムが存在するか否かを判定する(ステップS1002)。すなわち、リビジョン番号401が異なり、かつ、プログラム名402が同一であるレコードが存在するか否かが判定される。
【0163】
具体的には、コピー実行モジュール224は、プログラム統合管理情報230の各レコードのリビジョン番号503を含むプログラム名の問合せを開発リポジトリサーバ102に送信する。コピー実行モジュール224は、開発リポジトリサーバ102から取得したプログラム名に基づいて、名称が一致するプログラムが存在するか否かを判定する。
【0164】
開発リポジトリに名称が一致するプログラムが存在すると判定された場合、コピー実行モジュール224は、承認者端末112に、エラーメッセージを送信する(ステップS1009)。その後、統合管理モジュール220は、処理を終了する。当該エラーメッセージには、リビジョン番号、プログラム名、及び申請者が含まれる。
【0165】
一般的に、複数の開発者によってリリースされたプログラムを結合して一つの結合試験又は総合試験が行われる。したがって、リビジョン番号が異なる同一プログラムが開発リポジトリに存在する場合、どちらのプログラムをリリース資材に含めるかを決定する必要がある。そこで、本実施例では、前述したようなプログラムのコンフリクトが発生した場合、承認者に関係者間の調整を促すためのエラーメッセージを送信する。これによって、関係者間で速やかに調整が行われ、リリースの可否及びリリースするプログラムを決定することができる。
【0166】
開発リポジトリに名称が一致するプログラムが存在しないと判定された場合、コピー実行モジュール224は、申請一覧を提示する(ステップS1003)。
【0167】
コピー実行モジュール224は、申請承認の指示を受け付けたか否かを判定する(ステップS1004)。
【0168】
申請承認の指示を受け付けたと判定された場合、コピー実行モジュール224は、開発リポジトリサーバ102にプログラムコピー処理の実行指示を送信する(ステップS1005)。
【0169】
コピー実行モジュール224は、開発リポジトリサーバ102から応答を受け付けた場合、登録モジュール223を呼び出す。登録モジュール223は、ステータス302に設定する値「リリース待ち」、及び承認者によって選択された申請番号に対応するチケット番号を含む実行指示を、チケット管理サーバ101に送信する(ステップS1006)。
【0170】
登録モジュール223は、プログラム統合管理情報230を更新する(ステップS1007)。
【0171】
具体的には、登録モジュール223は、プログラム統合管理情報230を参照し、ステップS1004において選択されたレコードの承認ステータス505に「済」を設定する。
【0172】
ステップS1004において、申請差戻しの指示を受け付けたと判定された場合、コピー実行モジュール224は、登録モジュール223を呼び出す。登録モジュール223は、ステータス302に設定する値「リリース申請前」、及び承認者によって選択された申請番号に対応するチケット番号を含む実行指示を、チケット管理サーバ101に送信する(ステップS1010)。
【0173】
登録モジュール223は、チケット管理サーバ101から応答を受け付けた場合、差戻されたリリース申請を行った開発者端末111に差戻し通知を送信する(ステップS1011)。その後、統合管理モジュール220は、処理を終了する。
【0174】
本実施例によれば、リリース申請及び開発タスクが関連付けて管理されるため、開発タスク及びリリース申請が連携するようにプログラムのリリースにおける各種操作を制御することができる。これによって、開発者等の操作ミス及び判断ミス等に起因するリリースの誤りを防ぐことができため、試験工程が円滑に進行できる。
【0175】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
【0176】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるCPUが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、CD−ROM、DVD−ROM、ハードディスク、SSD(Solid State Drive)、光ディスク、光磁気ディスク、CD−R、磁気テープ、不揮発性のメモリカード、ROMなどが用いられる。
【0177】
また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、C/C++、perl、Shell、PHP、Java(登録商標)等の広範囲のプログラム又はスクリプト言語で実装できる。
【0178】
さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はCD−RW、CD−R等の記憶媒体に格納し、コンピュータが備えるCPUが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
【0179】
上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
【符号の説明】
【0180】
101 チケット管理サーバ
102 開発リポジトリサーバ
103 リリースリポジトリサーバ
104 プログラム統合管理サーバ
111 開発者端末
112 承認者端末
113 リリース管理者端末
211、251 CPU
212、252 メモリ
213 記憶装置
214、253 NW I/F
215、255 データバス
220 統合管理モジュール
221 入出力モジュール
222 判定モジュール
223 登録モジュール
224 コピー実行モジュール
230 プログラム統合管理情報
254 IO I/F
256 入力装置
257 出力装置
300 チケット管理情報
400 開発リポジトリ管理情報
601、602、603 制御モジュール
図1
図2
図3
図4
図5
図6
図7A
図7B
図7C
図7D
図8A
図8B
図8C
図8D
図9
図10