非表示を設定します。
マイグレーション
次にマイグレーションを作成します。今回必要になるのはデプロイの履歴を表現するモデルです。名前はDeployHistoryとしましょう。
DeployHistoryモデルは関連モデルに以下の3つを持たせます。
- デプロイ時のプロジェクト
- デプロイを実施したユーザ(ボタンを押した人)
- デプロイ時のチェンジセット
他にもデプロイ開始時刻や終了時刻、実行結果などの属性を持たせます。
一通り作成したらmigrateを実行します。
モデルの実装
続いてモデルです。関連と終了ステータスの名前だけを書いたシンプルなコードです。
デプロイ履歴画面の実装
さて、まずはデプロイの履歴画面を実装していきましょう。始めにコントローラとビューのファイルを作成します。コントローラの名前はdeployments、履歴画面はindexアクションとしました。
コントローラから実装していきます。
プロジェクト配下では@projectインスタンス変数が必須になる為、URLで渡されたプロジェクトIDからProjectモデルのインスタンスを取得し、@projectインスタンス変数にセットしています。基本的にすべての画面で必要になるため、before_filterで記述しています(①)。
次にビューの実装です。デプロイボタンがあること以外は前回とほぼ同様のコードになっています。デプロイを実施するアクション名はdeployとしました。
デプロイコマンドの実装
では核心のdeployアクションに入りましょう。このアクションでチケットのステータスの確認や、履歴の保存などを行います。
だいぶ長いコードになりました。順々に説明していきます。
まず、①では実装完了ステータスのチケットがあるかどうかをチェックし、ある場合にはエラーメッセージをflash領域に格納してリダイレクトしています。flashには値を入れておけばRedmineが自動でレンダリングしてくれます。あらかじめ準備されているキーはerror, warning, noticeの3つで、それぞれデザインが変わります。
②では履歴の保存用にリポジトリの最新リビジョンを取得しています。注意しなければならないのは、Redmineではリポジトリとの同期を定期的に行っているわけではなく、リポジトリ画面にアクセスした際に同期している、という点です。つまり、リポジトリ画面にアクセスしていない場合はRedmine上のリポジトリデータが古い可能性があります。そのため、Repository#fetch_changesetsメソッドを呼び、最新の情報に更新しています。
③, ④ではデプロイの実施と前後の処理時間を取得しています。Linuxのコマンドを実行しているだけなのでcapistranoである必要性は特になく、自作のシェルスクリプトでもかまいません。
そして⑤で履歴を作成し、⑥で完了メッセージをflashに格納し、indexアクションにリダイレクトします。
まだデプロイしてもアクティビティへ表示されるようにはなっていませんが、とりあえずコアな部分はできました。デプロイ!ボタンを押して、実際に動くことを確認してみましょう。
また、ログなどを表示するデプロイ履歴の詳細画面の作成については今回は省略します。Redmineとは関連しない画面なので、前回のステータスの変更履歴画面と同じように実装すれば問題なく作れるかと思います。
アクティビティへの表示
さて、晴れてRedmine上からデプロイができるようになり、そのログも確認できるようになりました。デプロイはコミットやWikiの更新などと同様にプロジェクトへ加える変更となりますから、デプロイした際にはアクティビティに表示されるようにしてみましょう。
アクティビティ機能はメニューなどと同様にプラグインから利用する事が可能ですが、やや手間がかかります。具体的には以下の2つの作業が必要です。
- アクティビティの提供元となるモデルを指定する
- モデルに対してアクティビティを生成するための共通インターフェースを実装する
今回はもちろんDeployHistoryモデルが提供元です。
まず、提供元となるモデルはinit.rbで定義します。activity_providerというメソッドで、アクティビティの名前とモデルのクラス名を指定します。
次にモデルで実装する共通インターフェースですが、これはacts_as_activity_providerとacts_as_eventという2つのクラスメソッドで実装します。acts_as_activity_providerではアクティビティの取得処理を、acts_as_eventでは表示内容を定義しています。
①ではfind_optionsにprojectを指定しています。アクティビティの検索条件にはプロジェクトのIDが含まれるため、必ずincludeに指定する必要があります。
これで完了です。再起動してアクティビティを見ると、先ほどデプロイした際の履歴が追加されているはずです。実はRedmineのアクティビティはそれ専用のテーブルが用意されているわけではなく、提供元となっている複数のモデルからレコードを取得し、それらを内部でマージする実装になっています。ですので、アクティビティを有効にする前のオペレーションでも表示される、というわけです。
おわりに
今回はContinuousDeploymentの開発を通して、チケットのステータスの取得やアクティビティへの表示、リポジトリの操作など、Redmineのビルトインの機能をプラグインから利用する、ということを解説しました。
ちなみにデプロイやビルドとRedmineとの連動、と言うことであればHudsonというCIサーバとRedmineを連動させるプラグインが既にリリースされています(リンク)。ですが、CIサーバの導入はわりとヘビーな話になりますし、既にcapistranoや自作のシェルスクリプトで運用している現場にとってはまずはこうして自作のプラグインから始める、というのは気軽で選択肢の一つとしてあってよいかと思います。
最終回となる次回はプラグイン開発の落ち穂拾いと、社内用プラグイン開発のススメ、と言う開発とはちょっと離れた内容についてお話したいと思います。どうぞお楽しみに。