ユーザー登録時に姓名で自動的にグループを割り当てる（Redmine Auto Assign Group Plugin）

Redmine Advent Calendar 2018の9日目に書こうと思っていたやつです。

Redmine Auto Assign Group Pluginは、ユーザー登録時、自動的にグループを割り当てるプラグインです。
１年ぐらい前に、ここに書いたような感じでRedmine.orgのフォーラムをきっかけに作ったものです。

Redmine 4.0.0に向けて直した勢いで、姓名でも割り当てできるようにしました。
メールアドレスと同じで、正規表現で設定を行います。
他の条件とのAND条件で一致した場合にグループを割り当てます。
画面はこんな感じ。

前回リリース時点から、姓名に部署などを入れて運用するケースがあるため、メール以外もできるといいという話は上がっていました。
ただ、自分自身がこのプラグインどころか、グループ自体を使っていないので、なかなか手がつきませんでした。自分で使うの大事ですね。

やるか！と勢いをつけた当初は、そろそろRedmine 4.0.0がでるんじゃね！？
と界隈が盛り上がっていた頃で、リリースに合わせてプラグインもリリースするなら、一緒にやるか、と思いたちました。
本家のリリースは、やっぱり気分が上がりますよね！

月日は流れて、、、、

• 4.0.0のStable branchのできたし！
• Advent Calendarも書かないとだし。。。

という感じで、4.0.0を待たずにリリースってことにしました。
リリース楽しみにして年末を過ごしたいと思いますw
＃書いてる時点でリリースしてないですけどね。。。

と書いてアドベントカレンダー用にあっためて置いたら、12/9にRedmine 4.0.0がリリースされました！！！！！
1日早くリリースしてしまいましたが、リリースされた状態のRedmine 4.0.0でも無事に動いています。
#アドベントカレンダーの方は別のに変えてしまった。。。

祝 Redmine 4.0.0リリース！

Redmine Advent Calendar 2018の9日目です！

ついに今日、Redmine 4.0.0がリリースされました！
JPLはじめ、コミッタの皆様、コミュニティの皆様、ありがとうございました！

で、プラグインのことを書こうかと思いましたが、急遽変更でRedmine.orgのニュースに投稿された、JPLのリリース通知を翻訳したいと思います。
ざっくりな感じですので、誤訳などあればご指摘を。。。

----------------
Redmine 4.0.0, 3.4.7, 3.3.9 リリース

昨年、Redmineにコントリビュートしてくれた多くの方に感謝します。Redmine 4.0.0のリリースを報告できて嬉しく思います。Redmine 4.0.0では、200を超える変更が行われました。

• メール通知での大きな変更： これまで1つのメールですべてのユーザーへ通知していましたが、それぞれのユーザー宛てになりました。
• テキストの書式に関する多くの改善
• CoderayからRougeへの変更により、コードハイライトで多くの言語をサポート

メールの配信は、現在Rails ActiveJobを使用しています。デフォルトでは非同期で送信されます。しかし、デフォルトではプロダクション環境には適していないインメモリキューが使用されるため、ActiveJobの永続的なバックエンドを設定することを検討する必要があります。
https://guides.rubyonrails.org/v5.2/active_job_basics.html#job-execution

Redmine 4.0.0は、先日リリースされた最新のRails 5.2.2を使用しています。

Redmine 3.4.7と3.3.9は、3.4.x、3.3.xのユーザー向けメンテナンスリリースです。詳細はチェンジログを参照してください。それぞれ、2つのRailsの脆弱性が修正されたRails 4.2.11への更新も含んでいます。それらの脆弱性はRedmine3.xには影響しないですが、可能であれば更新すべきです。
----------------

ついでに、拙作＆メンテのプラグインの4.0.0対応状況は以下の通りです。

• Redmine XLSX format issue exporter
  Githubのmasterは4.0.0で動作しますが、4.0.0の最後の最後で直ったCSVエクスポートのバグと同じものがあるため対応中。。。
• Redmine Auto Assign Group Plugin
  v0.1.1で対応済み
• Redmine XLS Export plugin
  v0.2.1.t11で対応済み

Redmineのリポジトリから特定ソースの修正をGoogle Apps Scriptでメールする

Redmineのプラグインを作成していると、関連する本体側の修正に影響を受けることがあります。
また、私の作っているRedmine XLSX format issue exporterは、RedmineのCSVエクスポート機能と同等を目指しているので、変更に追随するようにしています。

Redmine本体へのコミットは、MastodonやDiscordのBOTで確認できますが、流してみる感じになるので見逃してしまいがちです。
CIで失敗する場合はいいのですが、スルーしてなんか動きがおかしくなったり、本体側のバグ修正をプラグイン側にも反映すべき場合があったりが続いたので、対策を考えて見ました、の結果です。

今回はGoogle Apps Scriptを使って見ました。Google Apps Scriptを使うと、cron的なトリガーでスクリプトを動かすことができます。
設定画面はこんな感じ。


作成したスクリプトは、redmine.orgのリポジトリページへアクセスして、今日のコミットがあればメールするというものです。
以下のような感じ。targetsにURLを追加していけば、複数のソースをチェックできます。


これでちょっとは見逃しが少なくなるといいんですが。。。

Redmineのチケットに表示されるSVNのコミット情報に対象ブランチを表示する

Redmineのチケットとリポジトリを関連付けすると、そのチケットに該当のコミットが表示されます。

ここには、どのブランチへのコミットなのかの情報がありません。

これを解決しようと以下のプラグインが存在します。
Git Revision Branches

名前からGit専用と見せかけて、実はMercurialにも対応していました。
でも、私が欲しいのはSubversion！！！！！

というわけで、以下のプルリクエストを作成しました。
Subversion support.

これを入れるとSubversionでも以下のように表示されます。
Redmineはプロジェクトに複数のリポジトリが設定できるため、そのリポジトリ名と後ろにブランチが表示されます。

認識できるリポジトリは、Subversionの標準的な構成（trunk, branches, tags）を想定しています。
ただ、Redmine本家のリポジトリからして、sandboxというのがあるので、さすがにRedmineのプラグインだしなと思って、それも認識できるようにしました。
trunk以外はその１階層下まで表示する仕組みにしています。

また、一つのリポジトリに複数のプロジェクトを突っ込んでいるような構成も見かけます。
各プロジェクトの中に、さらにtrunkやbranchesなどがある、例えば、
http://example.com/svn/projectA
　/trunk
　/branches
　/tags
http://example.com/svn/projectX
　/trunk
　/branches
　/tags
みたいな感じのとき、Redmineのプロジェクト、もしくはリポジトリの設定が分かれていて、リポジトリの設定には、
http://example.com/svn/projectX
と指定すると思われます。
こういった場合にprojectX部分は邪魔なので、それを省く設定を入れました。
複数リポジトリを設定する場合を想定して、カンマ区切りで複数指定できるようにしました。

とりあえずこれで自分としては用が足りるとこまでいったかなという感じ。

【テスト設計】VSTePのファーストステップ 〜 新潟出張版 〜 に参加してきました

JaSST'18 Niigataの翌日に行われた、
【テスト設計】VSTePのファーストステップ 〜 新潟出張版 〜
に参加してきました。
JaSST'17 Tokyo のセッション「VSTePのファーストステップ 〜 JaSST'16東北出張おかわり会 〜」にて講演された、 JaSST東北実行委員のお二方を講師に迎えて行われました。
お二方、主催すわにいの@kasacchifulさん、お疲れ様でした＆ありがとうございました！

内容はワークが中心で、ワークに当たって必要なVSTePのことを、はじめに座学でというものでした。座学は大きく、テスト観点図とテストコンテナについてでした。
具体的な図などは、connpassに記載のある参考してもらえればと思います。

テスト観点図

• テスト観点は「テストの意図」。
• チームで納得のいく観点、観点のまとめを行う。
• チームで話し合う中での「違和感」を大事にする。
  あのとき、なんかひっかかってたんだよな〜、というところでバグが出て後悔しないようにする。
• 仕様書に書かれていることがすべてではない。
• チームの経験なども含めて観点を出していく。
• トップダウン、ボトムアップ、ズームイン、ズームアウトを繰り返し考えてみる。
• 図にしたら、左右、上下の粒度を見ていく。
  粒度があっていない箇所から抜け漏れが見えてくることが多い。

テストコンテナ

• テストを実施することを考えた、観点のグルーピングを行う。
• 左から右へ、時系列にコンテナを並べる。
  縦方向は並列に行えるもの。
  テストの前後関係、実施順序、同時にできることなどが見える。
• チームとしてしっくりくる、納得できる括りにすることが大事。

ワーク

• +Lhacaの解凍機能について、テスト観点図、テストコンテナを作成するワーク。
• 今回は６人のチーム。
• それぞれで仕様書をざっとみる。
• 仕様書は見ないようにして観点をみんなで付箋に書き出していった。
  仕様書を見ないことで、仕様書に書いていないことが出やすくなる。
• 手を止めずにどんどん進めていくのが重要。
• 出した付箋をツリー構造に整理していく。
  整理する中で新しい観点がでてきたり、構造を変えるために加えたりと、いろいろ話しながら進めました。
• 観点に出ていくる「言葉」を共通の理解で捉えているか、を確認するのも重要。
  チームで同じものを見ていることが重要。バックボーンの違いから、ここがなかなか合わなかった感じがしましたが、擦り合わせて行けたかな。
  知っている人たちのチームだからこその思い込みもありそうだな、と思いました。
• テスト観点図ができたら、テストコンテナを作成していく。
• これをやってからでないと、これができない。
  これをしてからこれをすべき、といったところからまとめていった。
• 実際にテストを行うことをイメージしながら進めると、順序や並列でできるかなどが考えやすいと感じた。
• 機能が追加された場合などの影響範囲なども、関連する観点から属しているコンテナを抽出することで絞り込みやすい。

VSTePを用いると、チームで納得したテスト観点図、テストコンテナができるので、振り返りを通した改善が行いやすくなるとの話でした。
実際のワークを通して、顕在化したバグがどこで漏れていたのか、というあたりが明確になりそうだということ、それがチームの中での共通のものさしで語れそうだということを感じました。

普段は一人でマインドマップで観点を出していくことが多いため、まずはワークでやったようなことを取りいれながら、徐々に周りを巻き込んで行けたらなあ、とか思いました。