db:migrate:multi-version-upgrade 작업
- GitLab 16.11에서 소개되었습니다.
이 작업은 병합 요청 파이프라인의 테스트 단계에서 실행됩니다. 가장 최근의 필수 업그레이드 중단점으로부터 작성자의 작업 브랜치로의 다중 버전 업그레이드에 대한 마이그레이션이 통과하는지를 확인합니다. 이는 최신 알려진 GitLab 버전 중단점에서의 테스트 데이터와 함께 생성된 PostgreSQL 덤프를 사용하여 gitlab:db:configure
을 실행하여 달성됩니다.
데이터베이스 덤프는 PostgreSQL 덤프 생성기를 통해 생성되고 유지됩니다. 데이터베이스에 데이터를 시드하기 위해 이 도구는 bulk_data.rb
구성을 사용하여 모든 팩토리를 시드하고 모든 db/fixtures
를 시드하기 위해 db:seed_fu
을 사용합니다. 최신 덤프는 필수 중단점의 최신 패치 릴리스에 대한 예약된 파이프라인에서 자동으로 생성됩니다.
문제 해결
데이터베이스 다시 구성 실패
이 실패는 일반적으로 작업 브랜치에서 실제 마이그레이션 오류로 인해 발생합니다. 로컬에서 실패를 재현하려면 마이그레이션 업그레이드 테스트 안내를 따르세요. 이 안내는 최신 PostgreSQL 덤프를 로컬 GitLab 개발 키트 또는 GitLab 도커 인스턴스에 가져오는 단계를 설명합니다.
실제 예제는 이 실패한 작업을 참조하세요.
손상된 마스터
새로운 필수 업그레이드 중단점이 추가되면(매 세 또는 네 마일스톤마다), 새 PostgreSQL 덤프의 빌드가 트리거됩니다. 경우에 따라서 새로운 추가 테이블이 시드되면 master
파이프라인에서 db:migrate:multi-version-upgrade
작업이 실패할 수 있습니다. 예를 들어, 새로운 추가 테이블로 인해 오래된 덤프에서 놓친 마이그레이션 오류를 감지하는 데 도움이 됩니다.
손상된 마스터 경우의 작업 흐름:
- 오류를 발생시킨 마이그레이션을 찾아 루트 원인 MR을 식별하세요. 예를 들어, 실패한 작업에서’Security Policy Management Project ID를 Security Policies에 추가하는 마이그레이션’을 검색하여 필요한 경우 로컬에서 디버깅하세요.
- 필요한 경우, 데이터베이스 다시 구성 실패에 설명된 대로 로컬 디버깅을 수행하세요.
- 해당 마이그레이션을 도입한 관련 팀에 연락하여 MR을 되돌려야 하는지 또는 수정이 진행될지에 대해 논의하세요.
- 팀에 연락할 수 없는 경우,
#database
슬랙 채널에 게시하세요.
- 팀에 연락할 수 없는 경우,
- 수정 또는 되돌리기가 진행 중일 때,
master
파이프라인을 일시적으로 사용하지 않도록DISABLE_DB_MULTI_VERSION_UPGRADE=true
을 CI/CD 설정 페이지에서 설정하여 차단할 수 있습니다.- 작업을 사용하지 않도록 설정할 때,
#master-broken
슬랙 채널에 알려주세요.
- 작업을 사용하지 않도록 설정할 때,
- 작업 안정성 추적 이슈#458402에 참고를 추가하세요.
- CI/CD 설정에서
DISABLE_DB_MULTI_VERSION_UPGRADE
를 제거하여 작업을 다시 활성화하세요.
데이터베이스 가져오기 실패
gitlab:db:configure
이전에 설정 단계에서 작업이 실패하는 경우, 외부 종속성으로 인해 실패할 수 있으며, 손상된 마스터를 차단하기 위해 GitLab 프로젝트 CI 변수에서 DISABLE_DB_MULTI_VERSION_UPGRADE=true
로 설정하여 작업을 차단할 수 있습니다.
Self-Managed Platform 팀에 문의하여 디버깅을 가속화하세요.