はじめに
みなさん、こんにちは!@m3m0r7です。 弊社では、最近 Renovate と呼ばれる依存関係を自動でバージョンアップするライブラリを取り入れました。
Renovate の導入
私自身は存在を知らなかったのですが、弊社フロントエンドリードの znppunfuv が導入を率先してくれました! (本人の代打で私が書いています!)
弊社はバックエンドとフロントエンドは完全にリポジトリが分離されている一方、Renovate はバックエンドやフロントエンド問わず数多くの言語に対応をしており、 ライブラリが自動的にアップデートされるようになっています。
PHP であれば composer require <dependency-name>:"X.Y.Z"
と一個一個やる必要がありますが、わざわざやるのは非効率ですし、
何が最新のバージョンであるかの把握も導入しているライブラリの数だけ目視で確認をする必要があり、なおさら非効率です。
そこで Renovate を取り入れることで自動化するようにしました。
例えば弊社だとバックエンド側に Elasticsearch の SDK を導入しているのですが、以下の画像のように 7.8
から 7.13.1
へ
Renovate の bot が自動でアップデートしてくれるためのプルリクエストを建てるようになっています。
上記はバックエンドの例ですね。もちろん、フロントエンドも package.json を更新したプルリクエストを建ててくれます。
これ以外にも、Dockerfile の更新にも対応していたり、エンジニア自身がライブラリの更新があった際にわざわざプルリクエストを建てる必要がなくなったため、 プロダクト開発に注力しやすくなり、相対的な開発効率も上昇したと言えるかなと思います。
ただ、Renovate はセマンティックバージョニングが正しいということを前提にしている部分があります。 一部のライブラリではパッチバージョンの更新でも後方互換のない破壊的変更や新機能追加等が入ってしまっている場合もあるため、 そのまま建てられたプルリクエストをマージしていいかというと、そうでもないといったことが注意点です。
また当初導入時は 1 つのライブラリで 1 つのプルリクエスト、アップデートする時間帯は特に指定しなかったので、Slack の GitHub 通知用チャンネルが大荒れすることもありました。 バージョンを上げる活動をサボっていたツケが来てしまったのです。
そして、GitHub Actions の時間をひたすら食っていくような状態でした。
実は Renovate にはアップデートを指定するタイミングやグルーピング機能があって、弊社では以下のように 朝 6 時と夜 10 時にプルリクエストを作成するように、なおかつパッチバージョンをまとめるように renovate-config を設定しています。
{ "hostRules": [ { "matchHost": "https://npm.pkg.github.com/", "hostType": "npm", "encrypted": { "token": "<TOKEN>" } } ], "npmrc": "@torana-us:registry=https://npm.pkg.github.com/", "extends": [ "config:base" ], "timezone": "Japan", "schedule": [ "after 10:00pm and before 06:00am every weekday", "every weekend" ], "semanticCommits": "enabled", "labels": [ "dependencies" ], "vulnerabilityAlerts": { "rangeStrategy": "update-lockfile", "commitMessageSuffix": "[SECURITY]", "branchTopic": "{{{datasource}}}-{{{depName}}}-vulnerability", "labels": [ "security" ] }, "packageRules": [ { "groupName": "patches", "groupSlug": "update-patches", "matchUpdateTypes": [ "patch" ] } ], "ignoreDeps": [ "npm" ] }
上記のように設定しているおかげで、バックエンド側では以下のように、パッチバージョンが更新されたものをまとめて 1 つのプルリクエストに集約できています。
さいごに
プロダクト開発はただ新しく作るだけではなく、以後のメンテナンス性を向上させるため、既存のコードの治安を維持していくための取り組みも必要だと開発部全体で考えています。 そのため、治安維持活動を率先していたり、目標設定にも治安維持活動やリファクタリングなどを設定したりと、実際に業務で取り組んで頂くような開発部の文化として醸成できているんじゃないかなと私は思っています!
もし、弊社に少しでも関心を持っていただけるようでしたら、お気軽にカジュアル面談から始めましょう!フロントエンドもバックエンドも共に働く仲間を探しています。