Dockerを使ったら便利だった話でした。DMM.comラボでログインやアカウント登録などの会員基盤の開発を担当している入社2年目の@kentaro-mです。本日は私が所属するチームで活躍しているプルリクエスト運用Botについてお話したいと思います。チームでは上図のようにプルリクエスト運用を行っています。Bot導入前にネックになっていたのはレビューを依頼してから承認されるまでの部分です。レビューが同時進行で行われ、マージまでの時間がかかるレビュー依頼は実装者がプルリクエストのタイトルとURLを付けて、Slackでチームメンバーに依頼しています。レビューは実装者以外のチームメンバーが行い、2人以上の承認が付けばマージできる方針でした。チームでは毎日5〜10ほどのプルリクエストが作成され、レビューが同時進行で行われておりレビュアーはどのプルリクエストをレビューしたか分からなくなったり、レビュイーは作成したプルリクエストのレビューが進まないことに気をもんでいたりしました。レビューする時間を明示的にとってみるそこで毎朝30分間チームメンバー全員でレビューの時間を取ることにしました。これにより、1日の始めに昨日作成されたプルリクエストはほとんどマージされるようになりました。この方法では一度に多くのプルリクエストをレビューすることになり、レビュアーの負担が増える結果となったのです。この結果を受けて、プルリクエストが作成されたタイミングでレビューを行う運用にすることがレビュアーとレビュイーにとって良いのではないかと考えました。それを実現するためにプルリクエスト運用を手助けするBot「プルリくん」の開発に着手しました。プルリくんが提供している機能プルリくんは以下の機能を提供しています。基本的にはレビュアーとレビュイーに対応して欲しいタイミングでのSlack通知がメインの機能です。それに加えて、毎回のプルリクエスト作成で必要なレビュアーのアサインの自動化もあわせて可能にしました。プルリクエスト作成時のレビュー依頼通知プルリクエストが作成されるとレビュアーにはDMでSlackに通知がきます。メンションコメントの確認通知メンション付きのレビューコメントが追加されると、レビュイーまたはレビュアーにDMでSlackに通知がきます。プルリクエストマージ可能時の通知プルリクエストにApproveコメントが指定人数以上ついたときにレビュイーに通知します。チームでは2人以上の承認で通知するようにしています。毎回プルリクエストを作成する度にポチポチとボタンを押して、同じメンバーをレビュアーとアサイニーに追加する必要があったのでプルリクエスト作成で自動追加するようにしました。プルリくんが動作する仕組みプルリくんはAWS環境で運用する想定で作られています。AWSにしたかというと、チームの開発環境がAWSで構築されており相乗りしたかったこと、会社の福利厚生で月100ドルまでAWSが自由に利用できて学習する際の個人的負担が必要なかったことが挙げられます。Gatewayのエンドポイントがたたかれることで処理が開始します。APIを使用してメッセージを送信しています。"レビューお願いします。"コメント確認お願いします。true}実際に利用する際の各機能の有効・無効やSlackメッセージ送信のためのGitHubとSlackのユーザー名の対応はJSON形式で設定できます。Enterpriseが導入され、社内システムとして構築されています。APIへのリクエスト等の社外からのアクセスはアクセス元IPを許可してもらう必要がありました。Lambdaはデフォルトではインターネット上に配置されているためにIPを固定することができません。Gatewayで通信の出入り口を作成しました。SAMを使用して構成をコード化し再利用可能にBotを開発し始めたときはまず自チームで動作するものを作りたいという思いでしたが、実装していくにつれて他チームに展開できたら良いのではないかと考えました。そこで簡単に他チームでも導入できる方法を実現するために辿り着いた答えが構成のコード化でした。SAMを使用することでコード化し容易にデプロイできます。私はCloudFormationの使用経験があったので後者でBotの構成のコード化に取り組みました。CAPABILITY_IAMコマンドを数回打つだけでAWS上にアプリケーションがデプロイされます。プルリくんを導入した結果プルリくん導入した結果、レビュー依頼からマージまでのネックとなっていたコミュニケーションの部分が解消されてレビューがうまく回るようになりました。具体的に良かったことは以下が挙げられます。レビュアーのプルリクエストへの反応が良くなったプルリくんを導入してからレビュアーの初動対応が早くなったことを感じました。以前は各々タスクの空き時間でレビューをしていましたが、導入後は通知をきっかけに動き出すことが増えて結果としてレビューが早く回るようになりました。Slack上でのレビュー依頼が減った以前はプルリクエストを作成後に開発者がSlackでレビュー依頼をしていました。日によって依頼メッセージでチャンネルが埋め尽くされることもありましたが、プルリくん導入後は依頼メッセージが減り、タスク進行する上での相談のコミュニケーションが増えました。さいごにチームに配属されて約1年半プルリクエスト運用を経験して日々感じていた課題を解決するためにBot開発に挑戦したことを紹介しました。今回はプルリクエストレビューで発生するコミュニケーションの改善にフォーカスを当てました。チームでは他にもユニットテストや静的解析ツールをCIで実行することでコードレビューにおけるレビュアーへの負担を減らす取り組みも行っています。アプリケーションの品質を向上させるためにプルリクエストレビューは重要な作業の一つだと思うのでこれからもどういった運用が良いのかを考えていきたいと思います。明日は@canacelさんの記事です。Matsushita@kentaro_m金沢のゲーム会社で働くフロントエンドエンジニアです。プライベートではかゆいところに手が届くツールを開発してGitHubに公開しています。https://kentarom.com/FollowDMM.com総合エンタテイメントサイト「DMM.com」を運営。会員数は2,900万人を突破。動画配信、FX、英会話、ゲーム、太陽光発電、3Dプリンタなど40以上のサービスを展開。沖縄での水族館事業参入、ベルギーでのサッカークラブ経営など、様々な事業を手掛ける。VENTURES」による出資や、M&Aなどを積極的に展開している。upLoginユーザーは見つかりませんでした。