마이그레이션 스타일 가이드

마이그레이션 스타일 가이드 관련 내용을 설명합니다.

마이그레이션 스타일 가이드 # GitLab의 마이그레이션을 작성할 때는 수십만 개의 크고 작은 조직이 이를 실행하며, 일부는 데이터베이스에 수년간의 데이터를 보유하고 있다는 점을 고려해야 합니다. 또한 규모에 관계없이 업그레이드를 위해 서버를 오프라인으로 전환해야 하는 상황은 대부분의 조직에게 큰 부담입니다. 따라서 마이그레이션을 신중하게 작성하고, 온라인 상태에서 적용 가능하며, 아래의 스타일 가이드를 준수하는 것이 중요합니다. 마이그레이션은 GitLab 설치를 절대 오프라인으로 전환하도록 요구해서는 안 됩니다. 마이그레이션은 항상 다운타임을 피하는 방식으로 작성되어야 합니다. 과거에는 DOWNTIME 상수를 설정하여 다운타임을 허용하는 마이그레이션을 정의하는 프로세스가 있었습니다. 오래된 마이그레이션을 살펴보면 이를 확인할 수 있습니다. 이 프로세스는 4년 동안 유지되었지만 실제로 사용된 적은 없으며, 이를 통해 다운타임을 피하기 위해 마이그레이션을 항상 다르게 작성하는 방법을 찾아낼 수 있다는 것을 배웠습니다. 마이그레이션을 작성할 때는 데이터베이스에 오래된 데이터나 불일치가 있을 수 있다는 점도 고려하고 이를 방어적으로 처리하세요. 데이터베이스 상태에 대해 가능한 한 가정을 적게 세우도록 노력하세요. 미래 버전에서 변경될 수 있으므로 GitLab 특정 코드에 의존하지 마세요. 필요한 경우 GitLab 코드를 마이그레이션에 복사하여 앞으로도 호환 가능하게 만드세요. 적절한 마이그레이션 유형 선택 # 새 마이그레이션을 추가하기 전 첫 번째 단계는 가장 적합한 유형을 결정하는 것입니다. 현재 수행해야 하는 작업의 종류와 완료까지 걸리는 시간에 따라 세 가지 종류의 마이그레이션을 만들 수 있습니다: 일반 스키마 마이그레이션. 이는 새 애플리케이션 코드가 배포되기 이전 에 실행되는 db/migrate 의 전통적인 Rails 마이그레이션입니다 (GitLab.com의 경우 Canary가 배포되기 전). 즉, 배포를 불필요하게 지연시키지 않도록 몇 분 이내로 비교적 빠르게 실행되어야 합니다. 예외적으로 시간이 더 걸리지만 애플리케이션이 올바르게 동작하는 데 절대적으로 중요한 마이그레이션이 있을 수 있습니다. 예를 들어 고유한 튜플을 강제하는 인덱스나 애플리케이션의 중요한 부분에서 쿼리 성능에 필요한 인덱스가 있을 수 있습니다. 그러나 마이그레이션이 허용할 수 없을 정도로 느린 경우, 피처 플래그 로 기능을 보호하고 대신 배포 후 마이그레이션을 수행하는 것이 더 나은 방법일 수 있습니다. 마이그레이션이 완료된 후 기능을 활성화하면 됩니다. 새 모델을 추가하는 마이그레이션도 이 일반 스키마 마이그레이션의 일부입니다. 차이점은 마이그레이션 생성에 사용하는 Rails 명령어와 추가로 생성되는 파일(모델용 파일 하나, 모델의 스펙 파일 하나)뿐입니다. 배포 후 마이그레이션. 이는 db/post_migrate 의 Rails 마이그레이션으로, GitLab.com 배포와 독립적으로 실행됩니다. 대기 중인 배포 후 마이그레이션은 배포 후 마이그레이션 파이프라인