APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > CI/CD > renovate導入は継続的な改善が重要

renovate導入は継続的な改善が重要

CI/CD Renovate
＜ techblogAPCについて（はじめにお読み下さい） ＞

renovate導入したらそこはゴールではなくスタート地点だった

先日 ライブラリ自動更新に renovate を導入したときの状況をご紹介しました。

techblog.ap-com.co.jp

やはり数日で、「ここはちょっと変えたいな」というところが出てきました。 今回はその対応内容についてご紹介したいと思います。

起きたこと

  • 内部依存関係のライブラリバージョンがダウングレードしてしまう
  • 毎日実行は頻度が多すぎる

実行内容調整

内部依存ライブラリバージョンがダウングレードしてしまう

rxjs 7を使っているプロジェクトがあるのですが、そこでrenovateを実行すると、内部依存関係にある rxjsのバージョンが6を取得するようpackage-lock.jsonが更新されました。 ローカルでnpm installし直すとなぜかpackage-lock.jsonが更新されていたのでなんでだろうと 思ったら、rxjs 7をダウンロードするようになるためでした。

実は・・・package.jsonでoverrideを指定していたんですね。このことをすっかり忘れていました。 overrideはnpm 8.3からサポートされたもので、それ以前のバージョンでは（当然ながら）機能してくれません。

  "overrides": {
    "rxjs": "~7.5.5"
  },

renovateを実行しているnodeのバージョンがちょっと古くてnpm8.1あたりのバージョンで実行するようになっていました。 なので、せっかくの指定も無視されていたということです。ローカル環境は当然有効になるようなNodeのバージョンを 使っていたので今回の事象になりました。

renovate直接の問題ではありませんが、renovateを実行する環境にも気をくばる必要がありますね。

renovateではどのバージョンのnpmを利用するかの指定があります。（package.json内のengines指定もそのひとつです） とはいえ、実行環境でサポートされていないものはどうにもならないと思うので、実行するnodeのバージョンもちゃんと メンテナンスしましょう。

今回の環境はazure pipelinesを利用していますが、その設定内容（一部）がこちらです

- task: NodeTool@0
  inputs:
    versionSpec: '16.17.x'    # ＜＝　ここで実行するnodeのバージョンを指定
  displayName: 'Install Node.js'

- bash: |
    git config --global user.email "xxx@example.com"
    git config --global user.name 'Renovate Bot'
    npx renovate      
  env:
    TOKEN: $(System.AccessToken)
    RENOVATE_TOKEN: $(GitHubToken) # get a token from https://github.com/settings/tokens and save it in the 'renovatebot' variables group
    RENOVATE_CONFIG_FILE: ".azure-pipelines/renovate-config.js" # use this environment variable if you prefer to have the renovate pipeline definition and the config file in it's own dictionary instead of the repository root.

これらを指定してrenovateを実行したところ、内部依存のrxjsバージョンダウングレード問題は解消しました。

実行頻度

設定当初は様々な課題が出るだろうと毎日1回実行するようにしました。対象リポジトリは4つ程度（3つはTypescript、1つはC#のアプリケーションです）。また、当初は自動マージまで実行せずに少し様子をみようということでPullReqの作成までとしました。 そうした中でこのリポジトリ数でも毎日のようにPullReqをが作成され、マージの処理しなければならないような状態になりました。結果、「毎日のように対処していて面倒だな」と感じるようことに。このままではRenovate導入は逆効果と言われかねません。 当初は様々な不安がありますからPullReqまでにして少し様子を見るのは良いことだと思います。しかし、やはり早い段階でマージまで自動化することをおすすめします。そうすることで「面倒」ということはなくなっていくと思います。そのためにも、テスト等を充実させておくことをおすすめします。また、すべてを自動マージするというのも難しいので、Major/Minor/Patchのそれぞレベルで、「Renovateの対象としない（すべて手動で対応する）」、「PullReqまでは自動作成する」、「マージまで自動化する」といった方針を決めなければなりません。その上で、適切な間隔でRenovateを実行するのがよさそうです。リポジトリ間の依存関係がある場合は、その関係を踏まえて実行タイミングを調整することも重要です。

これからも継続して調整

導入してすぐに、Renovateの設定は、最初から正解のものを作るというものではないと感じました。 組織の方針、言語などRenovateの対象、使用しているフレームワーク、作成しているテストの内容など、さまざまな要素で設定方針が少しずつ違うものになると思います。このため、早い段階で一部リポジトリを対象にRenovateを導入しつつ設定を細かく調整しながら自動化の精度をあげていくことが重要です。そしてある程度固まってきてから設定をテンプレート化していくとよいと思います。

まだまだ細かい調整は続いていますので、まとまったものができましたらまたご紹介したいと思います。 またの機会にご期待ください。