InfoGrab DocsInfoGrab Docs

Rails 업그레이드 가이드라인

요약

성능, 보안 업데이트, 새 기능의 혜택을 받기 위해 최신 Rails 릴리스로 GitLab을 운영하는 것을 목표로 합니다. 보안 패치를 위한 패치 릴리스 및 백포트 생성. Ruby on Rails 업그레이드 가이드를 확인하고, 향후 변경 사항에 맞게 애플리케이션을 준비하세요.

성능, 보안 업데이트, 새 기능의 혜택을 받기 위해 최신 Rails 릴리스로 GitLab을 운영하는 것을 목표로 합니다.

Rails 업그레이드 접근 방식#

GitLab용 MR 준비#

  • Ruby on Rails 업그레이드 가이드를 확인하고, 향후 변경 사항에 맞게 애플리케이션을 준비하세요.

  • Gemfile에서 rails gem 버전을 업데이트하세요.

  • bundle update --conservative rails를 실행하세요.

  • 메이저 및 마이너 버전 업데이트의 경우, bin/rails app:update를 실행하고 제안된 변경 사항 중 적용해야 할 것이 있는지 확인하세요.

  • qa/Gemfile에서 activesupport 버전을 업데이트하세요.

  • qa 폴더에서 bundle update --conservative activesupport를 실행하세요.

  • find gems -name Gemfile -exec bundle update --gemfile {} activesupport --patch --conservative \;를 실행하고, 필요에 따라 명령어의 --patch--minor 또는 --major로 교체하세요.

  • Bundler 충돌을 해결하세요.

  • package.json에서 @rails/ujs@rails/actioncable npm 패키지가 새 Rails 버전과 일치하는지 확인하세요.

  • 업데이트 후 yarn patch-package @rails/ujs를 실행하여 로컬 패치 파일 버전이 일치하는지 확인하세요.

  • pipeline:run-all-rspec 라벨을 붙여 MR을 생성하고 파이프라인이 깨지는지 확인하세요.

  • spec 실패를 해결하고 디버깅하려면 rails 리포지터리에 대해 git bisect를 사용하세요. 아래의 디버깅 섹션을 참조하세요.

  • 머지 리퀘스트 설명에 두 버전 간의 Gem 차이 링크를 포함하세요. 예를 들어, 이것은 activesupport 6.1.3.2에서 6.1.4.1로의 gem 차이입니다.

Gitaly용 MR 준비#

Gitaly에 더 이상 Ruby 코드가 없으므로 더 이상 필요하지 않습니다.

보안 패치를 위한 패치 릴리스 및 백포트 생성#

Rails 업그레이드가 패치 릴리스를 통해 이루어졌고 중요한 보안 수정이 포함된 경우, GitLab 패치 릴리스를 통해 Self-managed 고객에게 릴리스되었는지 확인하세요. 진행 방법에 대해서는 릴리스 매니저에게 문의하세요.

Deprecation Logger#

Ruby 및 Rails 지원 중단 경고를 전용 로그 파일인 log/deprecation_json.log에 기록합니다. 이는 테스트로 충분히 커버되지 않아 DeprecationToolkitEnv를 통과할 수 있는 코드가 있을 때 단서를 제공합니다.

GitLab.com의 경우, GitLab 팀원은 Kibana(https://log.gprd.gitlab.net/goto/f7cebf1ff05038d901ba2c45925c7e01)에서 이러한 로그 이벤트를 확인할 수 있습니다.

Rails에 대한 Git bisect#

일반적으로 어떤 Rails 변경이 spec 실패를 일으켰는지 알면 추가적인 컨텍스트가 생기고 실패에 대한 수정을 찾는 데 도움이 됩니다. 어떤 Rails 변경이 spec 실패를 일으켰는지 효율적이고 빠르게 찾으려면 Rails 리포지터리에 대해 git bisect 명령어를 사용할 수 있습니다:

원하는 폴더에 rails 프로젝트를 클론하세요. 예를 들어, GDK 루트 디렉터리일 수 있습니다:

cd 
git clone https://github.com/rails/rails.git

GitLab Gemfilegem 'rails' 줄을 다음으로 교체하세요:

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

Rails를 클론한 폴더로 RAILS_FOLDER 환경 변수를 설정하세요:

export RAILS_FOLDER="/rails"

RAILS_FOLDER 디렉터리로 변경하고 git bisect 명령어의 범위를 설정하세요:

cd $RAILS_FOLDER
git bisect start  

는 spec이 실패하는 태그이고, 는 spec이 성공하는 태그입니다. 예를 들어, 버전 6.1.3.2에서 6.1.4.1로 업그레이드하는 경우 git bisect start v6.1.4.1 v6.1.3.2입니다. 를 spec이 실패하는 태그로, 를 spec이 성공하는 태그로 교체하세요. 예를 들어, 버전 6.1.3.2에서 6.1.4.1로 업그레이드하는 경우 git bisect start v6.1.4.1 v6.1.3.2입니다. 출력에서 커밋을 찾는 데 대략 몇 단계가 필요한지 확인할 수 있습니다.

git bisect 프로세스를 시작하고 scripts/rails-update-bisect에 인수로 spec 파일명을 전달하세요. 전체 spec 파일 대신 하나의 예시만 선택하면 더 빠를 수 있습니다.

git bisect run /gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb
# OR
git bisect run /gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb:7

프로세스가 완료되면, git bisect는 커밋 해시를 출력하며, 이를 사용해 rails/rails 리포지터리에서 해당 MR을 찾을 수 있습니다.

git bisect reset을 실행하여 bisect 모드를 종료하세요.

Gemfile의 변경 사항을 되돌리세요:

git checkout -- Gemfile

추가 읽기 자료#

Rails 업그레이드 가이드라인

GitLab v19.1
원문 보기
요약

성능, 보안 업데이트, 새 기능의 혜택을 받기 위해 최신 Rails 릴리스로 GitLab을 운영하는 것을 목표로 합니다. 보안 패치를 위한 패치 릴리스 및 백포트 생성. Ruby on Rails 업그레이드 가이드를 확인하고, 향후 변경 사항에 맞게 애플리케이션을 준비하세요.

성능, 보안 업데이트, 새 기능의 혜택을 받기 위해 최신 Rails 릴리스로 GitLab을 운영하는 것을 목표로 합니다.

Rails 업그레이드 접근 방식#

GitLab용 MR 준비#

  • Ruby on Rails 업그레이드 가이드를 확인하고, 향후 변경 사항에 맞게 애플리케이션을 준비하세요.

  • Gemfile에서 rails gem 버전을 업데이트하세요.

  • bundle update --conservative rails를 실행하세요.

  • 메이저 및 마이너 버전 업데이트의 경우, bin/rails app:update를 실행하고 제안된 변경 사항 중 적용해야 할 것이 있는지 확인하세요.

  • qa/Gemfile에서 activesupport 버전을 업데이트하세요.

  • qa 폴더에서 bundle update --conservative activesupport를 실행하세요.

  • find gems -name Gemfile -exec bundle update --gemfile {} activesupport --patch --conservative \;를 실행하고, 필요에 따라 명령어의 --patch--minor 또는 --major로 교체하세요.

  • Bundler 충돌을 해결하세요.

  • package.json에서 @rails/ujs@rails/actioncable npm 패키지가 새 Rails 버전과 일치하는지 확인하세요.

  • 업데이트 후 yarn patch-package @rails/ujs를 실행하여 로컬 패치 파일 버전이 일치하는지 확인하세요.

  • pipeline:run-all-rspec 라벨을 붙여 MR을 생성하고 파이프라인이 깨지는지 확인하세요.

  • spec 실패를 해결하고 디버깅하려면 rails 리포지터리에 대해 git bisect를 사용하세요. 아래의 디버깅 섹션을 참조하세요.

  • 머지 리퀘스트 설명에 두 버전 간의 Gem 차이 링크를 포함하세요. 예를 들어, 이것은 activesupport 6.1.3.2에서 6.1.4.1로의 gem 차이입니다.

Gitaly용 MR 준비#

Gitaly에 더 이상 Ruby 코드가 없으므로 더 이상 필요하지 않습니다.

보안 패치를 위한 패치 릴리스 및 백포트 생성#

Rails 업그레이드가 패치 릴리스를 통해 이루어졌고 중요한 보안 수정이 포함된 경우, GitLab 패치 릴리스를 통해 Self-managed 고객에게 릴리스되었는지 확인하세요. 진행 방법에 대해서는 릴리스 매니저에게 문의하세요.

Deprecation Logger#

Ruby 및 Rails 지원 중단 경고를 전용 로그 파일인 log/deprecation_json.log에 기록합니다. 이는 테스트로 충분히 커버되지 않아 DeprecationToolkitEnv를 통과할 수 있는 코드가 있을 때 단서를 제공합니다.

GitLab.com의 경우, GitLab 팀원은 Kibana(https://log.gprd.gitlab.net/goto/f7cebf1ff05038d901ba2c45925c7e01)에서 이러한 로그 이벤트를 확인할 수 있습니다.

Rails에 대한 Git bisect#

일반적으로 어떤 Rails 변경이 spec 실패를 일으켰는지 알면 추가적인 컨텍스트가 생기고 실패에 대한 수정을 찾는 데 도움이 됩니다. 어떤 Rails 변경이 spec 실패를 일으켰는지 효율적이고 빠르게 찾으려면 Rails 리포지터리에 대해 git bisect 명령어를 사용할 수 있습니다:

원하는 폴더에 rails 프로젝트를 클론하세요. 예를 들어, GDK 루트 디렉터리일 수 있습니다:

cd 
git clone https://github.com/rails/rails.git

GitLab Gemfilegem 'rails' 줄을 다음으로 교체하세요:

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

Rails를 클론한 폴더로 RAILS_FOLDER 환경 변수를 설정하세요:

export RAILS_FOLDER="/rails"

RAILS_FOLDER 디렉터리로 변경하고 git bisect 명령어의 범위를 설정하세요:

cd $RAILS_FOLDER
git bisect start  

는 spec이 실패하는 태그이고, 는 spec이 성공하는 태그입니다. 예를 들어, 버전 6.1.3.2에서 6.1.4.1로 업그레이드하는 경우 git bisect start v6.1.4.1 v6.1.3.2입니다. 를 spec이 실패하는 태그로, 를 spec이 성공하는 태그로 교체하세요. 예를 들어, 버전 6.1.3.2에서 6.1.4.1로 업그레이드하는 경우 git bisect start v6.1.4.1 v6.1.3.2입니다. 출력에서 커밋을 찾는 데 대략 몇 단계가 필요한지 확인할 수 있습니다.

git bisect 프로세스를 시작하고 scripts/rails-update-bisect에 인수로 spec 파일명을 전달하세요. 전체 spec 파일 대신 하나의 예시만 선택하면 더 빠를 수 있습니다.

git bisect run /gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb
# OR
git bisect run /gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb:7

프로세스가 완료되면, git bisect는 커밋 해시를 출력하며, 이를 사용해 rails/rails 리포지터리에서 해당 MR을 찾을 수 있습니다.

git bisect reset을 실행하여 bisect 모드를 종료하세요.

Gemfile의 변경 사항을 되돌리세요:

git checkout -- Gemfile

추가 읽기 자료#