VSTSの便利機能は用法用量を守って使いましょう

Visual Studio Team ServiceのGitを利用してソース管理した場合、様々な便利機能の恩恵を受けられます。
今回はPull Requestに関する便利機能は理解して使いましょう！というネタです。

Completedと同時にWork ItemsのStateを移動させる

Pull RequestをCompleteする際のウインドウにいくつかオプションがあります。

マニュアルはここにあります。

その中に、Complete linked work items after merging というオプションがあります。

このオプションは、Completeと同時に紐づいているwork itemsのstateを変更するという便利な機能です。

これにより、TaskやProduct Backlog Itemの移動し忘れ防止が期待できます。

Taskを移動させてみる

作業中のTaskがソースレビューとともに完了になると便利ですね。

と、いうことでIn ProgressのTaskを用意しました。

Commit or Pull Request の時にTaskを紐づけた状態の Pull Request を発行します。

レビューする側でも、Pull Request 詳細の左上部分できちんと紐づけされているのか確認できます。

Completeするとき、Complete linked work items after merging オプションにチェックを入れて Complete Merge を実施してみましょう。

紐づけられていたTask2がDoneへ移動しました。

stateの移動先はどこ？

このオプションは一つ先へ移動するのか？それとも完了になるのか？

Task3、Task4を紐づけたPull RequestをCompleteしてみましたのでご覧ください。

このように、StateはDoneへ遷移します。

Product Backlog Itemを移動させてみる

では、Backlogはどうなるのか。

そもそも、Pull Requestに紐づけるWork ItemってTaskなのでしょうか？それともBacklogなのでしょうか？

このオプションが追加されて以降、私は「MicrosoftはTaskが紐づくことを想定している」と思っています。

それはなぜか。

CommittedのBacklogを用意したので、顛末をご覧ください。

Task同様、Product Backlog Item 2 をPull Requestに紐づけます。

stateはDoneへ移動しました。

段々、用法を間違えるとどうなるか察することができますね。

WIP制限の設定を有効したカンバンを利用した場合

カンバンのWIP制限を有効にした場合、Backlogはどのように動くのか。

Committedが2/1と溢れているようです。誰か並列作業を行っていますね。 さらに Product Backlog Item 5 が後から控えています。

Pull Requestに後から控えていたProduct Backlog Item 5を紐づけて...概要が何か訴えています。

なんと！BacklogがWIP制限中のComittedを飛び越えて完了してしまいました。

あ、はい、わかってた結果ですね。

ご利用は計画的に

このように、Complete linked work items after mergingオプションは紐づいたWork ItemのStateをDoneにしてしまうオプションです。

私が「MicrosoftはPull RequestにTaskが紐づくことを想定している」と思ったのも、Backlogを勝手にDoneにするのはさすがにどうなの？と感じたからですね。

Sprint Reviewのタイミングで確認を行っている場合、気付かないうちに完了してしまったということがあるので、便利なオプションだからといって安易に使うと混乱を招くので注意が必要です。