배포 후 마이그레이션(post deployment migration)은 배포 이후에 선택적으로 실행할 수 있는 일반적인 Rails 마이그레이션입니다. 기본적으로 이 마이그레이션은 다른 마이그레이션과 함께 실행되지만, 이 경우 다운타임이 필요합니다. 이 마이그레이션을 건너뛰려면 rake db:migrate를 실행할 때 환경 변수 SKIP_POST_DEPLOYMENT_MIGRATIONS를 비어 있지 않은 값으로 설정해야 합니다.

예를 들어, 다음 명령은 배포 후 마이그레이션을 포함한 모든 마이그레이션을 실행합니다:

bundle exec rake db:migrate

반면, 다음 명령은 배포 후 마이그레이션을 건너뜁니다:

export SKIP_POST_DEPLOYMENT_MIGRATIONS=true
bundle exec rake db:migrate

GitLab.com의 경우, 이 마이그레이션은 릴리즈 매니저의 재량에 따라 post-deploy migration 파이프라인을 통해 매일 실행됩니다.

배포 통합#

Chef를 사용하여 GitLab의 새 버전을 배포하고, 새 버전을 배포한 후 배포 후 마이그레이션을 실행하려는 경우를 가정해 봅시다. 일반적으로 배포 시 chef-client 명령을 사용한다고 가정하면, 이 기능을 활용하기 위해 다음과 같이 명령을 실행해야 합니다:

export SKIP_POST_DEPLOYMENT_MIGRATIONS=true
sudo chef-client

모든 서버가 업데이트되면, 환경 변수 없이 단일 서버에서 chef-client를 다시 실행할 수 있습니다.

이 과정은 다른 배포 방식에도 유사하게 적용됩니다. 먼저 환경 변수를 설정한 채로 배포하고, 그다음 변수를 해제한 상태로 단일 서버를 재배포합니다.

마이그레이션 생성#

배포 후 마이그레이션을 생성하려면 다음 Rails 제너레이터를 사용할 수 있습니다:

bundle exec rails g post_deployment_migration migration_name_here

이 명령은 db/post_migrate 디렉터리에 마이그레이션 파일을 생성합니다. 이 마이그레이션은 일반적인 Rails 마이그레이션과 완전히 동일하게 동작합니다.

사용 사례#

배포 후 마이그레이션은 기존 버전의 GitLab이 의존하는 상태를 변경하는 마이그레이션을 수행하는 데 사용할 수 있습니다. 예를 들어, 테이블에서 칼럼을 제거하려는 경우를 생각해 보세요. GitLab 인스턴스가 실행 중에 해당 칼럼의 존재에 의존하기 때문에, 이 작업은 다운타임을 필요로 합니다. 일반적으로 이런 경우에는 다음 단계를 따릅니다:

• GitLab 인스턴스 중지

• 칼럼을 제거하는 마이그레이션 실행

• GitLab 인스턴스 재시작

배포 후 마이그레이션을 사용하면 대신 다음 단계를 따를 수 있습니다:

• 배포 후 마이그레이션을 무시하면서 새 버전의 GitLab 배포

• 환경 변수를 설정하지 않은 상태로 rake db:migrate 재실행

여기서는 마이그레이션이 (더 이상 해당 칼럼에 의존하지 않는) 새 버전이 배포된 이후에 실행되므로 다운타임이 필요하지 않습니다.

이 마이그레이션이 유용한 다른 사례들은 다음과 같습니다:

• GitLab의 버그로 인해 생성된 데이터 정리

• 테이블 제거

• Sidekiq 큐 간 job 마이그레이션