업데이트 간 하위 호환성

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의 업그레이드 파이프라인 이러한 문제가 어떻게 발생하는지는 다음 예시에서 확인할 수 있습니다. 🚢