Rails 업그레이드 지침
우리는 최신 Rails 릴리스를 사용하여 GitLab을 실행하여 성능, 보안 업데이트 및 새로운 기능을 활용하고자 노력하고 있습니다.
Rails 업그레이드 접근 방식
GitLab을 위한 MR 준비
- Ruby on Rails 업그레이드 가이드를 확인하고 애플리케이션을 다가오는 변경 사항에 대비시킵니다.
-
Gemfile
에서rails
젬 버전을 업데이트합니다. -
bundle update rails
를 실행합니다. - 업데이트 작업인
rake rails:update
를 실행합니다. -
qa/Gemfile
에서activesupport
버전을 업데이트합니다. -
qa
폴더에서bundle update --conservative activesupport
를 실행합니다. - Bundler 충돌을 해결합니다.
-
@rails/ujs
및@rails/actioncable
npm 패키지가package.json
에서 새로운 rails 버전과 일치하는지 확인합니다. - 업데이트 후 로컬 패치 파일 버전이 일치하도록
yarn patch-package @rails/ujs
를 실행합니다. -
pipeline:run-all-rspec
라벨이 있는 MR을 만들고 파이프라인이 실패하는지 확인합니다. -
git bisect
를 사용하여 rails 리포지터리에 대한 특이점을 해결하고 디버깅합니다. 아래의 디버깅 섹션을 참조하세요. - 두 버전 간의 젬 차이에 대한 링크를 Merge Request 설명에 포함합니다. 예를 들어,
activesupport
6.1.3.2에서 6.1.4.1로의 젬 차이입니다.
Gitaly를 위한 MR 준비
-
Gitaly Ruby의 Gemfile에서
activesupport
젬 버전을 업데이트합니다. -
bundle update --conservative activesupport
를 실행합니다. - Gitaly 프로젝트에 대한 MR을 이러한 변경 사항과 함께 만듭니다.
- 이 MR을 GitLab 프로젝트에서 만든 MR에 의존성을 둡니다.
- GitLab 프로젝트의 MR을 Merge한 이후에만 해당 MR을 Merge합니다.
보안 패치용 패치 릴리스 및 백포트 작성
만약 Rails 업그레이드가 패치 릴리스를 거쳐 중요한 보안 수정 사항을 포함한다면, 해당 내용은 Self-Managed형 고객에게 릴리스되어야 합니다. 진행 방법에 대해 릴리스 매니저와 협의하세요.
사용중지 로거
우리는 Ruby 및 Rails 사용중지 경고를 log/deprecation_json.log
파일에 로깅합니다. 이것은 테스트에서 충분히 커버되지 않은 코드가 있을 때 징후를 제공하며, 이때 DeprecationToolkitEnv
를 우회하게 됩니다.
GitLab SaaS의 경우, GitLab 팀원은 Kibana(https://log.gprd.gitlab.net/goto/f7cebf1ff05038d901ba2c45925c7e01
)에서 이러한 로그 이벤트를 검토할 수 있습니다.
Rails에 대한 Git bisect
일반적으로, 어떤 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_FOLDER
환경 변수를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
로 대체합니다. 출력에서 어느 정도의 스텝이 걸리는지 확인할 수 있습니다. -
git bisect
프로세스를 시작하고scripts/rails-update-bisect
에 스펙 파일 이름을 인수로 전달합니다. 전체 스펙 파일 대신 하나의 예시만 선택하는 것이 빠를 수 있습니다.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
- 프로세스가 완료되면
git bisect
는 커밋 해시를 출력하여 해당 커밋에 대응하는 해당 MR을 찾을 수 있습니다. -
git bisect reset
를 실행하여bisect
모드를 종료합니다. -
Gemfile
의 변경 사항을 되돌립니다:git checkout -- Gemfile