gemアップデート体制について

各社、色々な言語を用いて日々プロダクトを磨いていらっしゃる事と思います。
ただ、OSSを用いて開発を効率化されている点は共通している事と思います。
そこで悩まされるのが、OSSのバージョンアップデートのタイミングではないでしょうか。

弊社ではバックエンドではRuby on Railsを用いていますが、以前、Ruby on Rails関連の勉強会に参加した際、gem(Rubyのサードパーティのライブラリ(≒ RubyのOSSライブラリ))のアップデートを放置し続けた結果、その後のアップデートが大変だったという話を伺った事があります。

各社、決まったタイミングで手動で実施したり、自動的にアップデートするようにしていたり、やり方は千差万別あるかと思いますが、弊社では、以下のようなやり方を採用しております。

1.利用しているgemをマイナーバージョンのアップデートのみ行うよう設定する。

2.CircleCIのスケジューラー設定機能を使って、毎月1日に自動でbundle updateコマンドを動作させ、
  GemfileやGemfile.lockに関するプルリクを作成するようにしている。

3.bundle updateのプルリクを開発メンバーでチェックする。

4.GitHubのセキュリティーアラート機能に反応するgemがあった場合は速やかにバージョンアップを図る。

1.利用しているgemをマイナーバージョンのアップデートのみ行うよう設定

バージョンは各言語、利用されているツールによって微妙に読み方が異なるようですが、「X.X.X.X」のように4桁の数値ですと、一般的には以下のように読まれるケースが多いようです。

左から1桁目の数値:メジャーバージョン
左から2桁目の数値:マイナーバージョン
左から3桁目の数値:ビルドバージョン(サービスリリースから何番目に作られたかという番号)
左から4桁目の数値:リビジョン(ビルドバージョンに対し、何回修正がかけられたかという番号)

gemの場合、バージョンの記述が4桁の数値になるケースもありますが、3桁の指定が大半です。
多くの方がお世話になった事がある、Railsチュートリアルを見ると、
https://railstutorial.jp/chapters/beginning?version=5.1#sec-bundler

左から2桁目の数値のバージョンアップをメジャーアップデート、左から3桁目の数値をマイナーバージョンアップと記述しているため、ここでは、その呼び方を採用します。

gemをマイナーバージョンのみアップデートする記述は以下のように行います。
https://guides.rubygems.org/patterns/#pessimistic-version-constraint

このように記述しておく事で、bundle updateしても3桁目のみバージョンアップされるようになります。
gem ‘devise’, ‘~> 4.6.0’

Gemfile.lockに現在利用している各gemのバージョンが記述されています。
そのため、Gemfile.lockを参照しながら各gemに ‘~> X.X.X’を追記しました。

2.bundle update自動化およびプルリクの自動作成

CircleCI2.0からcron機能が利用できるようになってるので、毎月1日に動作させるようにしています。
GitHub上でbundle update用gemはいくつか見かけましたが、個人用リポジトリだったりしてメンテ頻度不明なため、
今は、CircleCIの記述のみで対応できるようにしてます。

※設定した内容はこちら
https://qiita.com/dmiya/items/ea422e1a9583d288562c

3.bundle updateのプルリクを開発メンバーでチェック

自動作成されたGemfileやGemfile.lockのプルリク内容を開発メンバーでチェックします。

RSpecでテストを書いているので、プルリクが出される度、自動でテストを動かし動作検証してますが、サービスリリースを優先させるなど諸般の事情により、テストカバレッジが100%ではございません。

そこで、テストが書けていない部分で、今月のbundle updateにてマイナーバージョンアップされたgemがあれば、新規にテストを書いてチェックしたり、簡単に動作確認したりして問題ないかチェックします。

こうする事で、bundle updateした結果、不具合が発生するリスクを回避しております。

4.GitHubのセキュリティーアラートに反応するgemは速やかにバージョンアップ

ここまでご覧いただいた方の中にはメジャーアップデートはじゃあどうするのだろう?、と疑問に思われていらっしゃる方もいるかもしれません。

ここは意見が分かれる部分もあるとは思いますが、弊社の場合、マイナーバージョンアップデートは毎月実施し、GitHubのセキュリティーアラートにひっかからなければ良いというスタンスを現状採用しました。というのも、開発リソースも限られている中で他にやるべき事は多数存在します。

メジャーアップデートを頻繁に実施されていらっしゃる方々の中には実際直面した方もいらっしゃるかもしれませんが、メジャーアップデートすると、それまで動作していた機能が変わってしまってプログラムの修正が発生してしまう事があります。テストを書いているので動作が変わった事も検知できはしますが、動作変更に対応するとなると予定している開発ができなくなる恐れが出てきます。

まとめ

手探りな部分ではありますが、現時点ではメジャーアップデートを積極的には追わないがセキュリティーリスクなどは避けるべくマイナーバージョンアップは積極的に対応するというスタンスに落ち着いてます。

以上が弊社の現状のgemのアップデート体制になります。
機会があれば他社の方々のご意見や知見を伺ってみたいです。