개발, 테스트 및 프로덕션에서 데이터베이스를 어떻게 관리합니까?

개발, 테스트 및 프로덕션에서 데이터베이스를 어떻게 관리합니까?

---

개발, 테스트 및 프로덕션 서버간에 데이터베이스 스키마 및 데이터를 관리하는 방법에 대한 좋은 예를 찾으려고 고생했습니다.

설정은 다음과 같습니다. 각 개발자에게는 앱과 MySQL 데이터베이스를 실행하는 가상 머신이 있습니다. 그들이 원하는 것을하는 것은 그들의 개인 샌드 박스입니다. 현재 개발자는 SQL 스키마를 변경하고 SVN에 커밋 한 텍스트 파일로 데이터베이스를 덤프합니다.

항상 최신 커밋 된 코드를 실행하는 지속적인 통합 개발 서버를 구축하려고합니다. 지금 그렇게하면 각 빌드마다 SVN에서 데이터베이스를 다시로드합니다.

"릴리스 후보"를 실행하는 테스트 (가상) 서버가 있습니다. 테스트 서버에 배포하는 것은 현재 매우 수동적 인 프로세스이며 일반적으로 SVN에서 최신 SQL을로드하고 조정해야합니다. 또한 테스트 서버의 데이터가 일치하지 않습니다. 마지막 개발자가 샌드 박스 서버에서 수행 한 테스트 데이터는 무엇이든 가능합니다.

모든 것이 고장 나는 곳은 프로덕션 환경에 대한 배포입니다. 라이브 데이터를 테스트 데이터로 덮어 쓸 수 없으므로 모든 스키마 변경 사항을 수동으로 다시 작성해야합니다. 데이터를 조작하기 위해 많은 스키마 변경 또는 변환 스크립트가있는 경우에는 실제로 문제가 발생할 수 있습니다.

문제가 스키마 일 뿐이라면 문제가 더 쉬울 수 있지만 보안 및 권한 테이블의 메타 데이터와 같이 개발 중에 업데이트되는 데이터베이스에 "기본"데이터가 있습니다.

이것이 지속적인 통합과 1 단계 빌드로 나아가는 데있어 가장 큰 장벽입니다. 어떻게 당신은 그것을 해결?

---

후속 질문 : 데이터베이스 버전을 추적하여 주어진 데이터베이스 인스턴스를 업그레이드하기 위해 실행할 스크립트를 어떻게 알 수 있습니까? Lance와 같은 버전 표가 표준 절차 아래에 언급되어 있습니까?

---

Tarantino를 참조 해 주셔서 감사합니다. .NET 환경에 없지만 DataBaseChangeMangement 위키 페이지 가 매우 유용 하다는 것을 알았습니다 . 특히이 파워 포인트 프레젠테이션 (.ppt)

*.sql주어진 디렉토리 의 스크립트 이름을 데이터베이스의 테이블과 비교하여 확인하고 파일 이름의 첫 번째 부분을 구성하는 정수를 기준으로 순서가없는 스크립트를 실행하는 Python 스크립트를 작성합니다 . 그것이 매우 의심스러운 솔루션이라면, 여기에 게시 할 것입니다.

---

이에 대한 작업 스크립트가 있습니다. 존재하지 않는 경우 DB 초기화 및 필요에 따라 업그레이드 스크립트 실행을 처리합니다. 기존 데이터베이스를 지우고 파일에서 테스트 데이터를 가져 오는 스위치도 있습니다. 약 200 줄이므로 게시하지 않을 것입니다 (관심이 있다면 pastebin에 넣을 수도 있습니다).

---

몇 가지 좋은 옵션이 있습니다. "백업 복원"전략을 사용하지 않습니다.

1. 모든 스키마 변경 사항을 스크립팅하고 CI 서버가 해당 스크립트를 데이터베이스에서 실행하도록합니다. 현재 데이터베이스 버전을 추적 할 버전 테이블을 보유하고 최신 버전 인 경우에만 스크립트를 실행하십시오.

2. 마이그레이션 솔루션을 사용하십시오. 이러한 솔루션은 언어마다 다르지만 .NET의 경우 Migrator.NET을 사용합니다. 이를 통해 데이터베이스 버전을 정하고 버전 간 위아래로 이동할 수 있습니다. 스키마는 C # 코드로 지정됩니다.

---

개발자는 단순히 전체 데이터베이스를 소스 제어로 덤프하는 것이 아니라 작업하는 각 버그 / 기능에 대한 변경 스크립트 (스키마 및 데이터 변경)를 작성해야합니다. 이 스크립트는 현재 프로덕션 데이터베이스를 개발중인 새 버전으로 업그레이드합니다.

빌드 프로세스는 프로덕션 데이터베이스의 사본을 적절한 환경으로 복원하고 소스 제어에서 모든 스크립트를 실행하여 데이터베이스를 현재 버전으로 업데이트합니다. 모든 스크립트가 올바르게 실행되도록 매일 수행합니다.

---

Ruby on Rails가 어떻게 하는지를 살펴보십시오.

먼저 기본적으로 데이터베이스 스키마와 데이터를 버전 N에서 버전 N + 1로 (또는 버전 N + 1에서 N으로 다운 그레이드하는 경우) 변환하는 마이그레이션 파일이 있습니다. 데이터베이스에는 현재 버전을 알려주는 테이블이 있습니다.

테스트 데이터베이스는 단위 테스트 전에 항상 깨끗하게 정리되고 파일의 고정 데이터로 채워집니다.

---

Refactoring Databases : Evolutionary Database Design 책 은 데이터베이스 관리 방법에 대한 아이디어를 제공 할 수 있습니다. 짧은 버전은 http://martinfowler.com/articles/evodb.html 에서도 읽을 수 있습니다 .

하나의 PHP + MySQL 프로젝트에서 데이터베이스에 데이터베이스 개정 번호가 저장되어 있으며 프로그램이 데이터베이스에 연결되면 먼저 개정을 확인합니다. 프로그램에 다른 개정이 필요한 경우 데이터베이스 업그레이드를위한 페이지가 열립니다. 각 업그레이드는 PHP 코드로 지정되며 데이터베이스 스키마를 변경하고 모든 기존 데이터를 마이그레이션합니다.

---

• 데이터베이스 이름을 다음과 같이 지정하십시오.- dev_<<db>> , tst_<<db>> , stg_<<db>> , prd_<<db>>DB 이름을 하드 코딩해서는 안됩니다
• 따라서 동일한 물리적 서버에 다른 유형의 db조차도 배포 할 수 있습니다 (권장하지 않지만 리소스가 부족한 경우 ...
• 자동으로 데이터를 이동할 수 있는지 확인하십시오
• DB 작성 스크립트를 채우기와 분리 = 항상 DB를 처음부터 다시 작성하고 이전 DB 버전 또는 외부 데이터 소스에서 채우는 것이 가능해야합니다.
• 코드에 하드 코드 연결 문자열을 사용하지 마십시오 (구성 파일에는 없음)-구성 파일 연결 문자열 템플릿에 사용하십시오. 동적으로 채울 때 다시 컴파일 해야하는 application_layer의 각 재구성은 BAD입니다.
• 데이터베이스 버전 관리 및 db 객체 버전 관리를 사용하십시오. 자신이 무언가를 개발하지 않은 경우 준비된 제품을 사용할 수 있다면
• 각 DDL 변화를 추적하고 (일부 역사 테이블에 저장 여기 예 )
• 매일 백업! 백업에서 손실 된 항목을 얼마나 빨리 복원 할 수 있는지 테스트합니다 (자동 저장 스크립트 사용)
• DEV 데이터베이스와 PROD조차도 데이터와 관련하여 문제가 발생하는 것과 동일한 생성 스크립트를 가지고 있으므로 개발자가 정확한 제품 사본을 만들어서 재생할 수 있습니다 (나는 이것에 대한 마이너스를받을 것이지만 똥이 팬을 때리면 사고 방식과 비즈니스 프로세스 비용이 훨씬 저렴합니다. 따라서 코더가 합법적으로 원하는 것을 첨자로 만들도록하십시오.

---

이것은 내가 끊임없이 불만족스러운 것입니다-이 문제에 대한 우리의 해결책입니다. 몇 년 동안 우리는 각 릴리스마다 별도의 변경 스크립트를 유지했습니다. 이 스크립트에는 마지막 프로덕션 릴리스의 델타가 포함됩니다. 응용 프로그램이 릴리스 될 때마다 버전 번호가 증가하여 다음과 같은 결과가 나타납니다.

• dbChanges_1.sql
• dbChanges_2.sql
• ...
• dbChanges_n.sql

새로운 개발을위한 트렁크 / 메인 라인과 버그 수정, 단기 개선 등을위한 두 가지 개발 라인을 유지하기 시작할 때까지 이것은 잘 작동했습니다. 필연적으로 지점의 스키마를 변경해야 할 필요성이 생겨났습니다. 이 시점에서 이미 트렁크에 dbChanges_n + 1.sql이 있었으므로 다음과 같은 구성표를 사용하게되었습니다.

• dbChanges_n.1.sql
• dbChanges_n.2.sql
• ...
• dbChanges_n.3.sql

Again, this worked well enough, until we one day we looked up and saw 42 delta scripts in the mainline and 10 in the branch. ARGH!

These days we simply maintain one delta script and let SVN version it - i.e. we overwrite the script with each release. And we shy away from making schema changes in branches.

So, I'm not satisfied with this either. I really like the concept of migrations from Rails. I've become quite fascinated with LiquiBase. It supports the concept of incremental database refactorings. It's worth a look and I'll be looking at it in detail soon. Anybody have experience with it? I'd be very curious to hear about your results.

---

You could also look at using a tool like SQL Compare to script the difference between various versions of a database, allowing you to quickly migrate between versions

---

We have a very similar setup to the OP.

Developers develop in VM's with private DB's.

[Developers will soon be committing into private branches]

Testing is run on different machines ( actually in in VM's hosted on a server) [Will soon be run by Hudson CI server]

Test by loading the reference dump into the db. Apply the developers schema patches then apply the developers data patches

Then run unit and system tests.

Production is deployed to customers as installers.

What we do:

We take a schema dump of our sandbox DB. Then a sql data dump. We diff that to the previous baseline. that pair of deltas is to upgrade n-1 to n.

we configure the dumps and deltas.

So to install version N CLEAN we run the dump into an empty db. To patch, apply the intervening patches.

( Juha mentioned Rail's idea of having a table recording the current DB version is a good one and should make installing updates less fraught. )

Deltas and dumps have to be reviewed before beta test. I can't see any way around this as I've seen developers insert test accounts into the DB for themselves.

---

I'm afraid I'm in agreement with other posters. Developers need to script their changes.

In many cases a simple ALTER TABLE won't work, you need to modify existing data too - developers need to thing about what migrations are required and make sure they're scripted correctly (of course you need to test this carefully at some point in the release cycle).

Moreover, if you have any sense, you'll get your developers to script rollbacks for their changes as well so they can be reverted if need be. This should be tested as well, to ensure that their rollback not only executes without error, but leaves the DB in the same state as it was in previously (this is not always possible or desirable, but is a good rule most of the time).

How you hook that into a CI server, I don't know. Perhaps your CI server needs to have a known build snapshot on, which it reverts to each night and then applies all the changes since then. That's probably best, otherwise a broken migration script will break not just that night's build, but all subsequent ones.

---

Check out the dbdeploy, there are Java and .net tools already available, you could follow their standards for the SQL file layouts and schema version table and write your python version.

---

We are using command-line mysql-diff: it outputs a difference between two database schemas (from live DB or script) as ALTER script. mysql-diff is executed at application start, and if schema changed, it reports to developer. So developers do not need to write ALTERs manually, schema updates happen semi-automatically.

---

If you are in the .NET environment then the solution is Tarantino. It handles all of this (including which sql scripts to install) in a NANT build.

---

I've written a tool which (by hooking into Open DBDiff) compares database schemas, and will suggest migration scripts to you. If you make a change that deletes or modifies data, it will throw an error, but provide a suggestion for the script (e.g. when a column in missing in the new schema, it will check if the column has been renamed and create xx - generated script.sql.suggestion containing a rename statement).

http://code.google.com/p/migrationscriptgenerator/ SQL Server only I'm afraid :( It's also pretty alpha, but it is VERY low friction (particularly if you combine it with Tarantino or http://code.google.com/p/simplescriptrunner/)

The way I use it is to have a SQL scripts project in your .sln. You also have a db_next database locally which you make your changes to (using Management Studio or NHibernate Schema Export or LinqToSql CreateDatabase or something). Then you execute migrationscriptgenerator with the _dev and _next DBs, which creates. the SQL update scripts for migrating across.

---

For oracle database we use oracle-ddl2svn tools.

This tool automated next process

1. for every db scheme get scheme ddls
2. put it under version contol

changes between instances resolved manually

참고URL : https://stackoverflow.com/questions/6371/how-do-you-manage-databases-in-development-test-and-production