投稿

2018の投稿を表示しています

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

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

Redmine本体へのコミットは、MastodonDiscordの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以外はその1階層下まで表示する仕組みにしています。

また、一つのリポジトリに複数のプロジェクトを突っ込んでいるような構成も見かけます。
各プロジェクトの中に、さらに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の解凍機能について、テスト観点図、テストコンテナを作成するワーク。今回は6人のチーム。それぞれで仕様書をざっとみる。仕様書は見ないようにして観点をみんなで付箋に書き出していった。
仕様書を見ないことで、仕様書に書いていないことが出やすくなる。手を止めずにどんどん進めていくのが重要。出した付箋をツリー構造に整理していく。
整理する中で新しい観点がでてきたり、構造を変えるために加えたりと、いろいろ話しながら進めました。観点に出ていくる「言葉」を共通の理解で捉えているか、を確認するのも重要。
チームで同じものを見ていることが重要。バックボーンの違いから、…