アクトインディ開発者ブログ

子供とお出かけ情報「いこーよ」を運営する、アクトインディ株式会社の開発者ブログです

Dependabot導入に挑戦してみてわかったあれこれ

こんにちは。kanekoです。

アクトインディでは評価制度の一環で半期ごとに各自が目標を立てます。 4月から社員になったので私も初めてエンジニアとしての目標を立てました!

そのうちの一つがgemなどのアップデートの自動化です。 そしてこの度、Dependabotを導入しました。

Dependabotはライブラリーの更新をチェックしてくれ、しかも変更をPull Requestにしてくれるとてもいい子です。 少し前にGitHubが買収したことで話題になりました。

Dependabotに限らず、すでに何かしらの仕組みを導入している方は多いと思いますので、「Dependabotでこうしてみたよ!」ということに加え、大きなサービスで導入するに当たって感じたことも言語化してみます。

私のように、経験値が低くて何するにもドキドキする!という人の参考になれば幸いです!

導入するまで

Dependabotを使うのは個人としても初めてだったので、会社で使う前に自分個人のrailsアプリに試験導入してみました。

「GitHubのMarketplaceから検索→サインアップ→適用したいリポジトリを選択→設定」であっという間に完了。

「これはいけるぞ」と思ったのですが、いざ会社のプロダクトでもやろうとするとちょっと勝手が違って戸惑いました。

戸惑い1. GitHub Organizatiosと権限

Organizationにはいくつか所属してるものの、そこに何かを導入するのは初めてのことでした Dependabotにサインイン後このような画面になります。 アクトインディのOrganizationに導入するにはリクエストを送って許可を得ないといけません。

gyazo.com

「承認制はわかるとして、だれが承認してくれるんだ?」というのを理解していなかったので、リクエストを送った後「訳も分からず送ってしまった」と、Slackで「誰かにリクエストが飛んでいるはずなのだけどどうしたらいいですか」ってヘルプを出して一人であたふたしてました笑

Organizationのメンバーには役割があって、一覧を見ると画像のように誰がなんの役割かわかります。リクエストを承認してくれるのはOwnerのアカウントです。私のアカウントはMemberなのでそんな権限はありません。権限があれば自分でリクエストをして自分で承認もできるはず。

gyazo.com

Organizationsについての詳細はGitHub HelpのOrganizing members into teamsに書いてあります。初めて読んだのですが便利便利。

Dependabot使いたいんだということはその前にチームで共有していたので「大丈夫よー」という感じで権限ある方が優しく承認してくださいました。

戸惑い2. ライブラリーの数

Dependabotをインストールすると次に設定に移ります。 まず、チェックしたいライブラリーの言語の選択をするのですが、設定を保存すると、最初のアップデートチェックが走ります。ライブラリー1つにつき1つPull Requestが作成されます。すると、画像のようにずらっとプルリクエストが!

gyazo.com

デフォルトで毎日チェックが走るようになっていて、最初は「とりあえずデフォルトで」としていました。 すると(当然)翌日もその翌日も次々とプルリクエストが!!!

今振り返ると、数が多くても少なくてもマージする基準を満たしていればマージ、そうでなければ最悪マージしなければいいだけなので、そんなに戸惑わなくてもよかったなあと思うのですが、その時は「こんなに大量に!どうしよう!なんだかやばいことをやらかしてしまったかもしれない」と、”何もしてないのに壊れました”みたいな気持ちになりました。(大丈夫、何も壊れてはない)

個人でちょろっと使ってみるのとは、使い方は同じでもそれ以外が全然違うというのを体感できました!

マスターにマージするまで

条件

Pull Requestをマスターにマージする条件を次の2つとしました。

  1. テストが通ること
  2. 動作確認に問題ないこと

普通のPull Requestとだいたい同じ。 でも「どうやってやろうか」というのをあれこれ考えました。

テスト

アクトインディではPull Requestのラベルに「自動テスト対象」というのがあって、それを貼るとテストが走るようになっています。

Dependabotの設定でPull Request作成時にラベルをつけるように指定できるので、「自動テスト対象」を貼る設定にしました。これでOpenと同時にテストが走って結果も残るので、テストの確認は簡単にできるようになりました。

gyazo.com

動作確認

その次は動作確認ができるようにすることでした。

現在のアクトインディの開発体制としては、ブランチに命名規則があって、GitHubで新しいブランチにコミットがあるとステージングが作成されるようになっています。

DependabotのPull Request単体では命名規則則っていないためステージングでの確認ができません。

なので、画像のように新しくブランチを作って、テストが通ったものをどんどん集約してまとめて動作確認することにしました。

gyazo.com

その他

今はまだGitHubに差分を出さずに気軽に設定したいと思ったので画面上で設定をいじっているのですがDependabot config filesにあるようにファイルで管理することができます。そろそろこちらに移行してみようかと考えています。

また、automerged_updatesという便利な機能があって、"Automerged updates is currently in closed beta, contact support@dependabot.com to enable it on your account."というのをみて連絡したら早々に使えるようにしてもらえたので、先ほどの集約するブランチには基本的にこの設定でオートマージしていきたいと思っています。

最後に

以上、とりとめもない文章ですが、私にとって目標という口実で「こういうことがしてみたいです!」といって初めて挑戦したみた、アップデートの自動化への取り組みとその様子と感想をお送りしました。今後ももっと効率よくやっていけるように改良を重ねていこうと思っています。

アクトインディではベテランも新人も、経験問わずやってみたいことをやってみる環境が整っています! 何かに挑戦したい人はぜひこちらもご覧ください!

actindi.net