Bitbucket プルリクエスト ガイドライン機能を使おう

*この投稿は、<a href="http://qiita.com/advent-calendar/2016/augtokyo">Atlassian User Group Tokyo Advent Calendar 2016</a>の25日目です。*

## Bitbucket.org と拡張 (統合) 
Bitbucket は、Atlassian Connect による柔軟な拡張が行えます。これらのほとんどは、簡単に適用でき、設定も容易になっています。

### 拡張機能の閲覧と適用
拡張機能の閲覧は以下の手順で行えます。

![スクリーンショット 2016-12-24 22.08.29.png](https://qiita-image-store.s3.amazonaws.com/0/26169/9e47c338-6d8b-8be1-6925-40aa21917996.png "スクリーンショット 2016-12-24 22.08.29.png")

右上の自分のアカウントのアバターをクリックして、[統合] をクリックします。
すると、非常に多くの統合機能が閲覧できます。カテゴリでフィルターしてみるとよいでしょう。

![スクリーンショット 2016-12-24 22.10.34.png](https://qiita-image-store.s3.amazonaws.com/0/26169/254f215f-16bd-ef45-e256-75f92a4699b6.png "スクリーンショット 2016-12-24 22.10.34.png")

使って見たい機能があったら、[追加] ボタンをクリックするだけで適用することができます。適用時に権限について聞いてくることがほとんどですのでご注意ください。

適用したアドオン機能は、アカウントの設定か、リポジトリごとの設定にて詳細な設定を行えるものが多いです。

#### ↓ アカウントの設定に現れているアドオンの設定画面

![スクリーンショット 2016-12-24 22.13.22.png](https://qiita-image-store.s3.amazonaws.com/0/26169/79a5f6dd-9677-d634-7f7a-75feb9f50247.png "スクリーンショット 2016-12-24 22.13.22.png")

この例では、Bitbucket で Docker を活用した継続的インテグレーションとデプロイメントを行える「Bitbucket Pipelines」 (詳しくは[こちら](https://nagasawa.blog/articles/aws-codedeploy-with-bitbucket-pipelines/)も参考に) とグループチャットの HipChat と連携して通知や、HipChat でプルリクエストの一覧を管理できる「Bitbucket for HipChat」 (詳しくは[こちら](https://www.evangelism.jp/articles/chatops-case-study-code-review-with-bitbucket-and-hipchat/)も参考に) が示されています。

#### ↓ リポジトリの設定に現れているアドオンの設定画面

![スクリーンショット 2016-12-24 22.17.10.png](https://qiita-image-store.s3.amazonaws.com/0/26169/70268496-5f16-7a20-f7f6-e614c236f2a8.png "スクリーンショット 2016-12-24 22.17.10.png")

この例では、「Bitbucket Pipelines」のリポジトリごとの設定と、Bitbucket Issue Tracking をタスクボードとして可視化できる「BucketBord」 (詳しくは[こちら](https://www.evangelism.jp/articles/bitbucket-task-board-features/)も参考に)、そして HipChat との連携の設定が示されています。

## Bitbucket プルリクエスト ガイドライン

### プルリクエスト
プルリクエストは、Bitbucket が持っている機能です。レビュアーの指定などが行えて、コードレビューとマージを明確に迅速に簡素に行えるため、この機能を活用した開発フローを採用しているチームが増えています (GitHub フロー、フィーチャーフローと呼ばれる開発スタイル)。

ただし、せっかくの機能でもレビュアーによってレビューのポイントが異なっていたり、レビューの仕方が人に依存しすぎたり（例えば、コードコメントを使ってコードに直接スレッド形式でレビューディスカッションをするにしても粒度や求めるものが人によって差異がありすぎるとスレッドが間延びしすぎてしまい、第三者がみるとなんだかよくわからなく、ナレッジとして活用できない。。。なんてことはよくあります）することがあります。

最初はそれでもコードレビューをするべきですが、ある程度成熟してきたらそれらをガイドラインとして明示すべきです。ただ、それが社内標準など大きな枠組みであったり、ツールと連動していなく、他のドキュメント管理や文書を閲覧しなければならなかったりすると結局ガイドラインは形骸化していってしまいます。

### Pull Request Guidelines を使おう

 ![スクリーンショット 2016-12-24 22.26.26.png](https://qiita-image-store.s3.amazonaws.com/0/26169/aa02892a-6687-9228-cc6b-6d97808d0c14.png "スクリーンショット 2016-12-24 22.26.26.png")
 
「Pull Request Guidelines」は Atlassian が提供する Bitbucket の拡張機能です。これを適用すると、プルリクエストのレビュー画面にガイドラインへのリンクが出現し、そこからいつでもガイドラインを確認しながら、レビューを行うことができます。


![スクリーンショット 2016-12-24 22.29.35.png](https://qiita-image-store.s3.amazonaws.com/0/26169/df8cf08e-1b18-9293-a527-10b0755f4a75.png "スクリーンショット 2016-12-24 22.29.35.png")

該当箇所を拡大すると以下です：
 ![スクリーンショット 2016-12-24 22.30.09.png](https://qiita-image-store.s3.amazonaws.com/0/26169/7eac1983-35e6-b39b-9f3f-e6af2bccd01b.png "スクリーンショット 2016-12-24 22.30.09.png")
 
「Pull request guidelines」というリンクがそれです。このリンクをクリックすると、

![スクリーンショット 2016-12-24 22.31.40.png](https://qiita-image-store.s3.amazonaws.com/0/26169/57681557-0084-2537-3e07-db19c25c2e53.png "スクリーンショット 2016-12-24 22.31.40.png")

ガイドラインがポップアップされます。ガイドラインは、大項目と項目が設定でき、また、項目には、詳細な文書を記述しておくことができます。

![スクリーンショット 2016-12-24 22.33.12.png](https://qiita-image-store.s3.amazonaws.com/0/26169/f00bc294-ca13-3469-d824-6dd83454c6c6.png "スクリーンショット 2016-12-24 22.33.12.png")

項目をクリックすると、詳細な文書を閲覧できます。また、項目の右側にある![スクリーンショット 2016-12-24 22.35.21.png](https://qiita-image-store.s3.amazonaws.com/0/26169/76a3d6e3-eecd-f797-cbba-013082c3e173.png "スクリーンショット 2016-12-24 22.35.21.png")をクリックすると、「確認した」とマーク![スクリーンショット 2016-12-24 22.36.49.png](https://qiita-image-store.s3.amazonaws.com/0/26169/69ef9b5f-5c75-56a7-bca4-ea93139f2469.png "スクリーンショット 2016-12-24 22.36.49.png")がつきます。

### ガイドラインを書こう

ガイドラインは、もちろんチームによって作ることができます。方法は、<code>CONTRIBUTING.md</code> ファイルをリポジトリに作成するだけです。

<code>CONTRIBUTING.md</code> ファイルの内容は、Markdown と同じ形式で。

        #  --- 大項目
        ## --- 項目
        説明文書

という書式であれば OK です。

上記の画面では、

        # レビュー ポイント
        ## サイクロマティック複雑度
        必要以上に複雑なコードになっていないか？入れ子構造の複雑さはコードバグに直結します。

と記述されています（一部抜き出し）。


## まとめ

Bitbucket.org には多くの拡張機能があります。これらを活用してよりよいチーム作りに役立ててください。

今回は、ツール機能とは単に自動化することだけではないということも示したかったので、プルリクエストのガイドラインを提供するアドオンを紹介してみました。