Redmineで受信メールによるチケット登録や既存リポジトリ情報を登録する方法
Redmine.JPを見ながら、改めてRedmineの機能の使い道に気づいたのでメモ。
Twitter / @uchiunyo: Redmineってメールでチケット登録出来るのか。これってめっちゃ素敵やん?
メールでRedmineチケットを登録する機能の可能性: プログラマの思索
Redmineでは受信メールからチケット登録する機能があ。
この機能を使って、サーバー監視ツールから障害検知メールを発行してRedmineにチケットを自動登録する方法がある。
一度チケットに登録すれば、バグのワークフロー管理ができるし、チケットにすべての作業履歴が集約されるので、検索もしやすいし、追跡もしやすい。
蓄積されたバグチケットを集計して傾向分析もできる。
特にインシデント管理では、顧客の問合せや障害の集計結果からの傾向分析が重要だ。
品質管理の分野では、「1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する」というハインリッヒの法則なる経験則が既に知られている。
サーバー監視ツールが、単なる軽微なエラー検知をしてくれたとしても、その件数が多い場合、重大な事故につながる予兆があるかもしれない。
特にソフトウェアは常に機能改善という名の下にどんどん手を入れて変化していくので、品質が劣化しやすい。
バグ修正したはずなのに、新たなバグを埋め込んでしまったという経験はないだろうか?
だから、軽微な障害や問合せの集計結果から、サーバーがダウンするような重大なリスクを早めに嗅ぎ取るようにしたいものだ。
【元ネタ2】
既存リポジトリをプロジェクトで利用する | Redmine.JP
「リポジトリ」を開くまでSubversion等のリポジトリへのコミットが「活動」に表示されません | Redmine.JP
小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog
Redmineで空のリポジトリを登録する時は問題ないが、既存リポジトリのリビジョンが1千以上を超えている場合、リポジトリを登録するとRedmineがタイムアウトしてダウンしてしまう時がある。
例えば、従来のBTSからRedmineへ移行した場合、既存リポジトリが膨れ上がっている時が多く、リポジトリを登録するとタイムアウトしてダウンしてしまう現象は何度も経験した。
そのため、リポジトリの登録を諦めてしまった時もあった。
すると、No Ticket, No Commitのルールを運用できず、単なるタスク管理にしかRedmineを使えない片肺飛行の運用の時もあった。
だが、上記の記事によれば、既存リポジトリを設定する場合、リポジトリからの情報の取得をオフラインで行う手法があるとのこと。
ruby script/runner "Repository.fetch_changesets" -e production (すべての有効なプロジェクトのチェンジセットを取得)
または
http://redmine.example.com/sys/fetch_changesets?key=
この手法を使えば、巨大な既存リポジトリも、後から登録することが出来る。
つまり、この手法はリポジトリ情報の登録をバッチ処理化したものと思える。
すると、RedmineによるSCM連携で、Jenkinsから上記のコマンドを叩けば、定期的にリポジトリ情報をRedmineへ登録することも可能のはず。
そのアイデアは下記に書いた。
Redmineを業務システム化するアイデア~メトリクス集計の本質は集計バッチ処理: プログラマの思索
リポジトリ情報をDBに登録するバッチ処理は、メトリクス集計ツールでは非常に重要な機能であるが、従来はこの機能の実現が大変だったという事情がある。
一度、DBにリポジトリ情報を登録出来れば、いろんな操作でいくらでも多種多様なメトリクスを計算することが可能になる。
Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索
Redmineには単なるチケット駆動開発のインフラだけでなく、ITILと組み合わせたインシデント管理も可能だし、メトリクス収集&集計のツールでもあり、多種多様な顔を持つ。
色々考えてみる。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント