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

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

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