여러 지사에 걸친 데이터베이스 구조 관리

토마스 코왈레브스키

앱을 개발한다는 것은 새로운 기능을 구현하거나 패치를 적용하는 것만을 의미하지는 않습니다. 때로는 변경 사항을 되돌리고 프로젝트의 이전 단계로 돌아가야 할 때도 있습니다. 여러 브랜치에서 작업하는 동안 자주 발생할 수 있는 문제는 데이터베이스 구조의 적절한 버전 유지와 관련이 있습니다. 레일을 사용하는 프로그래머는 기성 솔루션을 마음대로 사용할 수 있습니다. 이러한 솔루션은 데이터베이스 변경의 구현 및 제어를 지원하며, 이를 마이그레이션이라고 합니다. 어떻게 작동하고 어떤 가능성을 가져오는지 설명하지 않고 브랜치를 전환하는 동안 데이터베이스 구조의 적절한 버전을 유지하는 문제에 초점을 맞추고 싶습니다.

앱의 데이터베이스 계층은 별도의 존재이며 마이그레이션에 의해서만 제어됩니다. 새 마이그레이션을 생성할 때는 데이터베이스 구조의 계획된 변환을 되돌릴 수 있도록 해야 합니다. 물론 극단적인 경우에는 되돌릴 수 없는 마이그레이션 에서 down 메서드를 호출합니다. 또한 마이그레이션을 되돌릴 수 없다는 사실도 알려줍니다. 마이그레이션에는 테이블, 열 또는 인덱스의 생성, 수정, 제거 등 다양한 유형의 변경이 있습니다. 삭제 및 수정 작업은 변경에 가장 민감합니다. 왜 그럴까요? 다음 시나리오를 고려해 보겠습니다. 기본 작업 경로인 마스터 브랜치로 작업하고 있습니다. 현재 테이블이 하나 있습니다:

클래스 CreateArticles < ActiveRecord::마이그레이션
   def change
     create_table :articles do |t|
       t.문자열 :이름
       t.text :설명
       t.문자열 :상태, null: false
       t.timestamps null: false
     end
   end
 end

우리의 기사 모델에는 다음과 같은 유효성 검사가 필요합니다. 이름, 설명 그리고 상태 속성을 사용합니다.

 클래스 Article < ActiveRecord::Base
   유효성 검사 :이름, 존재: true
   validates :description, presence: true
   validates :status, presence: true
 end

저희는 다음과 같은 변경 사항을 적용하고 있습니다. 기사 테이블에 기능 개발 브랜치를 삭제하고 상태 열입니다.

클래스 RemoveStatusColumnFromArticles < ActiveRecord::마이그레이션
   def change
     remove_column :기사, :상태, :문자열
   end
 end

마이그레이션을 실행합니다:

$ [예제/기능]: 번들 실행 레이크 db:마이그레이트
 == 20150605120955 RemoveStatusColumnFromArticles: 마이그레이션 ===================
 -- remove_column(:articles, :status, :string)
   -> 0.0717s
 == 20150605120955 RemoveStatusColumnFromArticles: 마이그레이션 완료 (0.0718s) ==========

데이터베이스의 스키마가 변경됩니다:

diff --git a/db/schema.rb b/db/schema.rb
index 2a100a9..76438c1 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -11,14 +11,13 @@ #

이 파일을 버전 관리 시스템에서 확인할 것을 강력히 권장합니다.

-ActiveRecord::Schema.define(버전: 20150605120350) do
+ActiveRecord::Schema.define(버전: 20150605120955) do
  createtable "articles", force: :cascade do |t|
    t.string "name"
    t.text "설명"
- t.string "status", null: false t.datetime "createdat", null: false
    t.datetime "updated_at", null: false
  end

end

다음으로, 변경 사항을 기능 브랜치로 전환합니다. 이 문제를 시뮬레이션하기 위해 현재 브랜치를 마스터로 전환합니다. 마이그레이션을 통해 기본 구조가 변경되어 상태 열의 기능 브랜치. 다음 명령을 사용해 보겠습니다:

Article.create!(이름: "카붐", 설명: "로렘 입섬...", 상태: "활성")

위에서 언급된 실행 후 어떤 일이 발생합니까? 코드? 오류입니다: ActiveRecord::UnknownAttributeError: 기사에 대한 알 수 없는 속성 '상태' 가 발생하며 이는 데이터베이스의 호환되지 않는 구조 버전 때문입니다. 브랜치를 마스터로 변경하기 전에 마이그레이션을 롤백해야 합니다. 상태 열에서 기사 테이블.

브랜치를 전환하기 전에 일부 마이그레이션을 롤백해야 하는지 확인하려면 어떻게 해야 하나요? 버전 제어 시스템을 사용하면(여기서는 git) 유용한 별칭을 만들어서 작업을 확인할 수 있습니다:

~/.gitconfig
 [별칭]
  마이그레이션 = "!f() { git diff --name-only $1..$2 db/migrate | tr -d '[A-Za-z/_.]'; }; f"

실행하기 GIT 마이그레이션 마스터 기능 명령을 실행하면 마이그레이션 버전 목록이 표시됩니다. 기능 브랜치에서 찾을 수 없으며 마스터.

$ [예제/기능]: git 마이그레이션 마스터 기능
 20150605120955

이 정보 덕분에 마스터로 전환하기 전에 데이터베이스 구조에서 수행한 변경 사항을 쉽게 롤백할 수 있습니다.

 $ [예제/기능]: 번들 실행 레이크 db:마이그레이트:다운 VERSION=20150605120955
 == 20150605120955 RemoveStatusColumnFromArticles: reverting ===================
 -- add_column(:articles, :status, :string)
   -> 0.0009s
 == 20150605120955 RemoveStatusColumnFromArticles: 되돌림 (0.0045s) ==========

마이그레이션을 롤백한 후 한 가지 더 해야 할 일은 데이터베이스 스키마의 상태를 복원하는 것입니다.

$ [예제/기능]: git 상태
브랜치 기능
커밋을 위해 스테이징되지 않은 변경 사항:
 (커밋할 내용을 업데이트하려면 "git add ..."를 사용한다).
 (작업 디렉터리에서 변경 내용을 삭제하려면 "git 체크아웃 -- ..." 사용)

수정: db/schema.rb

커밋에 추가한 변경 사항 없음("git add" 및/또는 "git commit -a" 사용)
$ [예제/기능]: git 체크아웃 db/schema.rb
$ [예제/기능]: git 상태
브랜치 기능
커밋할 내용 없음, 작업 디렉터리 정리

이제 우리는 쉽게 마스터 브랜치.

주어진 예제는 풀기 어려운 복잡한 문제는 아니지만, 업무 환경이 바뀌는 동안 데이터베이스의 구조를 유지하는 것이 얼마나 중요한지 깨닫는 데 도움이 될 것입니다.