「クラウドのメリットを一番享受できるのは、個人開発者、ソーシャルアプリ開発企業、IT系ベンチャー企業」

小さく・安く・始めて、成長に合わせてサービスレベルを向上させることが出来るクラウド・コンピューティングはそのような企業にとって大きなメリットがあると考えています。

クラウドは、開発環境、本番環境のインフラ、スケールアップ、運用負荷軽減を低リスクで担保できるサービスになっています。これからのアプリ開発でははじめるときにハードウェアのことをほとんど考えなくて良くなる、と言えます。

サービス提供者の役割によるメリットを簡単にまとめると、

経営者

  • システムの投資の無駄を排除 →「所有」から「利用」
  • 求めるサービス提供のためのハード購入費用がかからない
  • 素早いサービス立ち上げ

開発者

  • 開発環境の迅速な構築
  • スケールアップ・可用性向上
  • 本番リリースに向けたサーバ規模の設計を軽減
  • 負荷分散

運用者

  • 利用状況に応じた柔軟なリソース割当
  • システム運用負荷の軽減
  • ハード障害から解放(自前に比べて…

数年前まではデータセンターを借りて自前のハードを用意するか、ホスティングサービスを利用するかが一般的だったと思います。最近はクラウドを使うことで低コストでストレスなく(ハードの面倒を見る必要なく)始めることが出来る。スタートするときの敷居が低くなることはアプリケーションベンダーにとっては良いことです。
2,3年のスパンで見た場合、クラウドよりコスト面でメリットがあるサービスもありますがソーシャルアプリ・ソーシャルゲームに限ればベストなソリューションではないでしょうか。

新しいサービスをすばやく提供するために、その時、そのタイミングで最適なサービスを積極的に利用していきたいですね。

 

ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。
最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。
実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。

インフラ構築に使える10個のチェックリスト

  1. 必要なときにスケールアウト、スケールアップができるか
  2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
  3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか
  4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか
  5. メンテナンス時間を最小化できるか
  6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか
  7. サーバの状態を常に把握できているか(全体PV、各ページPV,日毎、時間毎)
  8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか
  9. バックアップ・リカバリの方法は確立されているか
  10.  監視用アプリケーションは正しく、漏れなく設定されているか

 

1. 必要なときにスケールアウト、スケールアップができるか

自前でマシンを用意する場合、ある程度余裕を持ったインフラを構築しておきたいものです。しかし多くのサービスでは必要最小限ではじめたい。という声があるのも確かです。(予算もありますし)

これがクラウドサービスを利用した場合、クラウドの一番のメリットと言える内容です。それぞれの意味を把握しておくと良いことがあるかもしれません。

  • スケールアウト(Scale Out) ・・・ 稼働する仮想サーバの台数を増やす機能
  • スケールアップ (Scale Up)・・・ 稼働するサーバ1台の性能をあげる

多くのクラウドサービスではこのスケールアウト、スケールアップは対応しています。その方法については開発しているサービスに合わせて手順書化しておくことがベストです。

ref:クラウドでよく言われる「スケールアウト」の反対の言葉って何だろう?

2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか

障害対応やバグ対応でもっとも大切なことは「障害が発生したときの原因を突き止めること」です。

問題が分かってしまえば解決するための対策を行うことはそんなに難しいことではないですし、いつ解決するのかを見積もることも比較的容易に出来ます。インフラを構築する時は、この原因を突き止めるための材料(ログ、発生手順、システムの挙動、エビデンス)をできるだけ多く、楽に集める仕組みが必要ということを意識して、インフラを構築するべきです。

3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか

多くのシステムでは有料、無料を問わず、使い慣れた監視システムやパッケージ等のソフトウェアを導入していると思います。監視システムにより障害を検知し、関係者にアラートできることは当たり前ですが、障害発生後の

  • 1次受付け
  • 問題の切り分け
  • 判断をする役割、管理者の判断の有無(ビジネス上の)
  • 担当者割当

が重要になります。障害が発生したときは、少なからず現場が混乱した状態になることが考えられますので落ちついて対処するためのルールやマニュアルを問題が起こる前に決めておくべきです。

4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか

アプリケーションの性質に合わせて、特にOS、ミドルウェアの設定は本番サービス開始までに必ず見直しをするべきです。
Apacheの設定ファイルやPHPの設定ファイルが環境によって異なっていたり、開発環境の設定になっている場合がよくありますので注意が必要です。Web#1とWeb#2は同じ役割のはずがApacheの設定やPHP.iniの設定が違う・・・は避けたいですね。

5. メンテナンス時間を最小化できるか

システムを長時間稼働させるように構成されたシステムにおいても、メンテナンスは多くのサービスで必要になります。ソーシャルゲームの場合、メンテナンス中は利用者が「アクセスすることが出来ない = 売上がない」、状態であるため可能な限りメンテナンス時間を最小化させる方法を考えるべきです。

  • メンテナンス中に実施している作業は本当に必要なのか・・・サービス停止しなくても良いのでは?
  • 夜間等のバッチ処理でできるのではないか
  • ジョブの順番や時間帯の変更は可能か

等の今より最適化することは常に考える必要があります。可能なら無停止アップデートができるのかを検討すべきです。

6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか

ウェブアプリケーションやソーシャルアプリでは、Apache、MySQL等のミドルウェアのログ、システムログ、アプリケーションログと見なければいけないログが散らばっており、さらにサーバによっても分散していると思います。開発や運用に多くの情報とヒントを提供するものがこのログファイルです。ログファイルをいつでも、すぐに参照できるように管理(集約、集計)することはとても重要です。

サービスが運用フェーズに入った段階でも、警告やエラー情報、タイムアウト等の異常をすぐに見つけ、原因を探す糸口として活用できるようになっているのかをチェックします。

7. アクセスの状態を把握できているか(全体PV、ページPV、日毎、時間毎、リソース)

サービス提供しているウェブサイトのアクセス解析を導入しているのか、また導入済みのアクセスログから自分たちに必要な数字を把握できているのかはとても重要なことです。直接利用者の動向を把握することが出来るツールになるため、自サイトのターゲットと実際の利用者の行動を把握するために活用できるような仕組みになっている必要があります。

8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか

Webアプリケーションの場合、役割によってサーバを分けたりパフォーマンス向上のために分割したり、をよくやります。ボトルネックになりやすいDB(マスタ)やスレーブDB等、機能の明確化をメモ書きしておくことで

  • システムの全体像を把握したり、
  • 将来の拡張性を考える
  • 運用保守の補助資料として利用
  • チーム内で情報共有(どのようなインフラになっているかを説明出来る)

ができます。役割分担(機能分担)を明示することはとても重要になります。

ソーシャルアプリ開発プラットフォーム(クラウド環境)
ソーシャルアプリ開発プラットフォーム(クラウド環境)/開発・ステージング環境

9. バックアップ・リカバリの方法は確立されているか

アプリケーションやDBのバックアップを実施することは比較的容易に出来るのですが、

  • リカバリにどれくらいの時間が必要なのか、
  • 正常にリカバリできるのか

ということは問題になるのではないでしょうか。

バックアップ・リカバリについては本番機と同等のマシンでリハーサルを実施しなければ正確なリカバリ時間や問題点は見えてこない場合が多々あります。(見積だけでは理想値になりやすく、試験をしない場合、障害が起こったときに想定外のトラブルや取り返しの付かない問題が発生すると考えるべきです。)
どうしても開発中は開発が優先されるため、バックアップ・リカバリは後回しにされる場合がありますが、利用者データや自分たちのシステム保全はとても大切なことなので実際にやってみることはとても重要になります。それが運用マニュアルとして記録されているとベストです。

 

10. 監視用アプリケーションは正しく、漏れなく設定されているか

システムのリソースやサービス監視用の専用ツールはとても高機能で便利に利用しているサイトが多くあります。自分たちのアプリケーション特性にあったチューニングや設定ファイルになっているのかを確認すべきです。デフォルトのままというありがちなミスをしないように注意する必要があります。

 

ソーシャルアプリ、ソーシャルゲーム開発のプラットフォームを構築するインフラエンジニアは表に立って活躍する目立つ存在ではありませんが、縁の下の力持ちな人材です。ソフトウェア開発期間よりももっと長い期間、運用を支える大切な基盤環境を構築しなければいけません。
インフラに関する10個のチェックリストをあなたの開発チームでも確認してみてください。
これ以外にも大切なチェックはあると思いますので教えてもらえればインフラエンジニアのスキルアップに繋がりますのでご意見をお待ちしています。

 

ソーシャルアプリ・モバイルアプリケーションの開発環境や支える技術についてご紹介。
ソーシャルアプリとは、mixi、mobageやGREEなどのSNSプラットフォーム上で動作するアプリケーションです。
2009年末頃から各SNSプラットフォームのオープン化が進められ、外部開発者でもアプリケーションを開発し、SNSに登録されている多くのユーザに対して公開できるようになっている。数千万人という会員をもつプラットフォームに公開が可能になることで、労せずに大量のユーザに利用してもらえる可能性が高い。
また、これまでのコンシューマ向けのゲームやECサイトと違い、SNSの利点を活用したコミュニケーションを重視していることが特徴の1つになっている。

ビジネスとして考えた場合、

  • 大量のユーザにリーチ
  • 少ない投資で開発が可能
  • その上で大きな成功の可能性あり

など、良いことだけを挙げると一日でもはやく始めたいと思うかもしれないが、そんなに簡単ではないことは承知の通り。
開発者から見たソーシャルアプリ開発で重要だと思われる点は

  1. 競合が多いく、早いリリースが必要 → 開発の効率化
  2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える → インフラ・維持費
  3. クチコミ等、一気にユーザが増えた場合のスケールアップ → インフラ・スケールアップ
  4. 利用者に向けたイベント、日々サイト更新必須 → サービス運営・ソフトウェアライフサイクル

 

1. 競合が多く、早いリリースが必要(開発の効率化)

ciklone(サイクロン)を利用しているお客様で携帯向けやスマートフォン開発されている企業様から話を聞いたり、開発者と話をすると、数名~5,6名の開発チームで2,3ヶ月くらいの期間でリリースとなる場合が多いようです。
開発の効率化について実践していることは

  • Ruby/PHP/Python等フレームワークを利用
  • 開発環境の仮想化・チーム内で共通化
  • バージョン管理システムとバグ管理システムの利用
  • 開発拠点の分散に対応したコミュニケーションツール・情報共有ツールの利用

などがあります。ソーシャルアプリを開発している企業の傾向がベンチャーというのもあるかもしれませんが…

2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える

初期費用で一番コストがかかるのがサーバ費用やデータセンター費用(人件費以外で)。この費用は売りあげゼロでも確実に必要になる費用です。多くの企業でインフラに関する部分は8,9割がクラウドサービスを利用されているようです。最近は国内クラウドサービスも増えてきており、日本語でのサポートや情報が充実しています。

  • GMOクラウド http://www.gmocloud.com/
  • ニフティクラウド http://cloud.nifty.com/
  • Amazon EC2 http://aws.amazon.com/jp/ec2/

 

3. クチコミ等、一気にユーザが増えた場合のスケールアップ

自分たちのアプリケーションのユーザが増えることはとてもうれしいことですが、不測のアクセス増加(それも何十倍)が起こった場合には

  • ハードウェアの増強 – Webサーバを増やす、キャッシュサーバを増やす、DBサーバを増やす
  • アプリケーションのチューニング

などの対応が必要になります。ここでもクラウドによる大きなメリットがあり

  • スケールアップが容易
  • 一気に増える時間帯、特定の日のみサーバ数を増やすなどの柔軟な対応

が可能です。
開発期間中に高トラフィックを発生させ負荷試験を実施したり、チューニングをすることがとても重要です。わかっていても現実のタイトなスケジュール内ではその時間と人材を確保することが難しいのが現実です。

4. 利用者に向けたイベント、日々のサイト更新必須

ソフトウェアやソーシャルアプリは開発期間よりも運用期間の方が長いことが通常だと思います。特にソーシャルアプリの場合、既存のユーザが飽きないように次から次へと新しいキャンペーンやイベントを行っています。
あるソーシャルゲームサイトでは、朝、前日のアイテム課金結果をみてよく売れている傾向から、その日の夕方には傾向に沿った新アイテムをリリースしたり。週替わり、月替わりのタイミングでイベントを実施したりしています。小さな改善だけではなく、コアなシステムに影響のある変更までユーザ動向に合わせた改善が日々くり返されています。

これは

  • 複数サーバの安定した運用
  • 複数サーバ(数台~数十台)に確実にリリースするデプロイ管理
  • 24時間のサーバ、サービス監視
  • ログの解析、ログの視覚化
  • デザイン・素材・プログラムのバージョン管理
  • 不測の事態と前兆を教えてくれるアラートシステム

 

ソーシャルアプリ開発では提供するサービスだけではなく、バックエンド側にも高度な技術力が必要とされます。
すべての環境が満足できるレベルまで整備されたプロジェクトが理想ですが、そのようにできない場合が多いのではないでしょうか。
技術者のスキルによりカバーできる部分とできない部分を見極め、あなたのチームに最適な環境を見つけてください。
そのための開発方式やインフラ技術について情報提供していきたいと考えています。


ciklone は Trac をベースにした BTS サービスのホスティングサービスを提供しています。利用しているお客様からの声から開発した新しい機能のご紹介です。

チケット管理システムを利用しているとき、使い慣れたメールクライアントからメールからチケット登録やチケットの更新ができれば・・・と思ったことはありませんか?

今回ご紹介する機能は、

  • メールクライアントから新規メールを送信してチケットを登録
  • チケットの通知メールに返信してチケットを更新
  • メールに添付ファイルを付けることで、チケットにファイル添付が可能
  • プロジェクトごとに送信用メールアドレスを自動で管理
  • メンバー以外のチケット登録は不可

ciklone をご利用のお客様(無料アカウント含む)はどなたでもご利用可能です。

 

チケットの登録

  1. プロジェクトの概要タブの「メールでチケット登録」リンク
    • プロジェクトごとに送信用メールアドレスが登録されています。このメールアドレスは送信専用です。
  2. いつも利用しているメールクライアントから東進専用メールアドレスにメールを送信する
    • 件名:チケットの件名
    • 本文:チケットの詳細内容
    • 添付:チケットの添付ファイル

チケットの更新

  1. メール通知設定をしておきます。チケットが新規作成、更新されるとメールが送信されます。
  2. 通知メールを受信し、受信したメールを返信。返信するとき、ciklone により管理されたチケット更新用のメールアドレスが設定されます。
  3. チケットに内容を記述し、送信します。

 

利用シーン

  • ホームページ担当者が顧客からの問い合わせをメールで開発チームに報告
  • 顧客先、出先から障害報告
  • 携帯、スマートフォンから障害報告
  • 自分のタスクを連続で登録
  • メールによる返信により、ブラウザでURLを開かなくても状況の確認とコメント作成

ciklone は無料アカウントがあります。

どなたでもすぐに使うことが出来ます。

 

ciklone 1.8 リリースのお知らせです。
本日、ciklone のリリースを実施しました。ご利用のお客様は新しい機能を利用する事が出来ます。ぜひご利用下さい。

機能紹介

ご要望やバグ報告を頂きました皆様、まことにありがとうございます。
これからもどうぞよろしくお願いいたします。

今後もさらなる改善をおこなってまいります。
ご要望やご質問はこちらまでご連絡ください。

cikloneはTracをベースにしたエンタープライズ向けのWebサービスです。利用しているお客様の声から開発した各種プラグインをTrac/Trac Lightningでも利用できるように trac-hacks:ExcelDownloadPlugin として公開しました。

https://trac-hacks.org/wiki/ExcelDownloadPlugin

 

Excelダウンロードプラグインは、Tracの強力なレポート機能と連動した

  • Excel形式でチケット出力
  • チケット一覧に対応した履歴出力

することが出来ます。

インストール

それでは、Windows環境で良く利用されているTracLightningをつかってインストールをしましょう。

1. xlwt ライブラリのインストール

ExcelDownloadPlugin は Excel ファイルの生成に xlwt を使っています。まずはこれをインストールします。

c:\TracLight\bin>easy_install -Z xlwt

2. ファイルのダウンロード

https://trac-hacks.org/wiki/ExcelDownloadPlugin にアクセスして、Downloadから「here」をクリックして、exceldownloadplugin-rxxxxx.zip をダウンロードします。ダウンロードしたファイルを適当なディレクトリに展開します。

ここでは、

C:\temp\exceldownloadplugin\0.12

に展開。

3. easy_install でインストール

easy_install にソースディレクトリを指定してインストールを実行します。

c:\TracLight\bin>easy_install -Z C:\temp\exceldownloadplugin\0.12
Processing 0.12
Running setup.py -q bdist_egg --dist-dir C:\temp\exceldownloadplugin\0.12\egg-dist-tmp-nduefk
zip_safe flag not set; analyzing archive contents...
Adding exceldownloadplugin 0.12.0.1 to easy-install.pth file
Installed c:\traclight\python\lib\site-packages\exceldownloadplugin-0.12.0.1-py2.6.egg
Processing dependencies for exceldownloadplugin==0.12.0.1
Finished processing dependencies for exceldownloadplugin==0.12.0.1

4. trac.ini でプラグインを有効にする

trac.ini はプロジェクト毎に設定する必要があります。有効にしたいプロジェクトの conf/trac.ini でプラグインを有効にします。

# conf/trac.ini
[components]
tracexceldownload.* = enabled

実際に使ってみましょう

カスタムクエリやレポートからチケット一覧を表示します。一覧表示されたページの下部に、「Excel」「Excel(履歴含む)」が表示されます。あとは、クリックしてダウンロードしてください。

Excelダウンロードプラグイン

  • Excel形式(xls)によるエクスポート機能
  • チケットの履歴出力
  • チケット単位(1チケット)で履歴を含めたエクスポート機能

が利用可能です。
ぜひ、あなたのプロジェクトでご活用下さい。

チケットのExcelエクスポート機能に履歴出力機能を追加しました。これにより、従来CSV/Excel出力したとき、チケット一覧と最新のチケット属性が出力されていましたが、履歴の一括出力ができるようになりました。Excel2003形式(xls)に正式対応しました。

 

チケット管理システムを利用して、課題管理、バグ管理、リリース管理をされている方。「チケットの履歴が出力したい」と思われたことはありませんか。

  • リリースプロセスのログ、報告内容(コメント履歴)として保存しておきたい
  • チケット管理が浸透すると重要な説明が履歴の中に記述されているデータを出力したい
  • 時系列での履歴を見返すため必要
  • CSV/Excel出力して作業履歴をデータとして残したい
  • 分析するためのテキストデータが欲しい

など。

ciklone に新しい機能:チケットのExcelエクスポート機能にチケットの履歴が出力できる機能を実装しました。レポート機能やチケット検索結果は従来通り利用する事が出来ます。(Excel出力時にチケットの履歴が出力されるようになりました。)

Excelエクスポート機能:履歴出力

  • Excel形式(xls)によるエクスポート機能
  • チケットの履歴出力
  • チケット単位(1チケット)で履歴を含めたエクスポート機能

が利用可能です。

ciklone をご利用のお客様はぜひご利用ください。

Excelエクスポート機能はプラグインとしても提供を予定しておりますので、Trac/Trac Lightningをご利用のお客様も利用可能です。(公開までしばらくお待ちください)

 

 

インストールが正常に終わったら設定です。(GUIツールを使ったとしてもチケットのワークフローを設定するのはとても面倒)
ここでは基本的な使い方と設定例を説明していきます。
環境
  • Windows XP SP3
  • TracLightning 3.1.1(DLはこちら)
Trac をつかったチケット運用をはじめて軌道にのってきたらワークフローをカスタマイズして自分たちのプロジェクトにあわせたいと思う。設定例を示しながらTracWorkflowAdmin の使い方を説明します。
読んでおいた方が良い文書

普通は、trac.ini に [ticket-workflow] セクションを作成し、[ticket-workflow] セクション内にサンプルを貼り付けておわり。

残念ながら、TracWorkflowAdmin にはGUIで trac.ini の {ticket-workflow} を編集できる機能がないので画像を示しながら設定例を解説します。当然、trac.ini の {ticket-workflow}セクションにコピーアンドペーストしても良いです。

※ワークフローがカスタマイズできるといっても、「new ではじまり close で終わる」は変わりません。

使い方

設定例1:TracWorkflowAdmin の初期化で提供されるワークフロー

標準的なワークフローです。流れとしては、新規作成(new) → 担当割り当て(assigned) → 解決(closed) となります。新規作成(new) → 担当する(accepted) → 解決(closed) という流れもあり、こちらはチケットを自分で選んで処理する場合のフローです。

[ticket-workflow]
accept = new,assigned,accepted,reopened -> accepted
accept.default = 999
accept.name = 担当する
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = new,assigned,accepted,reopened,closed -> *
leave.default = 1000
leave.name = 変更しない
leave.operations = leave_status
reassign = new,assigned,accepted,reopened -> assigned
reassign.default = 998
reassign.name = 担当を変える
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = closed -> reopened
reopen.default = 997
reopen.name = 再オープンする
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,accepted,reopened -> closed
resolve.default = 996
resolve.name = 解決にする
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

設定例2:最もシンプルなワークフロー

最もシンプルなフローです。新規作成(new) → 解決(closed) 。一人で利用している場合やワークフロー機能を使わない場合など、チケットを備忘録やタスクとしてシンプルに利用するときに良いかもしれません。

[ticket-workflow]
leave = new,closed,reopened -> *
leave.default = 1000
leave.name = 変更しない
leave.operations = leave_status
reopen = closed -> reopened
reopen.default = 999
reopen.name = 差し戻す
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,reopened -> closed
resolve.default = 998
resolve.name = 解決にする
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

設定例3:「確認待ち」ステータスを追加したワークフロー

フローダイアグラムは少し複雑になります。

チケットの作業が完了したとき、「確認待ち」というステータスが必要な場合があります。バグ管理の場合、開発者が対応済みと思っても、解決していないことや認識違いが多々あります。そこで、「完了」の前に必ず別の担当者による「確認」を入れることでバグが修正されたことをチェックしたり、再現しないことを確認したあとで「完了」にするためのワークフローです。

このワークフローでは完了にするためには必ず「解決・確認を依頼する」を経由しなければいけません。場合によっては直接完了できるフローを追加しても良いかもしれません。

[ticket-workflow]
leave = new,assigned,accepted,reopened,closed,resolved -> *
leave.name = 変更しない。
leave.default = 1
leave.operations = leave_status
accept = new,assigned,accepted,reopened -> accepted
accept.name = 着手する。
accept.default = 0
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
reassign = new,assigned,accepted,reopened -> assigned
reassign.name = 担当者変更
reassign.default = 0
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reject = resolved -> assigned
reject.name = 差し戻す。
reject.default = 0
reopen = closed,resolved -> reopened
reopen.name = 再オープンする。
reopen.default = 0
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,accepted,reopened -> resolved
resolve.name = 解決、確認を依頼する。
resolve.default = 0
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY
verify = resolved -> closed
verify.name = 完了を承認する。
verify.default = 0
verify.operations = set_resolution

参考資料

操作(operations)の説明

  • del_owner — チケットの所有者を削除します。
  • set_owner — チケットの所有者を選択された所有者か入力された所有者に設定します。
  • actionname.set_owner カンマ区切りのリストか1つの値を設定することができます。
  • set_owner_to_self — チケットの所有者をログインユーザに設定します。
  • del_resolution — チケットの解決方法を削除します。
  • set_resolution — チケットの解決方法を選択された解決方法か入力された解決方法に設定します。

trac の wiki/TracWorkflowから引用

いつもサイクロンをご利用頂きまして、誠にありがとうございます。

ciklone.com の計画メンテナンスを実施予定です。メンテナンス中は ciklone.com にアクセスすることはできませんのでご注意願います。

【実施予定日】: 2011年6月5日(日曜) 21:00~23:00

【作業時間】: 約2時間を予定

【内容】: ciklone.com のバージョンアップ作業

お客様にはご迷惑をおかけしますが、ciklone サービスの機能向上のためご協力をお願い致します。

メンテナンスに関するご質問は、こちらまでご連絡ください。

ワークフローダイアグラムによるワークフロー管理プラグインをご紹介します。Trac のすばらしい点はそのプラグインの豊富さがあります。チケットのワークフロー管理を簡単にするために

などがワークフロー関連では良く利用されているのではないでしょうか。

今回ご紹介するプラグインは、

チケットワークフローの図

特徴

TracWorkflowAdmin はチケットのワークフロー管理のために、シンプルなWebインターフェースを提供し、ワークフローを簡単に追加・編集することができます。

  1. アクションや表示名をインラインで追加・編集できるUI
  2. リアルタイムでワークフローダイアグラムとして表示(プレビュー機能)
  3. 設定間違いをメッセージで通知

ワークフロー管理プラグイン

TracWorkflowAdminの一番の特徴は、変更したワークフローをダイアグラム(線図)によるリアルタイムプレビューが利用できることです。

従来のワークフロー管理では複雑なワークフローを作成する場合、何度もやり直して試行錯誤しながら設定していたのではないでしょうか。このプラグインは「かんたんに、目で見て分るワークフロー管理」を目指して開発しました。

Windows/Trac (TracLightning) 編:インストール方法

前準備として、Tracが正常に動作する環境とpythonへのパスが通っていること。python は TracLightning と同時にインストールされます。パスの設定なども導入時に出来ていると思います。

>{Tracホーム}\python\Scripts

1. スタートメニュー「Trac」→「コマンドプロンプト」を実行

2. プラグインのインストール

TracWorkflowAdmin をダウンロードし、適当な場所に解凍します。

コマンドプロンプトで以下のコマンドを実行します。
C:> easy_install.exe C:\TracLight\plugins\svn\tracworkflowadmin\0.12

実行結果:

C:\TracLight\bin>easy_install.exe c:\TracLight\plugins\svn\tracworkflowadmin\0.12
Processing 0.12
Running setup.py -q bdist_egg --dist-dir c:\TracLight\plugins\svn\tracworkflowadmin\0.12\egg-dist-tmp-k4yidd
zip_safe flag not set; analyzing archive contents...
Removing tracworkflowadmin 0.1 from easy-install.pth file
Adding tracworkflowadmin 0.12.0.1 to easy-install.pth file

Installed c:\traclight\python\lib\site-packages\tracworkflowadmin-0.12.0.1-py2.6.egg
Processing dependencies for tracworkflowadmin==0.12.0.1
Finished processing dependencies for tracworkflowadmin==0.12.0.1

3. Trac を再起動

TracLightningの場合、

  • 「コマンドプロンプトで起動」を使っている場合は、コマンドプロンプトを閉じて再度「コマンドプロンプトで起動」を実行します
  • Windowsサービスで起動している場合は、管理ツールからサービスを選んで TracLightning のサービスを再起動します

再起動できたらブラウザから TracLightning のプロジェクトに管理者カウントでログインします。

ログイン後、管理メニュー → プラグインをクリック。

インストールした「TracWorkflowAdmin」を有効にします。変更を適用をクリック。
以上でプラグインのインストールは終了です。
※プラグインの有効・無効はプロジェクト毎に設定する必要があります。