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

경우에 따라, 이전 데이터베이스 마이그레이션 전체에 역효과를 주지 않으면서 기존 헬퍼의 기능을 추가하거나 수정해야 할 때가 있습니다. 이런 이유로 Gitlab::Database::Migration에 버전 관리를 도입했습니다. 이제 각 데이터베이스 마이그레이션은 해당 마이그레이션을 작성하는 시점의 최신 버전을 상속할 수 있습니다. 새 기능을 추가한 이후에도 이전 데이터베이스 마이그레이션은 더 이상 영향을 받지 않습니다. 버전은 보통 Gitlab::Database::Migration[2.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

• 문서의 모든 예시를 새 데이터베이스 마이그레이션 버전인 Gitlab::Database::Migration[2.2]를 참조하도록 업데이트하세요.

• 새 데이터베이스 버전에 대해 오픈 날짜 범위를 추가하여 migration_spec.rb가 새 데이터베이스 마이그레이션에서 실패하지 않는지 확인하세요.

이전 데이터베이스 마이그레이션 버전 사용 방지하기#

일정 시간이 지나고, 모든 개발자가 머지 리퀘스트에서 새 데이터베이스 마이그레이션 버전을 사용하고 있음을 확인한 후, 이전 버전이 사용되지 않도록 방지하세요:

• migration_spec.rb에서 이전 데이터베이스 버전의 날짜 범위를 닫으세요.

• RuboCop::Cop::Migration::VersionedMigrationClass와 해당 테스트를 수정하세요.

• Slack의 #backend 및 #database 채널과 Engineering Week-in-Review document를 통해 이 변경 사항을 공지하세요.