Rails 업그레이드 가이드라인

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

Rails 업그레이드 접근법

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

GitLab에 MR 준비하기

Ruby on Rails 업그레이드 가이드를 확인하고 애플리케이션을 다가오는 변경 사항에 준비합니다.
Gemfile에서 rails gem 버전을 업데이트합니다.
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 충돌을 해결합니다.
@rails/ujs 및 @rails/actioncable npm 패키지가 package.json에서 새로운 rails 버전과 일치하는지 확인합니다.
이를 업데이트한 후 yarn patch-package @rails/ujs를 실행하여 로컬 패치 파일 버전이 일치하는지 확인합니다.
pipeline:run-all-rspec 레이블을 가진 MR을 생성하고 파이프라인이 깨지는지 확인합니다.
사양 실패를 해결하고 디버그하기 위해 git bisect를 rails 저장소에 대해 사용합니다. 아래 디버깅 섹션를 참조하세요.
두 버전 간의 Gem 차이 링크를 병합 요청 설명에 포함합니다. 예를 들어, activesupport 6.1.3.2에서 6.1.4.1로의 차이가 있습니다.

Gitaly에 MR 준비하기

더 이상 필요하지 않습니다. Gitaly에는 Ruby 코드가 없기 때문입니다.

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

Rails 업그레이드가 패치 릴리스를 넘어 중요 보안 수정을 포함하는 경우,
자체 관리 고객에게 GitLab 패치 릴리스로 이를 릴리스해야 합니다. 진행 방법에 대해 릴리스 관리자와 상담하십시오.

폐기 로그

우리는 Ruby 및 Rails의 폐기 경고를 전용 로그 파일인 log/deprecation_json.log에 기록합니다. 이는
테스트로 충분히 커버되지 않은 코드가 DeprecationToolkitEnv를 지나칠 수 있을 때 단서를 제공합니다.

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

Rails에 대한 Git bisect

일반적으로, 어떤 Rails 변경이 사양 실패를 유발했는지 알고 있다면, 추가적인 맥락을 제공하며
실패에 대한 수정을 찾는 데 도움이 됩니다.

효율적이고 빠르게 어떤 Rails 변경이 사양 실패를 유발했는지 찾으려면,
Rails 저장소에 대해 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를 복제한 폴더로 RAILS_FOLDER 환경 변수 설정:
```
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입니다.
<NEW_VERSION_TAG>를 빨간색 사양이 있는 태그로, <OLD_VERSION_TAG>를 녹색 사양이 있는 태그로 교체하십시오.
출력에서 커밋을 찾기 위해 대략적으로 몇 단계가 필요한지 확인할 수 있습니다.
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
```