Ruby 업그레이드 가이드라인

GitLab에서 Ruby 버전을 업그레이드할 때 고려해야 할 범위, 영향 대상, 접근 방식 및 권장 사항을 설명합니다.

성능 및 보안 업데이트와 새로운 Ruby API의 혜택을 누리기 위해 GitLab은 최신 Ruby MRI 릴리즈를 사용하는 것을 목표로 합니다. GitLab 전체에서 Ruby를 업그레이드할 때는 다음 조건을 만족하는 방식으로 진행해야 합니다: 기여자들에게 최소한의 혼란을 야기해야 합니다. GitLab.com 가용성을 최적화해야 합니다. GitLab의 모든 부분에서 Ruby 버전 일관성을 유지해야 합니다. Ruby 버전 변경을 시작하기 전에 이 문서를 주의 깊게 처음부터 끝까지 읽어 어떤 변경이 필요할 수 있는지 전반적인 이해를 얻으세요. Ruby 업그레이드는 이전 업그레이드와 조금씩 다를 수 있으므로, 문서화된 단계의 순서와 필요성을 각 상황에 맞게 평가하세요. Ruby 업그레이드 범위 # Ruby를 업그레이드할 때 가장 먼저 고려해야 할 것은 범위입니다. 일반적으로 Ruby 업데이트가 발생해야 할 수 있는 다음 영역을 고려합니다: 메인 GitLab Rails 리포지터리. 보조 Ruby 시스템 리포지터리. 이러한 리포지터리의 시스템에서 사용하는 서드파티 라이브러리. 이러한 리포지터리의 시스템에서 사용하는 GitLab 라이브러리. 항상 이 모두를 다룰 필요는 없습니다. 예를 들어, 패치 수준 Ruby 업데이트는 서드파티 gem 업데이트가 필요하지 않을 수 있습니다. 패치, 마이너, 메이저 업그레이드 # 범위를 평가할 때 Ruby 버전 수준이 중요합니다. 예를 들어, 패치 릴리즈는 일반적으로 보안 또는 버그 수정으로 제한되므로, GitLab을 Ruby 2.7.2에서 2.7.4로 업그레이드하는 것보다 Ruby 2.x에서 3.x로 업그레이드하는 것이 더 어렵고 위험합니다. 업그레이드를 준비할 때 이 점을 인지하고 그에 따라 계획을 세우세요. 향후 업그레이드의 범위를 예측하는 데 도움이 되도록 다음 업그레이드에 필요한 노력을 참고하세요: 패치 업그레이드 2.7.2 -> 2.7.4 마이너 업그레이드 2.6.x -> 2.7.x 메이저 업그레이드 2.x.x -> 3.x.x 영향을 받는 대상 및 타깃 # 업그레이드 전에 Ruby 업그레이드의 영향을 즉각적으로 받는 순서에 따라 모든 대상과 타깃을 고려하세요: 개발자. 회사 내외부에 GitLab 및 관련 프로젝트의 많은 기여자가 있습니다. .ruby-version 과 같은 파일을 변경하면 이러한 파일을 해석하는 도구를 사용하는 모든 사람에게 영향을 줍니다. 개발자는 병합된 변경 사항이 포함된 리포지터리를 pull하는 즉시 영향을 받습니다. GitLab CI/CD. 코드 통합 및 테스트에 CI/CD를 많이 활용합니다. CI/CD job은 .ruby-version 과 같은 파일을 해석하지 않습니다. 대신 .gitlab-ci.yml 에 정의된 Docker 컨테이너에 설치된 Ruby를 사용합니다. 이 job에서 사용하는 컨테이너 이미지는 gitlab-build-images 리포지터리에서 관리됩니다. 이미지 업데이트를 병합하면 이미지가 빌드 되는 즉시 CI/CD job에 영향이 미칩니다. GitLab.com . G