GitLab에서는 GitLab.com과 같은 대규모 환경에서 개발자가 테이블의 스키마와 데이터를 다룰 수 있도록 데이터베이스 마이그레이션용 헬퍼를 다수 추가했습니다. 각 데이터베이스 마이그레이션마다 헬퍼를 포함시키는 반복 작업을 피하기 위해, 모든 데이터베이스 마이그레이션에 Rails ActiveRecord::Migration 클래스의 서브클래스를 사용합니다. 이 서브클래스가 Gitlab::Database::Migration 이며, 개발자가 사용할 수 있는 모든 헬퍼가 이미 포함돼 있습니다. 자체 제작한 헬퍼의 사용 사례는 마이그레이션 중 다운타임 방지에서 확인할 수 있습니다.

기존 헬퍼의 기능을 추가하거나 수정하면서도 이전 데이터베이스 마이그레이션 전체에 역효과를 주지 않아야 하는 경우가 있습니다. 이를 위해 Gitlab::Database::Migration에 버전 관리를 도입했습니다. 이제 각 데이터베이스 마이그레이션은 작성 시점의 최신 버전 클래스를 상속할 수 있습니다. 새 기능을 추가하더라도 기존 데이터베이스 마이그레이션은 영향을 받지 않습니다. 버전은 보통 Gitlab::Database::Migration[2.1]과 같이 표기하며, 여기서 2.1 이 현재 버전입니다.

목표 지점이 계속 움직이기 때문에 새 마이그레이션을 추가하고 이전 버전을 더 이상 사용하지 않도록 하는 작업은 까다로울 수 있습니다. 데이터베이스 마이그레이션은 매일 추가되며, 이 과정에서 파이프라인이 깨질 수 있습니다. 이 문서에서는 새 데이터베이스 마이그레이션 버전을 추가하는 두 단계 방법을 설명합니다.

1. 새 버전을 도입하고 이전 버전도 계속 허용
2. 이전 데이터베이스 마이그레이션 버전 사용 차단

새 버전을 도입하고 이전 버전도 계속 허용#

1. 새 버전은 migration.rb 클래스에 추가하며, 새 버전에 포함돼야 하는 새 헬퍼도 함께 추가합니다. current_version 이 이 새 버전을 가리키는지 확인합니다. 예를 들면 다음과 같습니다.

         class V2_2 < V2_1 # rubocop:disable Naming/ClassAndModuleCamelCase
           include Gitlab::Database::MigrationHelpers::ANY_NEW_HELPER
         end
   
         def self.current_version
           2.2
         end
   

2. 문서의 모든 예시가 새 데이터베이스 마이그레이션 버전인 Gitlab::Database::Migration[2.2]을 가리키도록 갱신합니다.

3. 새 데이터베이스 버전에 대해 열린 날짜 범위를 추가해 migration_spec.rb가 새 데이터베이스 마이그레이션에서 실패하지 않도록 합니다.

이전 데이터베이스 마이그레이션 버전 사용 차단#

일정 시간이 지나 모든 개발자가 머지 리퀘스트에서 새 데이터베이스 마이그레이션 버전을 사용하고 있음을 확인한 다음, 이전 버전의 사용을 차단합니다.

1. migration_spec.rb에서 이전 데이터베이스 버전의 날짜 범위를 닫습니다.
2. RuboCop::Cop::Migration::VersionedMigrationClass 와 해당 테스트를 수정합니다.
3. 이 변경 사항을 Slack #backend 및 #database 채널과 Engineering Week-in-Review document에 공유합니다.