Rails 업그레이드 지침

우리는 성능, 보안 업데이트 및 새로운 기능의 이점을 누리기 위해 GitLab을 최신 Rails 릴리스를 사용하여 실행하려고 노력합니다.

Rails 업그레이드 접근 방식

GitLab을 위한 MR 준비.
보안 패치를 위한 패치 릴리스 및 백포트 생성.

GitLab을 위한 MR 준비

Ruby on Rails 업그레이드 가이드를 확인하고 애플리케이션을 다가오는 변경 사항에 맞게 준비합니다.
Gemfile에서 rails 젬 버전을 업데이트합니다.
bundle update --conservative rails를 실행합니다.
주 버전 및 소 버전 업데이트의 경우, bin/rails app:update를 실행하고 제안된 변경 사항을 적용해야 하는지 확인합니다.
qa/Gemfile에서 activesupport 버전을 업데이트합니다.
qa 폴더에서 bundle update --conservative activesupport를 실행합니다.
vendor/gems/attr_encrypted/attr_encrypted.gemspec에서 activerecord_version 버전을 업데이트합니다.
vendor/gems/attr_encrypted 폴더에서 bundle update --conservative activerecord를 실행합니다.
모든 Bundler 충돌을 해결합니다.
package.json에서 새로운 rails 버전과 일치하는지 @rails/ujs 및 @rails/actioncable npm 패키지를 확인합니다 (package.json).
업데이트 후 로컬 패치 파일 버전이 일치하도록 yarn patch-package @rails/ujs를 실행합니다.
pipeline:run-all-rspec 라벨이 있는 MR을 생성하고 파이프라인이 실패했는지 확인합니다.
git bisect를 사용하여 레일즈 저장소에 대한 해상도 및 디버깅 스펙 실패를 해결합니다. 디버깅 섹션을 참조하세요.
MR 설명에 두 버전 간의 젬 차이에 대한 링크를 포함합니다. 예를 들어, 다음은 activesupport 6.1.3.2에서 6.1.4.1로의 젬 차이입니다.

Gitaly를 위한 MR 준비

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

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

Rails 업그레이드가 패치 릴리스를 통해 이뤄졌고 중요한 보안 수정 사항이 포함된 경우, 자체 관리형 고객에게 해당 패치를 릴리스하는 것이 중요합니다. 진행 방법에 대해 릴리스 매니저와 협의하세요.

폐지 로거

우리는 또한 루비 및 레일즈 폐지 경고를 전용 로그 파일, log/deprecation_json.log에 기록합니다. 이것은 테스트에서 충분히 다루지 않는 코드가 있고 실수로 DeprecationToolkitEnv를 통과할 수 있는 힌트를 제공합니다.

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

Rails에 대한 Git bisect

일반적으로 레일즈 변경이 스펙 실패를 유발했다면, 이것은 추가적인 맥락을 더해주고 실패에 대한 해결책을 찾는 데 도움이 됩니다. 스펙 실패를 유발한 레일즈 변경을 효율적이고 빠르게 찾으려면 git bisect 명령어를 사용할 수 있습니다.

선택한 폴더에 rails 프로젝트를 클론합니다. 예를 들어, GDK 루트 디렉토리일 수 있습니다.
```
cd <GDK_FOLDER>
git clone https://github.com/rails/rails.git
```
GitLab Gemfile의 gem 'rails' 라인을 다음과 같이 변경합니다:
```
gem 'rails', ENV['RAILS_VERSION'], path: ENV['RAILS_FOLDER']
```
RAILS_FOLDER 환경 변수를 복제한 Rails가 있는 폴더로 설정합니다:
```
export RAILS_FOLDER="<GDK_FOLDER>/rails"
```
디렉토리를 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가 됩니다. 이후 git bisect 프로세스가 약간 얼마나 많은 단계가 걸리는지 확인할 수 있습니다.
git bisect 프로세스를 시작하고 scripts/rails-update-bisect에 스펙 파일 이름을 아규먼트로 전달합니다. 전체 스펙 파일 대신 단일 예제만 선택하는 것이 더 빠를 수 있습니다.
```
git bisect run <GDK_FOLDER>/gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb
# 또는
git bisect run <GDK_FOLDER>/gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb:7
```
프로세스가 완료되면, git bisect는 커밋 해시를 출력하는데, 이를 사용하여 rails/rails 저장소에서 해당 MR을 찾을 수 있습니다.
git bisect reset을 실행하여 bisect 모드를 종료합니다.
Gemfile의 변경 사항을 되돌립니다:
```
git checkout -- Gemfile
```