(57)【要約】【課題】スケジュールに基づき複数種類の環境それぞれへアプリケーションを正しくデプロイできる自動デプロイ方法及び自動デプロイ管理システムを提供する。【解決手段】複数種類の環境それぞれへアプリケーションをデプロイする自動デプロイ方法であって、自動実行のスケジュール登録された実行日付になると、デプロイ処理の実行対象となる前記環境の種類に応じて承認者を特定し、前記特定した承認者の承認結果をチェックして前記デプロイ処理を実行する。【選択図】  図１
2015046004.tif 000002
【特許請求の範囲】
【請求項１】
複数種類の環境それぞれへアプリケーションをデプロイする自動デプロイ方法であって、自動実行のスケジュール登録された実行日付になると、デプロイ処理の実行対象となる前記環境の種類に応じて承認者を特定し、前記特定した承認者の承認結果をチェックして前記デプロイ処理を実行することを特徴とする自動デプロイ方法。
【請求項２】
前記環境の種類に応じて複数の承認者を特定し、前記特定したすべての承認者の承認結果をチェックして前記デプロイ処理を実行することを特徴とする請求項１に記載の自動デプロイ方法。
【請求項３】
前記環境の種類は開発者用試験環境と商用環境を含み、前記環境の種類に応じて異なる承認者を含むように特定し、前記特定したすべての承認者の承認結果をチェックして前記デプロイ処理を実行することを特徴とする請求項１または２に記載の自動デプロイ方法。
【請求項４】
前記アプリケーションに応じて承認者を特定し、前記アプリケーションに応じて特定した承認者の承認結果と前記環境の種類に応じて特定した承認者の承認結果をチェックして前記デプロイ処理を実行することを特徴とする請求項１〜３のいずれか１項に記載の自動デプロイ方法。
【請求項５】
前記アプリケーションと前記環境と前記実行日付をスケジュール登録可能とし、前記スケジュール登録された環境の種類に基づくすべての前記承認者を登録することを特徴とする請求項４に記載の自動デプロイ方法。
【請求項６】
既にスケジュール登録済のデプロイに関する情報を含むカレンダーを表示し、前記カレンダー内で特定される日付を前記実行日付としてスケジュール登録することを特徴とする請求項５に記載の自動デプロイ方法。
【請求項７】
既にスケジュール登録済のデプロイに関する情報を前記承認者へ表示し、前記承認者による前記承認結果を登録可能とすることを特徴とする請求項６に記載の自動デプロイ方法。
【請求項８】
前記デプロイ処理の実行の結果でエラーを検出すると前記デプロイ処理を再実行し、再実行の結果でエラーを検出するとエラーを記録することを特徴とする請求項１〜７のいずれか１項に記載の自動デプロイ方法。
【請求項９】
既にデプロイ済みのアプリケーションの複数のバージョンを表示し、前記複数のバージョンの中の１つのバージョンが特定されると、特定されたバージョンのアプリケーションをデプロイするようにスケジュール登録することを特徴とする請求項５に記載の自動デプロイ方法。
【請求項１０】
複数種類の環境それぞれへアプリケーションをデプロイする自動デプロイ管理システムであって、
デプロイ処理の実行日付と、前記環境の種類と、前記デプロイ処理の実行に対する承認者の承認結果とが登録されるデータベースと、
デプロイされるアプリケーションが格納されるリポジトリと、
前記実行日付になると、前記環境の種類に応じて前記承認者を特定し、前記特定した承認者の前記承認結果をチェックして、前記リポジトリから前記環境へ前記アプリケーションの前記デプロイ処理を実行する自動デプロイワーク処理部と、
を備えたことを特徴とする自動デプロイ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スケジュール機能を用いたアプリケーションの自動デプロイ方法及び自動デプロイ管理システムに関するものである。
【背景技術】
【０００２】
近年、コンピュータの利用が社会インフラの制御など大規模化しており、これにともなってコンピュータのプログラムの開発規模も増加の一途をたどっている。このようなプログラムは１つのものとして開発するには規模が大き過ぎるため、多数のアプリケーション（モジュール）を組み合わせることにより１つのプログラムを構成している。また、多数のアプリケーションは一度に組み合わせることができず、段階的に組み合わせるため、アプリケーションの実行環境も複雑化しており、開発段階毎などの環境や商用環境などが複数存在する。複数の環境の中には開発の途中であり、組み合わせるべき他のアプリケーションの準備が間に合わないため、代替えのアプリケーションを組み合わせる場合もあるし、開発メーカの環境ではアプリケーションを実行するハードウェアが最終的な商用環境のハードウェアとは異なり、使用するハードウェアに応じて商用環境とは異なるアプリケーションを組み合わせる場合などもある。
【０００３】
このように環境の複雑化にともない複数の環境それぞれへアプリケーションを正しくデプロイすることは重要である。担当者の勘違いなどにより本来とは異なるアプリケーションをデプロイして他のアプリケーションと組み合わせられると正しく動作せず、原因の追究に時間のかかってしまうことなどもある。
【０００４】
一方、デプロイに関し、特許文献１、２にはデプロイ先のハードウェア構成などのサーバ環境に適合したＯＳのディスクイメージをサーバへデプロイする技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１２２９６３号公報
【特許文献２】特開２０１１−０７６３７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１、２には環境に応じてデプロイする技術が開示されているものの、環境となるハードウェア構成などは既に履歴などとして記憶されており、この記憶された環境とデプロイ先の環境が一致した場合に、その記憶された環境に対応するディスクイメージをデプロイするというものであって、新たな開発における環境には適用できない。また、ＯＳなどの１つのディスクイメージをデプロイするというものであって、開発スケジュールなどに基づき複数のアプリケーションをデプロイして組み合わせる環境には適用できない。
【０００７】
本発明は、スケジュールに基づき複数種類の環境それぞれへアプリケーションを正しくデプロイできる自動デプロイ方法及び自動デプロイ管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明にかかる自動デプロイ方法は、複数種類の環境それぞれへアプリケーションをデプロイする自動デプロイ方法であって、自動実行のスケジュール登録された実行日付になると、デプロイ処理の実行対象となる前記環境の種類に応じて承認者を特定し、前記特定した承認者の承認結果をチェックして前記デプロイ処理を実行することを特徴とする。
【０００９】
また、本発明にかかる自動デプロイ方法は、前記アプリケーションに応じて承認者を特定し、前記アプリケーションに応じて特定した承認者の承認結果と前記環境の種類に応じて特定した承認者の承認結果をチェックして前記デプロイ処理を実行することを特徴とする。
【００１０】
また、本発明は自動デプロイ管理システムとしても把握される。
【発明の効果】
【００１１】
本発明によれば、スケジュールに基づきデプロイする環境の種類やアプリケーションに応じた承認者の承認結果をチェックしてデプロイ処理を実行するため、各環境へアプリケーションを正しくデプロイできる。
【図面の簡単な説明】
【００１２】
【図１】アプリケーションをデプロイするシステムの構成の例を示す図である。
【図２】ユーザ管理テーブルの例を示す図である。
【図３】スケジュール管理テーブルの例を示す図である。
【図４】タスク管理テーブルの例を示す図である。
【図５】バージョン管理テーブルの例を示す図である。
【図６】スケジュール登録の処理フローの例を示す図である。
【図７】自動デプロイ管理システムへのログイン画面の例を示す図である。
【図８】自動デプロイ管理システムのメイン画面の例を示す図である。
【図９】スケジュール選択画面の例を示す図である。
【図１０】スケジュール登録画面の例を示す図である。
【図１１】スケジュール承認の処理フローの例を示す図である。
【図１２】スケジュール承認画面の例を示す図である。
【図１３】自動デプロイの処理フローの例を示す図である。
【図１４】バージョン変更の処理フローの例を示す図である。
【図１５】環境選択画面の例を示す図である。
【図１６】バージョン選択画面の例を示す図である。
【発明を実施するための形態】
【００１３】
図１を用いて好ましい自動デプロイ管理システム110の概要を説明する。アプリケーション(以下、アプリとする)を対象とする自動デプロイ管理システム110は、アプリ開発を行う開発環境120と、用途の異なる複数の環境を含むデプロイ先環境130との間にネットワーク140で接続され、デプロイ元のアプリリポジトリ116からデプロイ先の各環境（環境Ａ131、環境Ｂ132、環境Ｃ133）へ矢印151のようにアプリデプロイを自動で行うものである。自動デプロイ管理システム110は、アプリのデプロイスケジュール情報、タスク情報及びアプリのバージョン情報を保持する自動デプロイ管理システムデータベース（ＤＢ）111と、このデータベースの情報をもとにアプリリポジトリ116とデプロイ先環境130間のアプリデプロイを自動的に開始する自動デプロイワーク処理部117を有する。
【００１４】
自動デプロイワーク処理部117は例えば一般的なコンピュータでもよく、図示を省略したＣＰＵとメモリとハードディスクやＳＳＤなどの記憶装置とを備え、記憶装置に格納したプログラムをメモリへロードしてＣＰＵが実行することにより、後で図を用いて説明する処理フローを実現する。自動デプロイ管理システムデータベース111とアプリリポジトリ116はハードディスクやＳＳＤなどの記憶装置を含み、自動デプロイワーク処理部117へ読み書き可能に接続される。図１では自動デプロイ管理システムデータベース111とアプリリポジトリ116を自動デプロイワーク処理部117の外部記憶装置として図示したが、自動デプロイワーク処理部117に内蔵の記憶装置としてもよく、自動デプロイワーク処理部117とネットワークで接続した記憶装置などとしてもよい。
【００１５】
自動デプロイワーク処理部117は、自動デプロイ管理システム110が毎日、決められた時刻にデプロイ指示を受けたとき、スケジュール情報及びタスク情報を元にデプロイ対象のアプリ及び環境を特定し、タスク情報を元に承認チェックを行い、デプロイ可否を判断してデプロイ可の場合にデプロイ処理を開始する。自動デプロイワーク処理のスケジュール登録機能は、担当者がデプロイ実行日、デプロイ対象のアプリ及び環境を登録し、登録されたデプロイ対象の環境に応じて承認者をシステム的に登録する機能である。自動デプロイワーク処理のスケジュール承認機能は、スケジュール登録機能でシステム的に登録した承認者が、担当者が登録したスケジュールを承認したり拒否したりする機能である。
【００１６】
自動デプロイワーク処理のデプロイ実行機能は、デプロイ実行日のタスク情報を元に実行すべきタスクの有無をチェックし、スケジュール登録機能で登録した各承認者の承認をチェックしてデプロイ実行を制御する。そして、アプリ情報及びタスク情報をもとにアプリリポジトリに格納されているアプリとデプロイする環境を特定してデプロイ処理を開始する。デプロイ処理が終了するとデプロイした環境のチェックを行い、正常に終了した場合は、バージョン管理情報を更新して対象タスクのステータスを実行済に更新する。エラーが発生している場合はエラーが発生した対象タスクの再実行を行う。再実行後、正常に完了した場合はバージョン管理情報及びタスク情報を更新する。再実行してもエラーが発生した場合はタスク管理のステータスをエラーに更新しデプロイ処理が完了となる。
【００１７】
自動デプロイワーク処理のバージョン管理機能は、環境毎のアプリをバージョン管理情報で保持する特定のバージョンに変更する機能である。変更したい環境、アプリバージョンをスケジュール登録し、自動デプロイワーク処理にてデプロイ処理を実行する。
【００１８】
以上がデプロイ管理システム110の概要であり、デプロイする環境に応じて承認者を割り当て、承認者から承認を受けていることを自動的にチェックできるため、担当者の勘違いなどにより生じる各環境でのアプリの誤ったデプロイを防止できる。
【００１９】
以下、さらに詳しく自動デプロイ管理システム110を説明する。図１に示した自動デプロイ管理システム110は、自動デプロイ管理システムデータベース111と、アプリリポジトリ116と、自動デプロイワーク処理部117とを有する。
【００２０】
自動デプロイ管理システムデータベース111は、複数のデプロイするアプリ情報(対象アプリ、実行日付、デプロイ先環境を示す情報)やデプロイの実行に関する情報(ユーザID、承認可否、実行ステータスなどの情報)を保持するデータ保持部である。アプリリポジトリ116は、例えば開発環境120の担当者端末121で矢印152のようにコミットしたアプリを保持するデータベースである。
【００２１】
ここで、開発環境120は担当者端末121と承認者端末122とから構成される環境である。担当者端末121は開発したアプリをアプリリポジトリ116へコミットしたり、矢印153のようにアプリデプロイのスケジュール登録を行ったりするものである。承認者端末122は矢印154のようにスケジュール登録されたタスクを承認するものである。また、デプロイ先環境130は、用途の異なる複数の端末を備えた環境である。例えば、環境Ａ131はあるシステムの担当者のみが試験する試験用端末、環境Ｂ132は担当者及びシステム提供先の試験者が試験を行える検証用端末、環境Ｃ133は実際にシステムを利用している環境の商用端末からなる環境である。また、各環境に応じて組み合わせるアプリが異なる。例えば、環境Ｃ133では存在する装置を環境Ａ131や環境Ｂ132では用意できない場合、その装置の代用となるアプリをデプロイする必要があり、そのアプリを環境Ａ131や環境Ｂ132にてデプロイしないと正しく動作せず、環境Ｃ133にてデプロイすると実際に存在する装置の動作を妨げる。逆に、環境Ｃ133で存在する装置を動作させるためのアプリは環境Ａ131や環境Ｂ132では不要であり、環境Ｃ133では必要である。このように環境に応じて適切なアプリを正しい組み合わせでデプロイする必要がある。
【００２２】
自動デプロイ管理システムデータベース 111は、ユーザ管理テーブル112、スケジュール管理テーブル113、タスク管理テーブル114、バージョン管理テーブル115を有する。ユーザ管理テーブル112はユーザに関する情報を管理するテーブルであり、図２に示すように、ユーザ名201 (ああ いい、・・・)、ユーザID 202 (A001、・・・)、パスワード203 (ABCD、・・・)、権限204 (担当者、承認者)などの各情報を有する。これによりユーザ毎のパスワードと権限が管理される。
【００２３】
スケジュール管理テーブル113は、アプリデプロイ実行のスケジュール情報を管理するテーブルであり、図３に示すように、デプロイの実行日付301 (2013/3/1、・・・)、デプロイ対象のアプリ302 (XXXXXX、・・・)、デプロイ先環境303 (環境Ａ、・・・)、デプロイをスケジュールに登録したユーザID 304(A0001、・・・)、デプロイを実行するタスクの番号305 (1、２、・・・)などの各情報を有する。このスケジュール管理テーブル113の情報に基づいて自動デプロイワーク処理部117が次に説明するタスク管理テーブル114を作成する。
【００２４】
タスク管理テーブル114は、スケジュール登録された情報をもとに作成されるタスク情報を管理するテーブルであり、図４に示すように、実行日付401 (2013/3/1、・・・)、タスク番号402 (1、２、・・・)、デプロイ先環境403 (環境Ａ、・・・)、承認者1 404(A0002、・・・)、承認者１ 404の承認結果405 (承認済、未承認、・・・  図４では済と未で示す)、承認者２ 406 (T0004、NULL、・・・図４ではNULLを横棒で示す)、承認者２ 406の承認結果407 (NULL、承認済、・・・)、承認者３ 408 (V0005、・・・)、承認者３ 408の承認結果409 (承認済、・・・)、デプロイの実行状態(ステータス)410 (実行済、未実行・・・図４では済と未で示す)などの各情報を有する。このタスク管理テーブル114をもとに、図１３などを用いて後で説明する自動デプロイ処理において、デプロイ先環境の特定、対象アプリの特定、承認チェックなどに利用する。
【００２５】
バージョン管理テーブル115は、デプロイの実行日付とデプロイ先環境毎にアプリのバージョンを管理するテーブルである。図５に示すように、実行日付501 (2013/3/1、・・・)、アプリ502 (XXXXXX、・・・)、デプロイ先環境503 (環境Ａ、・・・)、アプリのバージョン504 (0002、・・・)などの各情報を有する。このバージョン管理テーブル115をもとに、図１４などを用いて後で説明するバージョン変更登録を行う。
【００２６】
図６はアプリ自動デプロイのスケジュール登録の処理フローの例を示す図である。担当者端末121からアプリデプロイのスケジュール登録のために、自動デプロイ管理システム110へユーザIDとパスワードを入力してログインを行う(ステップ601)。このログインのための操作は、例えば図７に示したログイン画面701を使用する。ログイン画面701はユーザID 702、パスワード703、ログインボタン704を含み、ユーザIDとパスワードを入力可能とし、またログインボタン704の押下によりログインを自動デプロイ管理システム110へ通知できる。なお、ログイン画面701は担当者端末121のディスプレイ画面の全面に表示してもよいし、ディスプレイ画面内の１つのウィンドウとして表示してもよい。ログインボタン704を押下すると、自動デプロイ管理システム110はログイン画面701で入力されたユーザID 702とパスワード703が予め登録された正しいものであるかを確認してログインさせるか否かを判定する(ステップ602)。
【００２７】
その判定(ステップ602)の結果、予め登録されたものではなく、ログインさせない場合(否の場合)には、自動デプロイ管理システム110のログイン(ステップ601)へ戻り、ユーザID 702とパスワード703を再度入力可能にする。
【００２８】
また、ログインさせる場合(可の場合)、ログイン画面701から図８に示すメイン画面801へ遷移する。メイン画面801はスケジュール選択ボタン802、承認登録ボタン803、バージョン変更ボタン804の３つの作業を選択可能とするボタンを備え、ここではメイン画面801におけるスケジュール選択ボタン802の押下に応じて、図９に示すスケジュール選択画面901に遷移する。承認登録ボタン803については図１１など用いて後で説明し、バージョン変更ボタン804については図１４などを用いて後で説明する。スケジュール選択画面901はスケジュールの日付を選択するための画面であり、カレンダーとなっている。スケジュール選択画面901の最上欄は曜日であり、最上欄以外の各欄の左上は日付である。各欄には既に登録されたスケジュールが表示され、特定の日付を押下すると押下された日付が選択されて新たなスケジュールを登録できる。スケジュール選択画面901においてデプロイしたい日付を選択すると図１０に示したスケジュール登録画面1001へ遷移する。
【００２９】
図１０は、図９で2013/3/2の日付を選択した例であり、スケジュール登録画面1001において、選択されたデプロイの実行日付1002が表示され、デプロイ対象となるアプリ名1003とデプロイ先の環境名1004を入力可能として、登録ボタン1005を押下可能とする。デプロイしたいアプリ及びデプロイ先環境を入力して登録ボタン1005を押下することによりスケジュール登録を行う(ステップ603)。スケジュール登録(ステップ603)では、選択された実行日付1002、入力されたアプリ名1003と環境名1004、ログインしているユーザID 702をスケジュール管理テーブル113の実行日付301などへ登録し、デプロイ処理のタスクの番号305を割り当てる。タスク番号305は例えば同じ実行日付301のデプロイ処理を識別するための番号であり、図３では同じ実行日付301においてシリアル番号を割り当てているが、これに限定されるものではなく、複数のデプロイ処理のタスクを識別できればよい。
【００３０】
スケジュール登録(ステップ603)が完了すると、登録されたスケジュール管理テーブル113の環境情報に基づいて承認者を登録する。例えばデプロイ先の環境が環境Ａ131の場合は承認者１登録(ステップ605)へ。環境Ｂ132の場合は承認者１、２登録(ステップ606)へ。環境Ｃ133の場合は承認者１、２、３登録(ステップ607)へというようにデプロイ先の環境に応じた承認者の登録処理を行う(ステップ604)。
【００３１】
承認者１登録(ステップ605)の処理は、スケジュール管理テーブル113の実行日付301、デプロイ先環境303、タスク番号305の情報をもとにタスク管理テーブル114の実行日付401からデプロイ先環境403までを作成する。また、スケジュール管理テーブル113のデプロイ先環境303とユーザID 304などに応じてタスク管理テーブル114の承認者１ 404と承認結果405のみを登録し、承認者２ 406から承認結果409までは登録しない、あるいは登録しない代わりにNULLを登録する。ステップ605では承認結果405へ未承認を登録する。また、デプロイ処理の実行状態410に未実行と登録を行う。
【００３２】
承認者１、２登録(ステップ606)の処理もスケジュール管理テーブル113の情報をもとにタスク管理テーブル114を作成する。ただし、承認者２ 406を含めてタスク管理テーブル114の承認者１ 404から承認結果407までを登録し、承認者３ 408と承認結果409には登録しない。ステップ606では承認結果405、407へ未承認を登録する。また、実行状態410に未実行と登録を行う。
【００３３】
承認者１、２、３登録(ステップ607)では、スケジュール管理テーブル113の情報をもとにタスク管理テーブル114を作成する際に、承認者３ 408を含めてタスク管理テーブル114の承認者１ 404から承認結果409までを登録する。ステップ607では承認結果405、407、409へ未承認を登録する。また、実行状態410に未実行と登録を行う。
【００３４】
登録する承認者に関し、例えば、環境Ａ131、環境Ｂ132、環境Ｃ133において、ユーザID 304がA0001の担当者がスケジュールを登録した場合、A0001の所属するグループの管理者であるユーザID 202がA0002を承認者１ 404へ登録する。同様に、ユーザID 304がB0001の担当者についてはグループの管理者であるB0002を承認者１ 404へ登録する。また、環境Ｂ132と環境Ｃ133において、承認者２ 406はプロジェクトにおける開発統括リーダとなるユーザID 202 であるT0004を承認者２ 406へ登録する。環境Ｃ133において、承認者３ 408はプロジェクト全体を統括するリーダとなるユーザID 202であるV0005を承認者３ 408へ登録する。なお、ここでは承認者１ 404として担当者の属するグループの管理者としたが、図３に示したように担当者とアプリとが１対１に対応する場合は担当者の属するグループとアプリの属するグループとは同じであり、担当者のユーザID 304ではなくアプリ302に対応する管理者などとしてもよい。また、開発統括リーダと全体を統括するリーダもこれらに限定されるものではなく、各環境に責任のある者が承認者となってもよいし、各環境の重要度に応じた承認者となってもよい。さらに、承認者１ 404として複数の承認者を登録可能とし、環境Ａ131に関する管理者全員を登録してもよく、担当の異なるグループあるいはアプリに関する承認者を登録し、承認しない場合はすべての担当者へ通知してもよい。これにより、承認者は自分の担当以外を相互にチェックすることができ、デプロイすべきアプリの漏れを防止できる。
【００３５】
図１１は、担当者により登録されたスケジュール情報に基づくデプロイ実行の承認可否を設定するスケジュール承認の処理フローの例を示す図である。まず、承認者端末122からスケジュール承認のために自動デプロイ管理システム110のログイン画面701においてユーザID 702及びパスワード703を入力し、ログインボタン704を押下してログインを行う(ステップ1101)。ログインボタン704を押下すると、自動デプロイ管理システム110はログイン画面のユーザID及びパスワード確認してログインさせるか否かを判定する(ステップ1102)。その判定の結果、ログインさせない場合(否の場合)には、自動デプロイ管理システム110のログイン(ステップ1101)へ戻る。
【００３６】
また、ログインさせる場合(可の場合)、ログイン画面701からメイン画面801へ遷移する。メイン画面801において承認登録ボタン803が押下されたことに応じてスケジュール承認画面1201に遷移する。スケジュール承認画面1201において表示されるスケジュール情報を確認して承認または却下の決定が行なわれる(ステップ1103)。スケジュール承認画面1201は、例えば図１２に示すように、ステップ1101でログインした承認者のユーザID 1202、登録者である担当者ユーザID 1203、実行日付1204、アプリ名1205、環境名1206などの登録情報が表示され、承認ボタン1207と却下ボタン1208の押下を可能とする。ここで、アプリ名1205を複数にしてもよい。例えば、図３、４に示した2013/3/2のデプロイについて環境Ｂ132における２つのアプリXXXXXXとVVVVVVを並べて表示し、承認者２ 406であるT0004が２つのアプリのデプロイされることを確認して承認できる。
【００３７】
ステップ1103において承認ボタン1207が押下されると、タスク管理テーブル114の承認結果405、407、409の対応する項目を未承認から承認へ更新する(ステップ1104)。また、ステップ1103において却下ボタン1208が押下された場合は、タスク管理テーブル114の承認結果405、407、409のいずれも更新されず、未承認のままとなる。
【００３８】
なお、ステップ1102の後で図９に示したスケジュール選択画面901を表示し、選択された日付が実行日1204となるスケジュール承認画面1201を表示してもよいし、ステップ1101で入力されたユーザID 702とタスク管理テーブル114内の承認者１ 404、承認者２ 406、承認者３ 408との一致するスケジュール承認画面1201を表示してもよい。また、実行日付401より所定日だけ前に承認結果405、407、409へ承認していない承認者に対してメールなどにより承認の依頼を通知してもよい。
【００３９】
図１３は自動デプロイ処理のフローの例を示す図である。毎日決められた時刻に自動デプロイ管理システム110が図１３に示したデプロイ処理を自動的に開始する。まず、デプロイ処理を開始した日付のタスクがタスク管理テーブル114に存在するかチェックを行う(ステップ1301)。タスクが存在しない場合はデプロイ処理が終了する。
【００４０】
タスクが存在する場合はタスク管理テーブル114の対象タスク情報をもとに承認者１404の承認結果405が承認であるか未承認であるかのチェックを行う(ステップ1302)。未承認の場合はタスクチェック(ステップ1301)へ戻り、他のタスクが存在するかをチェックする。ここで未承認の場合に担当者など指定された者へ未承認であることをメールなどにより通知してもよい。承認の場合はタスク管理テーブル114の対象タスク情報をもとに承認者２ 406が存在するかNULLであるかをチェックし、承認者２ 406が存在する場合は承認結果407が承認または未承認かのチェックを行う(ステップ1303)。未承認の場合はタスクチェック(ステップ1301)へ戻り、他のタスクが存在するかをチェックする。承認者２ 406がNULLまたは承認結果407が承認の場合はタスク管理テーブル114の対象タスク情報をもとに承認者３ 408が存在するかNULLであるかをチェックし、承認者３ 408の承認結果409が承認または未承認かのチェックを行う(ステップ1304)。未承認の場合はタスクチェック(ステップ1301)へ戻り、他のタスクが存在するかをチェックする。  承認者３ 408がNULLまたは承認結果409が承認の場合はタスク管理テーブル114の対象タスク情報をもとにデプロイ先環境403を取得する(ステップ1305)。
【００４１】
そして、タスク管理テーブル114の実行日付401とタスク番号402に一致するスケジュール管理テーブル113の実行日付301とタスク番号305に対応するアプリ302を取得し、アプリリポジトリ116の中の取得したアプリ302の格納位置を特定する(ステップ1306)。デプロイ元のアプリリポジトリ116の特定された格納位置からデプロイ先環境403に対応するデプロイ先環境130内の環境Ａ131、環境Ｂ132、または環境Ｃ133へのデプロイ処理を行う(ステップ1307)。
【００４２】
ステップ1307のデプロイ処理が完了したら、デプロイ処理によるシステム的なエラーが発生していないか確認を行う(ステップ1308)。エラーが発生しておらず正常にデプロイ処理が完了していた場合はバージョン管理テーブル115へバージョン504などを追加して更新を行う(ステップ1310)。エラーが発生していた場合はデプロイ回数が１回目か２回目かを判定する(ステップ1309)。１回目の場合は、デプロイを再実行する為にデプロイ処理(ステップ1307)へ戻り、デプロイ処理を実行する(ステップ1307)。２回目の場合は、デプロイ再実行を行わず対象タスクのステータス更新(ステップ1311)へ遷移する。
【００４３】
デプロイが正常に完了してステップ1310から遷移してきた場合は、タスク管理テーブル114の実行状態410を実行済に更新し、デプロイにエラーが発生しておりステップ1309から遷移してきた場合は、実行状態410をエラー完了に更新する(ステップ1311)。ステップ1301において対象となったタスクすべてのデプロイ処理が完了したら自動デプロイ処理を終了する。
【００４４】
アプリのバージョン管理については、例えば図５に示すデプロイ先環境503のアプリ502毎に４つまでのバージョンをアプリリポジトリ116に保持する。実行日付501が2013/3/1にデプロイ先環境503の環境Ａ131へ新たにデプロイされたアプリ502がXXXXXXのバージョン504を0001と登録する。実行日付501が2013/3/5に同じ環境である環境Ａ131、同じアプリであるXXXXXXがデプロイされたら、2013/3/1の既存のXXXXXXのバージョン504へ１加算して0002と更新し、2013/3/5のバージョン504を0001とする。すなわち、最新のXXXXXXのバージョン504を0001とする。この際、バージョン504を0004まで保持していた場合は最も古い0004のアプリをアプリリポジトリ116から削除する。
【００４５】
図１４は、以前にデプロイしたアプリのバージョンへ変更するバージョン管理処理のフローの例を示す図である。担当者端末121からアプリのバージョン変更のために自動デプロイ管理システム110のログイン画面701においてユーザID 702とパスワード703入力してログインを行う(ステップ1401)。ログインボタン704が押下されると、自動デプロイ管理システム110はログイン画面701のユーザID 702とパスワード703を確認してログインさせるか否かを判定する(ステップ1402)。その判定の結果、ログインさせない場合(否の場合)には、自動デプロイ管理システム110のログイン(ステップ1401)へ戻り、ユーザID 702とパスワード703を再度入力可能にする。
【００４６】
また、ログインさせる場合(可の場合)、ログイン画面701からメイン画面801へ遷移する。メイン画面801においてバージョン変更ボタン804が押下されると環境選択画面1501に遷移する。図１５に示す環境選択画面1501において、アプリのバージョンを変更したいデプロイ先環境を選択させる(ステップ1403)。環境選択画面1501は、例えば図１５に示すように、環境Ａボタン1502、環境Ｂボタン1503、環境Ｃボタン1504の押下を可能とする。
【００４７】
デプロイ先環境が選択されると図１６に示すバージョン選択画面1601へ遷移し、バージョン変更のためのデプロイ実行の日付を入力し、変更後のバージョンを選択可能とする(ステップ1404)。バージョン選択画面1601にはバージョン管理テーブル115に基づきバージョンを含むアプリに関する情報1602を表示する。ここでは、環境選択画面1501において環境Ａ131を選択し、環境Ａ131についてのみ表示する。また、アプリとしてXXXXXXのみを表示するが、XXXXXX以外を表示してもよいし、予めXXXXXXを選択させてもよい。そして、バージョン変更実行日付1606へバージョン変更のためのデプロイ実行の日付を入力させ、登録ボタン1603から1605のいずれかが押下されることにより、登録ボタン1603から1605に隣接して表示されたバージョンへデプロイ処理するようにスケジュール登録される。ステップ1405における処理は既に図６を用いて説明したスケジュール登録処理であるので、説明を省略する。そして、バージョン変更実行日付1606へ入力された日付に図１３を用いて説明したデプロイ処理が実行される。
【００４８】
以上で説明したように、デプロイする環境などを指定するだけでデプロイする環境に応じて複数の承認者を登録できるため、受けるべき承認の漏れを防止することができる。そして、デプロイ処理実行時に承認者の承認をチェックできるため、承認の得られない誤ったデプロイを防止できる。また、以前にデプロイしたバージョンへ簡単な操作で戻す登録ができ、この場合でも承認者の承認をチェックできるため、承認の得られない誤ったバージョンへ戻すデプロイを防止できる。
【符号の説明】
【００４９】
110  自動デプロイ管理システム
111  自動デプロイ管理システムデータベース
112  ユーザ管理テーブル
113  スケジュール管理テーブル
114  タスク管理テーブル
115  バージョン管理テーブル
116  アプリリポジトリ
117  自動デプロイワーク処理部
120  開発環境
121  担当者端末
122  承認者端末
130  デプロイ先環境
131  環境Ａ(例えば、開発者用試験環境)
132  環境Ｂ(例えば、システム提供先試験用環境)
133  環境Ｃ(例えば、商用環境または本番環境)
【図１】
2015046004.tif 000003
【図２】
2015046004.tif 000004
【図３】
2015046004.tif 000005
【図４】
2015046004.tif 000006
【図５】
2015046004.tif 000007
【図６】
2015046004.tif 000008
【図７】
2015046004.tif 000009
【図８】
2015046004.tif 000010
【図９】
2015046004.tif 000011
【図１０】
2015046004.tif 000012
【図１１】
2015046004.tif 000013
【図１２】
2015046004.tif 000014
【図１３】
2015046004.tif 000015
【図１４】
2015046004.tif 000016
【図１５】
2015046004.tif 000017
【図１６】
2015046004.tif 000018