Railsアップグレードのガイドライン

パフォーマンス、セキュリティアップデート、新機能の恩恵を受けるために、私たちは最新のRailsリリースを使ってGitLabを運営するよう努めています。

Rails アップグレードのアプローチ

  1. GitLab用のMRを準備します。
  2. GitalyのMRを準備します。
  3. セキュリティパッチのパッチリリースとバックポートの作成。

GitLab 用の MR の準備

  1. Ruby on Rails のアップグレードガイドを確認し、今後の変更に備えてアプリケーションを準備しましょう。
  2. Gemfile のrails gem バージョンを更新します。
  3. bundle update rails を実行してください。
  4. アップデートタスクの実行rake rails:update.
  5. qa/Gemfile のactivesupport バージョンを更新します。
  6. qa フォルダー内のbundle update --conservative activesupport を実行してください。
  7. Bundlerの競合を解決します。
  8. @rails/ujs と@rails/actioncable の npm パッケージがpackage.jsonの新しい Rails バージョンと一致していることを確認します。
  9. 更新後にyarn patch-package @rails/ujs を実行して、ローカルのパッチファイルのバージョンが一致していることを確認してください。
  10. pipeline:run-all-rspec のラベルで MR を作成し、パイプラインが壊れるかどうかを確認してください。
  11. Railsリポジトリに対してgit bisect 。以下のデバッグのセクションを参照してください。
  12. マージリクエストの説明に、2つのバージョン間のGem diffへのリンクを含めてください。例えば、これはactivesupport 6.1.3.2 から 6.1.4.1 の gem diff です。

Gitaly用のMRの準備

  1. GitalyのGemfileの activesupport gemのバージョンを更新します。
  2. bundle update --conservative activesupport を実行してください。
  3. これらの変更を加えたGitalyプロジェクトに対してMRを作成します。
  4. このMRをGitLabプロジェクトで作成されたMRに依存させます。
  5. GitLabプロジェクトのMRをマージした後にのみ、このMRをマージ。

セキュリティパッチのパッチリリースとバックポートの作成

Railsのアップグレードがパッチリリース以上であり、重要なセキュリティ修正が含まれている場合は、必ずGitLabパッチリリースで自主管理顧客にリリースしてください。進め方についてはリリースマネージャに相談してください。

非推奨ロガー

また、RubyとRailsの非推奨に関する警告を専用のログファイルlog/deprecation_json.log に記録しています。 テストで十分にカバーされておらず、DeprecationToolkitEnv を通過してしまうようなコードがある場合に手がかりとなります。

GitLab SaaSの場合、GitLabのチームメンバーはKibana (https://log.gprd.gitlab.net/goto/f7cebf1ff05038d901ba2c45925c7e01) でこれらのログイベントを調べることができます。

Railsに対するGitバイセクト

通常、specの失敗の原因となったRailsの変更がわかれば、コンテキストが追加され、失敗の修正を見つけるのに役立ちます。specの失敗の原因となったRailsの変更を効率的かつ迅速に見つけるには、Railsリポジトリに対してgit bisect ：

  1. お好みのフォルダにrails プロジェクトをクローンします。たとえば、GDKのルートディレクトリなどです：

    cd <GDK_FOLDER>
git clone https://github.com/rails/rails.git

  2. GitLabGemfile のgem 'rails' 行を置き換えてください：

    gem 'rails', ENV['RAILS_VERSION'], path: ENV['RAILS_FOLDER']

  3. RAILS_FOLDER 環境変数に Rails をクローンしたフォルダを設定します：

    export RAILS_FOLDER="<GDK_FOLDER>/rails"

  4. ディレクトリをRAILS_FOLDER に変更し、git bisect コマンドの範囲を設定します：

    cd $RAILS_FOLDER
git bisect start <NEW_VERSION_TAG> <OLD_VERSION_TAG>

    ここで、<NEW_VERSION_TAG> は仕様が赤のタグ、<OLD_VERSION_TAG> は仕様が緑のタグです。例えば、バージョン6.1.3.2から6.1.4.1にアップグレードする場合、git bisect start v6.1.4.1 v6.1.3.2 。<NEW_VERSION_TAG> を仕様が赤のタグに、<OLD_VERSION_TAG> を仕様が緑のタグに置き換えてください。例えば、バージョン6.1.3.2から6.1.4.1にアップグレードする場合は、git bisect start v6.1.4.1 v6.1.3.2 。出力では、コミットを見つけるまでにおよそ何ステップかかったかがわかります。

  5. git bisect プロセスを起動し、spec のファイル名を引数としてscripts/rails-update-bisect に渡します。specファイル全体ではなく、1つの例だけを選んだ方が速い場合があります。

    git bisect run <GDK_FOLDER>/gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb
# OR
git bisect run <GDK_FOLDER>/gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb:7
  6. 処理が完了すると、git bisect にコミットハッシュが表示されます。このハッシュを使用して、rails/rails リポジトリで対応する MR を見つけることができます。
  7. bisect モードを終了するにはgit bisect reset を実行します。

  8. Gemfile に変更を戻します：

    git checkout -- Gemfile

フォローアップ資料