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」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
「ソフトウェア工学」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
「Git・構成管理」カテゴリの記事
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント