업데이트 간 하위 호환성

GitLab 배포의 구성 요소별 하위 호환성 요구사항과 업데이트 시 발생할 수 있는 호환성 문제를 방지하는 방법을 설명합니다.

GitLab 배포는 여러 구성 요소로 나눌 수 있습니다. GitLab 업데이트는 원자적으로 이루어지지 않습니다. 따라서 많은 구성 요소가 하위 호환성을 유지해야 합니다 . 자주 발생하는 문제 # 어떤 의미에서 이러한 시나리오는 모두 일시적인 상태입니다. 그러나 실제 운영 환경에서는 종종 수 시간 동안 지속될 수 있습니다. 따라서 영구적인 상태와 동일한 주의를 기울여 다루어야 합니다. Sidekiq 워커 수정 시 # 예를 들어 인수를 변경할 때 : 이전 시그니처로 job이 큐에 추가되고 새 월간 릴리즈에서 실행되는 것이 괜찮은가요? 새 시그니처로 job이 큐에 추가되고 이전 월간 릴리즈에서 실행되는 것이 괜찮은가요? 새 Sidekiq 워커 추가 시 # Sidekiq 노드가 아직 업데이트되지 않아 이 job들이 수 시간 동안 실행되지 않는 것이 괜찮은가요? JavaScript/Vue 수정 시 # Rails 코드 변경사항(Rails 컨트롤러, REST API, GraphQL API)이 이전 월간 릴리즈에서 머지되어 릴리즈된 경우, JavaScript는 문제없이 해당 Rails 코드에 요청을 보낼 수 있습니다. Rails 코드 변경사항(Rails 컨트롤러, REST API, GraphQL API)이 아직 릴리즈되지 않은 경우, JavaScript는 해당 Rails 코드에 요청을 보낼 수 있지만 기본적으로 비활성화된 기능 플래그 뒤에 있거나 우아하게 실패할 수 있어야 합니다. 예를 들어 18.3에서 GraphQL 쿼리를 추가하는 경우, 기능 플래그 없이 프론트엔드에서 해당 쿼리를 사용하려면 18.4까지 기다려야 합니다. 기존 쿼리에 GraphQL 필드를 추가할 때는 @gl_introduced 지시어 를 사용하여 우아하게 실패할 수 있습니다. REST API에 필드를 추가할 때는 응답에 새 필드가 없으면 이전 필드로 폴백하여 우아하게 실패할 수 있습니다. 사전 배포 마이그레이션 추가 시 # 사전 배포 마이그레이션이 실행되었지만 웹, Sidekiq, API 노드가 이전 릴리즈를 실행 중인 것이 괜찮은가요? 사후 배포 마이그레이션 추가 시 # 모든 GitLab 노드가 업데이트되었지만 사후 배포 마이그레이션이 며칠 후에야 실행되는 것이 괜찮은가요? 백그라운드 마이그레이션 추가 시 # 모든 노드가 업데이트되고, 며칠 후 사후 배포 마이그레이션이 실행된 다음, 백그라운드 마이그레이션이 완료되는 데 일주일이 걸리는 것이 괜찮은가요? Rails와 같은 의존성 업그레이드 시 # 일부 노드는 새 Rails 버전을 사용하고, 일부 노드는 이전 Rails 버전을 사용하는 것이 괜찮은가요? 업데이트 과정 살펴보기 # 업데이트 중 하위 호환성 문제는 종종 매우 미묘합니다. 따라서 다음 내용을 숙지하는 것이 좋습니다: 업그레이드 지침 레퍼런스 아키텍처 GitLab.com의 아키텍처 GitLab.com의 업그레이드 파이프라인 이러한 문제가 어떻게 발생하는지 설명하기 위해 다음 예시를 살펴보세요: 🚢 새 버전 🙂 이전 버전 이 예시에서는 한 달간의 릴리즈로 업데이트한다고