Slack通知 と GitHub の Releases・Tags を自動生成するツールを作っています
この記事は，Slack Advent Calendar 2019 18日目の記事です．
現在，slack-ruby-client と octokit.rb を使って，Slack通知 と GitHub の Releases・Tags の自動生成を一気に実行するツールを作っています．今回はそのツールについて紹介します．
github-slack-release-notification
slack-ruby-client と octokit.rb を利用して，Slack API と GitHub API を実行し，Slack通知や GitHub の Releases と Tags が自動生成するようにしました．
Slack通知では Block Kit を使って最新のプルリクエストの情報を表示するようにしています．今の所，名前がそのまんまのため，どこかのタイミングで名前を再検討するかもしれないです．
使い方
git cloneをしてからプロジェクト直下に.envを作成し，以下の定数を設定していきます．
GITHUB_PERSONAL_ACCESS_TOKEN=GitHub の個人アクセストークン（repo） GITHUB_REPOSITORY=Githubのユーザ名/リポジトリ名 SLACK_API_TOKEN=Bots の Slack API トークン PRODUCT_PAGE=プロダクトのWebページのURL RELEASE_POST_CHANNELS="random,general" ERROR_POST_CHANNELS="random,general" SUCCESS_EMOJI=":kirakira:" FAIL_EMOJI=":guttari:"
○○_EMOJIには，Slack の好きな絵文字を設定できます．Slack のチャンネルは複数選択が可能です．
SLACK_API_TOKENは Bots の API トークンを利用しました．
プロジェクト直下でapp.rbを実行します
github-slack-release-notification - [master] » ruby app.rb
Slack を見ると通知が来ています．（検証用のスクショとは言え，このPR内容はちょっと恥ずかしい...）
設定した GItHub リポジトリを見てみると，Releases・Tags も作られています．
作ろうと思ったきっかけ
普段は Ruby on Rails （以下，Rails）でのWebサービス開発を通して Ruby を書いているのですが，もっと Ruby 力を高めたいと思っていました．すると，Rails というフレームワークから離れた Ruby のコードを最近はあまり書いていないことにふと気がつきました．
そこで，今年の7月に ootemachi.rb で Rubotyを触ってみたという内容でLTをしてみたのですが，LT が終わって数分後に「ん？今度は Ruboty という Bot の フレームワークに乗っているのでは？」と気づいてしまいました．
そんな中，この勉強会の会場が Slack Japan のオフィスで，私のLTの前に@seratchさんの「Ruby で始める Slack App 開発」というセッションの内容を思い出していると「slack-ruby-client と Ruby で何か作れば，フレームワークに縛られずに何か役立つ楽しいツールが作れるかもしれない」と思いつきました．
そして，その頃は業務でデプロイ時に Slack通知 をする Capistarano のプラグインや Releases・Tags を自動生成する Capistarano のプラグインの導入を終えていたタイミングで「この2つの機能を Slack と GitHub の API を組み合わせて表現したら面白くなりそう」と思って作ってみた感じです．
ここまで作ってみての感想
一言で言うと「オブジェクト指向を自分で納得しながら Ruby を書くことができた」です．Ruby を始めたての頃，入門書でクラスについての章で車クラスや車輪クラスを作ってオブジェクト指向を学んだ記憶があったのですが，「これが開発業務にどのように結びつくのか？」ともやもやしていました（正直これは大学時代に Java を勉強していた頃から感じていた...）．
勿論，普段の開発でもオブジェクト指向は活用していますが，あくまで「フレームワークのルールに沿ったオブジェクト指向」なので「オブジェクト指向をやっている感」をあまり強く感じていませんでした．あまり上手く説明できていませんが，他に「Active Record にだいぶ助けられているのでは？」と思っているのも関係あるかもしれないです．
しかし，今回のツール作成を通して，「1つのファイルに処理をひたすら書く」→「冗長になってきたのでメソッド化」→「それでも長くなってきたので，メインの処理やAPIを操作する役割毎にクラスを作る」というオブジェクト指向の流れを自分で納得しながら自然に進めることができました．
また，Rails のようなディレクトリ構成も決まっていないため，どのような構成にするかも自分で決められるため．設計の本を読みながら色々試行錯誤ができます．また， 現在のコードが再設計やリファクタリングしがいがある状態なので Ruby の勉強するモチベーションがだいぶ上がりました．
今後
再設計（.envで設定する値も多いし...）やテストコードの導入など，やること沢山ありそうです．最終的には CI での自動デプロイ後に AWS Lambda で実行できるようにしたいと考えています．
まとめと所感
Slack通知 と GitHub の Releases・Tags を自動生成するツールを作っています．今までオリジナルの Webサービス を好んで作っていて，Ruby でツールを作成するのが久しかったですが，Slack や GitHub の Web API を組み合わせると，とても面白くなることを実感しました．業務でのちょっとした不便を解消するアイデアが出てきているので，ドンドン作っていこうと思います．
また，Ruby に限らず JavaScript や golang など他の言語でのツール開発にもチャレンジしていこうと思います．
「GoRails」は Ruby on Rails と英語を勉強するのにピッタリなサービスだった
この記事は，Ruby on Rails Advent Calendar 2019 17日目の記事です．
普段から Ruby on Rails（以下，Rails）で開発をしているのですが，キャッチアップする方法が書籍がメインでした．
そんな中，「GoRails」という動画で Rails を学べるサービスを見つけました．今回はその「GoRails」について自分なりにまとめていこうと思います．
GoRails とは
Chris Oliver さんが運営している Rails に特化したチュートリアルサイトです．現在では2万人以上の開発者が利用しているそうです．
少し前までは，Railsチュートリアルではお馴染みの「RailsCasts」というサービスがありましたが，現在は更新が止まってしまいました．
そこで「GoRails」の登場したことにより「新たな RailsCasts だ！」とブログや Twitter で一部のエンジニアから評されているようです．
入門してみた理由
他にも「Udemy」や「Pluralsight」という動画で Rails を学ぶサービスを見つけました．
どれにしようか考えた時に，「GoRails」の方がカリキュラムの数と定期的に更新されていることやメドピアさんが「テックサポート制度」というエンジニア向けの社内制度に「GoRails」を導入している事例を知り，入門することにしました．また，英語に触れる機会をもう少し増やしたい気持ちもありました．
ただ，「Pluralsight」は JavaScript や Python など Rails 以外のコンテンツが充実しており，Udemy は Rails の英語でのコンテンツで面白いものを何個か見つけたので，どちらも今後の動向はチェックしていこうと思います．
内容
※以下は会員登録しなくても見ることができます．
Rails そのものを学べるだけではなく， Rails を基点に Vue.js や Twilio など Rails でのWebサービス開発で利用される技術についても学ぶことができます・
「Rails & Vue.js Trello Clone」という Rails と Vue.js を使った Trello のクローンを作る動画で勉強してみました．動画のプラットフォームは YouTube のため，困ったら自動翻訳が使えます．
進捗としてはまだ序盤の段階のため完成までもう少し掛かりそうです．
まとめと所感
「GoRails」で Rails の勉強をしてみました．説明が英語のため最初は慣れが必要そうですが，自動翻訳の力と実装したソースコードを自分なりに解釈していけば進めていけそうでした．
何点か質問事項も生まれ，質問するには英語でコメントする必要があります．そのため，英語力を勉強するきっかけやモチベーションの一つになりそうです．
現状，有料プランは 月額 19$ とちょっと手を伸ばせば払えそうな金額のため検討してみても良いなと思いました．
「もう少し検討してみたい！」という人は Free のコンテンツがあるのでこちらを見てみるのも良さそうです．
シス担ミートアップ#3 で AWS CodeBuild を CI 環境として使ってみた話をしました
9月頃になりますが「シス担ミートアップ」という社内イベントに登壇しました．イベント自体は3回目で，グループイン企業や投資先企業のエンジニアも参加し，様々な知見の共有や交流し，充実したイベントとなりました．
このイベントで私は， AWS CodeBuild（以下，CodeBuild） を CI として使ってみた話をしました．今回は登壇した資料についての補足や発表時にあまり話せていなかった内容を書いていこうと思います．
登壇資料
CircleCI のテスト実行待ち問題
当時のマイナビニュースでは CircleCI の「コンテナ課金プラン」を利用していました．CircleCI は GitHub.com の Organization 単位で利用することができます．Organization には他チームのリポジトリもあるため，CircleCI のコンテナを他チームと共同で利用することになります．
これにより，マイナビニュースで CircleCI を利用している時に他チームのテストの実行待ちが頻繁に発生し，開発の進捗が遅れるという問題が発生しました．
マイナビニュースが他の CI サービスに移行
CircleCI の契約コンテナ数を増やす案や DroneCI などの CI 環境を構築する案など，調査・検討をしましたが，その中で CodeBuild を CI として利用する事例があることを知りました．
他の企業での事例は少なかったですが，従量課金制で並列実行できる点やマイナビニュースでは既に AWS をインフラとして利用していたため導入が早いと判断し，CodeBuild を CI として利用することにしました．
CodeBuild では CircleCI のような複数のコンテナ指定ができない...
設定用の yml ファイル（buildspec.yml）の書き方が少し異なることや CI のログは CloudWatch Logs が必要になるなどの変更点はありましたが，ここまでで CircleCI との大きな違いはありませんでした，
しかし．一番の大きな違いは CodeBuild で設定する yml ファイルや CodeBuild のコンソール画面で複数のコンテナを指定することができないという点でした．CircleCI を利用していた時は Web や DB など複数のコンテナがある構成であったため，CodeBuild ではどのように表現すれば良いのか？というところでとても悩みました．
Docker in Docker で 複数のコンテナを利用することを表現する
複数コンテナを指定する方法についてさらに調べたところ，コンテナの中にさらに複数のコンテナを指定する Docker in Docker (以下，dind) を使った方法を知りました．
Docker 社が Docker Hub で配布している dind 用のコンテナイメージ CodeBuild のコンソールで指定し， 設定用の yml ファイルにdocker pullコマンド記載し，テストの実行に必要なコンテナイメージを pull する方法です．
他の企業での事例が少ないこともあり，挑戦するのがとても不安でしたが，何とか上記の構成で CI 環境を構築することができました．CodeBuild のコンソールでのコンテナの指定方法や設定用の yml ファイルの書き方については，スライドを見てみてください．
こうして現在では，CI 環境としてマイナビニュースは CodeBuild，他チームは CircleCI を利用しています．
CI の速度改善を試みる
「CodeBuild で CI 環境を構築できた！！めでたしめでたし...」という訳にもいかず，今度は CI の実行時間が遅いという課題が発生しました．
速度改善には色々な方法があるのですが，一番効果が高かったのは，CodeBuild のローカルキャッシュ機能の一つである「DockerLayerCacheをオン」する方法でした．この機能をオンにすることで，ビルドで利用した Dockerfile レイヤーを再利用することでき，結果として約9分短縮されました．
他のローカルキャッシュ機能やコンピューティングタイプを上げ，最終的には約25分→約13分代まで CI の実行時間を短縮することに成功しました．
この速度改善から数ヶ月後にソリューションアーキテクトの方とお話をする機会がありました．その時に今回やったことについて話した所，ローカルキャッシュ機能はあくまでベストエフォートな機能で，ビルドの間隔が空いた場合やビルドの並列度が高い(同じ時間に複数のビルドが実行される)場合はキャッシュが効かない時があるという話を聞きました．
これは実際に利用している私自身も「あれ？今回のビルドはキャッシュが効いてないな」と思う場面が何度かあり，納得しました．
その他運用していて遭遇したこと
他に遭遇したこととして，Codebuild 側で Linux コマンドなどのバージョンが上がった時に設定用の yml ファイルにあるコマンドのオプションの指定方法が変わったことで，CI が落ちることが何度かありました．その一例として過去に記事を書いております．
CodeBuild を利用するようになって，開発メンバーが約4人で月額の平均が約2000円とだいぶコストカットすることに成功しました．
しかし，上記のような管理コストも考えると，新たなプロダクトがリポジトリに追加され，そのプロダクトでも CI が必要になった時は，CircleCI や TravisCI などの CI サービスを利用することや DroneCI や Jenkins など違う種類の CI 環境の構築することなどを再検討してみても良いと考えました．
最近，CircleCI に 「Performanceプラン」という新しいプラン*1が登場したため気になっています．
まぁ CodeBuild の方が金銭コストが低く CI 環境を構築できることがわかってしまったので，開発効率を優先するのか，それとも金銭コストを優先するのかなどを開発チームや事業部全体で議論する必要があるかと思います．
まとめと所感
シス担ミートアップ#3 に登壇しました．当時の私の AWS の利用経験は Amazon S3 を少し使ったことあるくらい（前職では OpenStack によるプライベートクラウドをメインで利用していました）で，「そもそも AWS について色々調べないと！」みたいな状態でした．そのため，今回経験したことを通して AWS についてもよく知ることができたため，とても良い経験になりました．
また， CI 環境...というより，技術選定はパフォーマンスや開発効率を優先するだけではなく，選定したサービスやツールの金銭コストや運用コストについても考慮する必要があることを思い知らされました．
その点では技術選定の経験もできたため，これからも「発生している問題や課題に対して，解決をする方法」についての考え方やセンスを磨いていこうと思います．
*1:当時（CodeBuild への移行作業をしている時）は「Performanceプラン」が出るらしいというのを噂で聞いた状態でした．
環境変数によって実行するE2Eテストを変えられるようにする
引き続き Jest × Puppeteer でのE2Eテストのキャッチアップをしている．進めていくうちに，本番環境の他にステージング環境や検証環境に対してもE2Eテストを実行できるようにしたくなってきた．
そのため，今回は環境変数によって実行するE2Eテストが変えられるようにする方法を調べたのでまとめておく．
ソースコードはこちら github.com
やり方
環境変数を使いたい時はよく「dotenv」というnpmライブラリが登場するが，今回はE2Eテストを実行時に環境変数を指定し，特定のE2Eテストを実行できるようにした． www.npmjs.com
今回の記事用に本番環境やステージング環境が用意できなかったため，あくまでENVIRONMENTという環境変数の内容によって実行するE2Eテストが変わるように書いてみた．process.envを使って環境変数の内容を確認し，if文で実行するE2Eテスト変えるようにしている．
e2e-env.spec.js
describe('環境変数別にページが遷移するか', () => { if (process.env.ENVIRONMENT == 'GOOGLE') { beforeAll(async () => { await page.goto('https://www.google.co.jp/'); }); it('should be titled "Google"', async () => { await expect(page.title()).resolves.toMatch('Google'); }); } else if (process.env.ENVIRONMENT == 'YAHOO') { beforeAll(async () => { await page.goto('https://www.yahoo.co.jp/'); }); it('should be titled "Yahoo! Japan"', async () => { await expect(page.title()).resolves.toMatch('Yahoo! JAPAN'); }); } else { beforeAll(async () => { await page.goto('https://www.bing.com/'); }); it('should be titled "Bing"', async () => { await expect(page.title()).resolves.toMatch('Bing'); }); } });
実行してみる
実行する時は以下のように環境変数を指定して実行する．ENVIRONMENTにGOOGLEを指定したため，Google のトップページに遷移するE2Eテストを実行してみた．
$ ENVIRONMENT=GOOGLE npx jest ./e2e-env.spec.js
PASS ./e2e-env.spec.js
環境変数別にページが遷移するか
✓ should be titled "Google" (8ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 2.476s, estimated 3s
Ran all test suites matching /.\/e2e-env.spec.js/i.
もし，本当にアクセスされているのかを見たい場合はjest-puppeteer.config.jsのheadless:をfalseにした状態でE2Eテストを実行するとブラウザが自動で立ち上がり，目で見て確認することができる．
jest-puppeteer.config.js
module.exports = {
launch: {
-- headless: false,
++ headless: true,
},
};
まとめと所感
環境変数によって実行するE2Eテストが変えられるようにしてみた．過去に RSpec × Capybara で似たようなことをやったので Jest × Puppeteer でも実現できて良かった．検証時は意味もなく「dotenv」をインストールしたり，.envを作成してしまっていたが，結果的に新たなライブラリをインストールせずに実現できた．
今後はif文の部分を Rails の部分テンプレートのように共通化し，これから書くE2Eテストで呼び出すような使い方をしていこうと考えている．
GitHub の新機能「Code review assignment」を使ってみた
この記事は マイナビ Advent Calendar 2019 8日目の記事となります.
前日は「チャットボットをもくもくして運用した1年間の軌跡」でした．このチャットボット，普段は結構クレイジーな発言が多いですが投げかけた言葉に対して的確に答えたり，盛り上げてくれるようなことをたまに言うので社内で結構人気です．一番スゲーと思ったシーンはこちら（内容は意味わからない感じですが笑笑）．
なので↑の記事も是非見てみてください🤖．
前置きはこの辺にして，今回は先日開催された「GitHubUniverse」で発表された「Code review assignment」という機能の使い方についてまとめようと思います．
この機能を設定すると，プルリクエストのコードレビューでチームメンバーからレビュアーを自動でアサインすることができるようになります．
PRのコードレビューのアサインを自動で行えるようになります！アサインの方式はラウンドロビンとロードバランスの2つ。パブリックベータとして、すべてのOrganizationでお使いいただけます！ #GitHubUniverse pic.twitter.com/7NvXqcmCUN
— GitHub Japan (@GitHubJapan) 2019年11月13日
設定方法
公式のヘルプを見ながら設定していきます．
前提
「Teams」に設定する機能のため個人のリポジトリではなく，「Organizations」に所属しているリポジトリで設定できます．また，事前に Team を作成し「Code review assignment」を設定したいリポジトリに Team を追加する必要があります．
「Teams」の「Settings」で「Code review assignment」を設定する
「Teams」のページ（https://github.com/orgs/オーガニゼーション名/teams/リポジトリ名）にアクセスし，「Settings」を選択します．もし「Settings」が表示されない場合は権限が不足しているため管理者に自分のアカウントの権限を上げてもらうか，これから記載する内容を設定してもらうかを相談してみてください．
「Code review assignment」を選択します．
「Enable auto assignment」 にチェックを入れます．すると以下のように「How many team members should be assigned to review?」 （Teams のメンバー内でコードレビューにアサインする人数は何人に設定するか？）や「Routing algorithm」（アサインする時のアルゴリズム）などが表示されるため，設定します．
「Routing algorithm」は現在2つあります．1つ目の「Round robin」は各メンバーが今までアサインされたレビュー数に関係なく、チームメンバーが交互にアサインされるようにするアルゴリズムです．
2つ目の「Load balance」は各メンバーがアサインされたレビュー数に基づいてレビュアーを選択し，過去30日間で各メンバーがアサインされたレビュアー数が均等になるようにするアルゴリズムです．
他にもアサインの対象から除外するメンバーの設定やメンバーをアサインした時にチーム全体ではなく，アサインしたメンバーのみ通知するかどうかなどの設定があります．
今回は以下のように設定し，「Save Changes」を押して設定を保存します．
実際に使ってみる
さあ！実際に使ってみましょう！使い方は簡単で新規または既存のプルリクエストのページで「Reviewers」を選択し，「Code review assignment」を設定した Team を指定します．
※てっきりリポジトリに Team を設定すると「Reviewers」が指定されてないプルリクエストは自動でレビュアーをアサインをするものだと勘違いしていました😅
すると Team の中から1名のメンバーをレビュアーとしてアサインされました．これでもうレビュアーを誰にするか迷う必要は無くなりますね！！
まとめと所感
「Code review assignment」を使ってみました．設定で少し迷う（おそらく自分だけ...）ところはありましたが設定自体は簡単でした．
ちなみに業務では「Pull Panda」という GitHub Apps を使っています．GitHub が買収した企業のアプリで類似する機能がありますが，これからどんな差別化をしていくのか楽しみですね．
「GitHubUniverse」では他にも発表された機能があるので，利用可能になったタイミングで「良いな！！」って思った機能は使い方をまとめていこうと思います！！
マイナビ Tech Night #3 でチーム開発をする上でやってきたことについて話しました
この記事は，マイナビ Advent Calendar 2019 4日目の記事となります. 前日は「GCEインスタンスの起動/停止をローカルマシンと同期する」でした．ちょうど個人開発をやりたいと思っていて，課題だと思ったことを解決するヒントを貰えた記事でした．
先月「マイナビ Tech Night #3」でトーク枠で登壇しました．今年の1月から入社し，イベント当日までマイナビニュースでやってきたことを発表する内容となりました．
今回は登壇した資料についての補足や発表時にあまり話せていなかった内容を書いていこうと思います．
登壇資料
プルリクエストの情報が GitHub 上に無い😨
マイナビニュースで開発をする時，マイナビ側のエンジニアは GitHub *1 ，開発ベンダー側のエンジニアは GitLab というように Git のホスティングサービスが分かれていました．
これにより開発ベンダー側のプルリクエスト（GitLab で言うマージリクエスト）の情報が見ることができず，実装の意図を追うのが大変でした．また開発ベンダー側がリリース前にどのような開発プロセスを経ているのかをマイナビ側で細かく把握できなかったのも課題でした．
やったこと
まずは Git のホスティングサービスをマイナビの GitHub に統合するところから始めました．今までは開発ベンダーへ開発依頼をする時は，Redmine で依頼をしていたため，Redmine から移行し，マイナビの GitHub で開発する上での issueやプルリクエストの使い方についてなど開発フローを再整備しました．
マイナビ側で開発フローの案を出し，開発ベンダー側へフィードバックを貰いながら進めていきました．
次に CI 環境の構築です．マイナビの GitHub を開発ベンダーのエンジニアも使うということはマイナビの CI を使うことになります．しかし他のチームと共用で CircleCI を利用していたため，タダでさえ契約コンテナ数が少ない状態から CI を利用するエンジニアが増えるということになり，CI の実行待ちが増えることが容易に想像できました．
CircleCI の場合，現在では「PERFORMANCE プラン」に変更すると従量課金制になり， CI の実行待ちを気にする必要が無くなりますが，当時はすぐに何とかしないといけない課題であったため，マイナビニュースでは AWS CodeBuild で CI 環境を構築することにしました．
その時の登壇についてまだ記事を書いていないため近々書こうと思います．
追記(2019/12/15)
こちらの記事で詳細を書きました．
え！誰が今どの環境でデプロイしてるの？😕
検証環境へのデプロイやリリース作業をした後，Slack で開発メンバーへ報告していました．
しかし，手動で報告していることや報告する途中で割り込みのタスクが入ったことで結果的に報告ができず，他のメンバーの作業が止まることが何回か目立ちました．
やったこと
Capistrano をデプロイツールとして採用していたこともあり，「capistrano-releases-notification」でデプロイ時に Slack で通知し，「capistrano-github-releases」で該当のプルリクエストに自動でリリース報告のコメントと Releases と Tags を自動生成するようにしました．Releases と Tags はリリースノートとして機能するので便利です．
それぞれの gem の使い方については，過去に記事を投稿したのでもし興味があれば見てもらえたらと思います．
リニューアル時の流れで使っている Git-flow
当時は develop ブランチを親ブランチとして開発をしていました．しかし切り戻しがあった時の作業の煩わしさや Git-Flow を続ける理由も現状の開発では特に無かったため GitHub フローにした方が効率が良さそうという思いが強くなっていきました．
やったこと
GitHub フローに変更しました．作業自体は develop ブランチと master ブランチに差分が無いことを確認した後に develop ブランチを削除するだけです．
後は開発フローが少し変更になるためそのメンテナンス作業すればOKでした．親ブランチを作りたい場合は，各自で適宜作成するようにしています．
どの改善でも共通で言えること
今振り返ると今回のイベントで発表したことは作業の難易度自体はそこまで難しくないものだと思いました．しかし，その中で苦労した点は改善に至るまでの議論です．
「○○にした方が良いんじゃね？」だけだと，改善を進めていくうちに生まれる懸念事項への解決が上手くできなかったり，開発メンバーが納得しないまま進めてします場合があります．
そのため改善を進めるには「そもそもの課題は何か」，「課題が解決されたらどんな状態になるのか」などを明確・整理することで懸念事項への解決や開発メンバーへの納得を得ながら進める必要があると感じました．
苦労した点と書きましたが，ここは時間を掛けて進めるべき内容だと思います．というかこの内容を発表の時にもっと話せば良かったと後悔してます😅．
まとめと所感
「マイナビ Tech Night #3」 で登壇しました．入社からイベント当日までの振り返りにもなったのでとても良かったです．完全ベンダーコントロールから内製開発への割合を増やすという段階なこともあり，GitHub の使い方や CI 環境の構築など今まで自分が Join したチームでは前提だったことをマイナビニュースでゼロから作り上げていくような経験をすることができました．
現在はスライドの後半にあるサーバーサイド，フロントエンド，インフラでやっていくことに取り組んでいるので，次回があればこれらの内容について発表できればと思っています．
今回のイベントや登壇資料がこれから内製・半内製開発をする上でどんなことが必要になるのかを検討している方達へ少しでも参考になればと思います（「内製開発へのシフト」がテーマのイベントがあったら登壇してみたい機運が高まりました）．
追記（2019/12/16）
「Geekroid」にてイベントレポートが公開されました．
Watchman が原因で Jest でテストを実行しても動かない場合の対応方法
この記事は，マイナビ Advent Calendar 2019 1日目の記事となります.
前回，Jest と Puppeteer に入門するという記事を書いたが，その記事を書く過程でテストが上手く動かず，詰まってしまったのでどう対応したのかをまとめておく．
Jest でテストを実行しても動かない
作った E2Eテストを jest コマンドを実行したところ，Determining test suites to run...の表示で止まってしまい，テストが終わらない現象が発生した．
$ jest ./sum.test.js Determining test suites to run...
原因
公式リポジトリの issues を色々見てみたところ（結構奥深くまで見たので大変だった...） ，自分の PC に「Watchman」というライブラリがインストールされていることが原因で Jest が動かないという issue を見つけた．
「インストールした覚えが無いので，流石にこれではないだろう」と思いながらコマンドを確認してみた所，実はインストールされていたことがわかった．
$ which watchman /usr/local/bin/watchman
解決方法
解決方法は簡単で，brew uninstall watchman を実行し，Watchman を削除すれば， jest コマンドが動くようになった．
$ brew uninstall watchman Uninstalling /usr/local/Cellar/watchman/4.9.0_3... (23 files, 2MB) $ jest ./sum.test.js PASS ./sum.test.js ✓ adds 1 + 2 to equal 3 (4ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 0 total Time: 1.172s Ran all test suites matching /.\/sum.test.js/i.
Watchman とは？
「さぁこれで解決解決〜」と思って終わりにしようとしたが，そもそも Watchman とはどんなライブラリなのかを軽く調べてみた．
Watchman とは Facebook が開発したファイル/フォルダ監視ツールで，指定したファイルが変更されたら，それをトリガーに何らかのアクションを設定できるツールであることがわかった．
なぜ自分が Watchman をインストールしたのかを思い出してみたところ，過去に React Native を勉強してみようと思い，公式チュートリアルに沿って進めていたところ， Watchman をインストールする内容があり，その時にインストールしたことを思い出した．
今は React Native を触る機会が無いため Watchman をアンインストールをして解決したが，React Native のテストを Jest で書いている人は何らかの回避方法が必要であると思った．
この回避方法までは今回は調べないが今後 React Native を触る機会があれば検討する必要がある（すでに回避方法がありそうではあるが...）．
まとめと所感
今回は Jest でテストを実行したのに動かない場合の原因の一つについてまとめてみた．今回はそれらしいエラー文がコンソール上に表示されなかったので原因がわかるのに想定以上に時間が掛かった．
詰まったら，とりあえず公式のリポジトリを見に行く習慣はこの調子でやっていきたい．
