見出し画像

Bitbucket CloudでDangerを使ってレビューの一部を自動化する

この記事は、NAVITIME JAPAN Advent Calendar 2021の 21日目の記事です。

こんにちは、ももたけと見習いスパルタ人2号です。我々は開発サポート部門に所属し、Atlassian製品をはじめとした開発系ツールの導入や運用促進を担っております。今回Dangerを使ってコードレビューの一部を自動化する方法をご紹介します。

Dangerとは

コードレビューにおいて、必ず確認している共通のチェックが存在することがありませんか? たとえば筆者の周りを見渡すと「ドキュメントも更新してください」「Pipfileを更新した場合は必要があればPipfile.lockも更新してください」などがあり、チームに新しく人が入ったときや、ちょっとしたミスで上記の指摘をしないといけないことがあります。

Dangerの公式サイトでは下記のように紹介されています。

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review.

Dangerはルーティーンのようにおこなっているこれらのレビューを自動化してくれるツールになります。

ルールはTypeScript/JavaScriptで記述できるため、プロダクトやチーム毎の幅広いルールを設定することが可能です。

Dangerは、Rubyで開発されているものがメインとなりますが、Bitbucket Cloudに非対応だったため、後続のDanger JSを利用しております。
DangerとDanger JSについてはこちらをご参考ください。

今回利用したもの

・Bitbucket Cloud
・Danger JS
・Docker
・(Jenkins)

現在、Bitbucket PipelinesやCircleCIなどの様々CIツールが存在しており、Dangerを利用するだけであれば、その多くで yarn install danger と yarn danger ciを実行することで解析することができます。

しかし、弊社のセキュリティ規約により、社内利用のIPだけからBitbucket  Cloudにアクセスできるように制限がかかっています。SaaSのCIサービスを利用するためにはIPの口開けが必要になりますが、口開けしたIPで不特定のユーザーからアクセスされてしまう可能性があり利用ができませんでした。

弊社でCIサービスを利用する場合は、ホスティングしているJenkinsをメインで利用し、自社環境からのアクセスのみに制限した上でBitbucket Cloudとの通信を許可しています。(一部Bitbucket Pipelinesも利用しています。)JenkinsにはDangerのプラグインなどが無いため、環境にDangerをインストールする必要がありますが、色々なOSでJenkinsが利用されていることや、少し話は変わりますがローカルで利用することも考慮して、環境構築を容易にするためにDockerを利用しました。

準備

リポジトリで下記のファイルを作成します。

①dangerfile.ts (or dangerfile.js)

チェックする項目を記入するファイルです。公式のリファレンスを参考にチェックしたい項目を追加してください。

import { danger, warn } from "danger"

if (danger.bitbucket_cloud.pr.title.includes("WIP")) {
 warn("PR is considered WIP")
}

ドキュメントには下記のような例が記載されています。

・ラベルが使用されていることを確認する
・要約は必ず記入させる
・担当者は必ずX人以上に設定させる
・package.jsonが編集された場合は注意を促す

https://danger.systems/reference.html

チームのレビュー体制に応じて必要な項目を設定できます。「Dangerとは」でも触れましたが、こちらにプロダクトやチーム毎のルールを記載していくことになります。Dangerのプラグインを導入するとLintの結果なども一緒に通知してくれるなど、機能は多岐に渡るので、よりコードの中まで確認したい場合はドキュメントを確認してみるのもいいかもしれません。

②Dockerfile

冒頭でお伝えしたように、今回はDockerを利用して環境を構築しています。

FROM golang:1.17

RUN apt-get update
RUN apt-get install -y nodejs
RUN apt-get install -y npm
RUN npm install danger

WORKDIR /tmp

ENV JENKINS_URL="http://jenkins.com/"

ENTRYPOINT /go/node_modules/.bin/danger ci

公式のGetting Startedはこちら。

実行

Bitbucket Cloudの場合は下記の4つをDangerに渡すことによって実行が可能です。

DANGER_BITBUCKETCLOUD_USERNAME (ユーザー名)
DANGER_BITBUCKETCLOUD_PASSWORD(アプリパスワード)
CHANGE_URL (プルリクエストのURL)
CHANGE_ID (プルリクエストのID) 

下記のコマンドをdangerfileがあるパスで実行すると、Dangerが解析を行い、Bitbucketに通知してくれます。

docker run -v  $REPOSITORY_PATH:/tmp -e CHANGE_URL=$CHANGE_URL -e CHANGE_ID=$CHANGE_ID -e DANGER_BITBUCKETCLOUD_USERNAME=$DANGER_BITBUCKETCLOUD_USERNAME -e DANGER_BITBUCKETCLOUD_PASSWORD=$DANGER_BITBUCKETCLOUD_PASSWORD -itd {任意のタグ}

確認

Bitbucketのプルリクエストのページを確認すると、コメント欄に下記のような通知がされています。

画像1
プルリクエストに表示されたメッセージ

通知ができていない場合の原因切り分けは、実行したパスの配下にdanger-results.jsonが存在しているかどうかを確認してください。ErrorやWarningが記載されている場合は、Bitbucketとの疎通周りが怪しいため、IDやAPP PASSWORDなどを確認してください。

ここまでできれば、ホスティングしているJenkinsなどのCIツールでプルリクエストが発行されたり更新されたりするたびに解析するだけですね!
1点注意になりますが、JenkinsでDangerを利用する場合はよくBitbucketというプラグインが紹介されています。こちらについては、トリガーがプッシュのみとなっていてプルリクエストの作成をトリガーにジョブを実行することができないことがあり、利用ができませんでした。このため弊社ではBitbucket Push and Pull Requestを利用しています。こちらはプルリクエストの承認などの様々なシーンでのトリガーができるのでおすすめです。

おわりに

皆さん日々レビューをしていく中で、「このファイルはリリース前に修正していないとまずい」や「同じ箇所を何度も指摘しているかも」となるケースがあると思います。Bitbucket CloudでもDangerの利用ができるようになったため、チームの指摘あるあるをゼロにできるように、是非導入してはいかがでしょうか。