소규모 웹 팀을위한 로컬 데이터베이스 개발 프로세스를 설정하는 방법은 무엇입니까?

배경

저는 약 4 명의 프로그래머와 4 명의 디자이너로 구성된 소규모 웹 팀을위한 새로운 개발 프로세스를 만들고 있으며 앞으로 팀을 성장시킬 수있는 잠재력이 있습니다. 우리의 제품은 우리가 디자인하고 호스팅하는 클라이언트 웹 사이트를 강화하는 중앙 응용 프로그램입니다.

이전에는 단일 dev 데이터베이스가있는 dev 서버에서 FTP를 통해 모두 작업했습니다. 그것은 "일" ^* 잠시 동안 만 우리의 과정을 성숙하는 시간이 그래서 우리는 새로운 방향으로 이동하고있다.

우리는 Percona Server 5.5를 사용하지만 이는 비용을 낮게 유지한다는 아이디어와 함께 데이터베이스에 구애받지 않아야합니다.

목표 :

다음을 염두에두고 데이터베이스 개발을위한 CI (Continuous Integration) 프로세스를 작성하려고합니다.

1. 개발자는 개발 코드를 실행할 로컬 데이터 사본을 보유하고 있습니다.
2. 데이터베이스 구조를 이전 변경 세트로 롤백 가능
3. 새로운 기능 스키마 변경과 스키마 디자인 수정 변경을 분리 할 수 ​​있음
4. 테스트를 위해 데이터베이스 구조를 로컬로 수정할 수 있습니다

초기 개념

SVN과 LiquiBase를 사용하여 아래 프로세스를 스케치했지만 완전히 제거했습니다 #4.

• 트렁크에서 '개발'분기를 만듭니다
• 중앙 '개발'DB 서버가 '개발'분기에서 실행
• 지역 개발자는 개발 지점의 노예로 설정됩니다 ( #1위에서 제공 )
• liquibase 변경 세트는 개발 브랜치에 정기적으로 커밋되어 중앙 커밋 데이터베이스를 업데이트하기 위해 커밋 후 후크를 실행합니다 (이 개발 서버의 슬레이브로 실행되는 로컬 시스템으로 이동 #2).
• 기능 또는 스키마 수정 사항이 QA로 이동할 준비가되면 DBA (me)는 개발 브랜치에서 트렁크로 적절한 변경 사항을 병합합니다. 이 조치는 스테이징 데이터베이스 서버에 적용 할 SQL 스크립트를 작성합니다.
• 스테이징 서버는 프로덕션과 동일한 구조 및 QA의 변경 사항을 가져야하는 TRUNK를 반영해야합니다.
• 스테이징 서버에서 sql 스크립트를 실행 한 후 변경 사항에 대해 QA를 수행하십시오.
• 모든 것이 좋아 보인다면 구조를 태그하십시오. 그러면 DBA가 수동으로 프로덕션에서 실행할 .sql 스크립트가 생성됩니다 (필요한 경우 사용량이 적은 시간 동안).

이 프로세스를 수행하려면 모든 개발자가 동일한 '개발'분기를 실행해야합니다. 즉, 주어진 시간에 데이터베이스 스키마 버전이 하나만 있어야합니다 (필자는 확실하지 않습니다).

또한 스키마에 대한 변경 사항은 로컬에서 테스트 할 수 없으며 올바르게 수행하지 않으면 다른 개발자에게 영향을 줄 수 있습니다. 우리 환경에서 개발자는 새 테이블을 추가 할 수 있지만 기존 구조는 거의 수정하지 않을 수 있습니다. DBA로서 디자인 수정은 저에 의해 이루어집니다. 그러나 로컬에서 수정 프로그램을 테스트 할 수없는 것은 프로세스의 가장 큰 중단입니다.

위의 프로세스를 어떻게 조정하여 로컬 개발을 허용하면서 상대적으로 최신 데이터 사본을 유지하면서 (제안 된 프로세스에서 복제에 의해 제공됨)? 지난 주까지도 최신 데이터가 필요하지 않습니다.

환경 관리

단일 데이터베이스 버전으로 강요하고 싶지 않다고 생각합니다. 여러 개발 작업 스트림을 가질 수있는 충분한 개발자가 있으며 개발 작업 스트림과 독립적으로 현재 프로덕션 환경에 패치를 적용해야합니다.

Liquibase 또는 수동 프로세스를 사용하여 버전을 업그레이드하기위한 패치 스크립트를 생성 할 수 있습니다. 수동 프로세스로 시작하여 패치에서 QA 용 스키마 비교 도구를 사용하는 것이 좋습니다. 복잡하지 않은 데이터베이스의 깨끗하고 자동화 된 투명한 동기화는 약간 유토피아 적입니다.

중앙 데이터 모델은 사용자가 원하는 모든 시스템에 보관할 수 있습니다. 지루한 엔터프라이즈 리포지토리 도구의 모든 것을 사용하여 테이블 스크립트를 만들었습니다. 테이블 스크립트 작성은 서브 버전과 같은 일반적인 소스 제어 도구와 잘 작동하지만 모든 리포지토리 도구가 버전 관리를 잘 수행하지는 않습니다.

마스터 데이터 모델 리포지토리로 무엇을 사용하든 해당 모델에서 환경을 배포하기 위해서는 상당히 깨끗한 메커니즘이 필요합니다. 환경으로의 롤아웃이 용이하도록 구성해야합니다. 또한 한 릴리스 버전에서 다음 버전으로 패치하는 메커니즘이 필요합니다.

내가 한 것

개발 환경을 관리 할 때 과거에 다음을 수행했습니다. 특히 첨단 기술은 아니지만 버전 제어 및 자동화 된 빌드가 가능하므로 환경을 특정 버전으로 쉽게 롤아웃 할 수 있으며 많은 환경을 유지하는 것이 매우 실용적입니다.

중앙 리포지토리 유지 관리 : 버전 관리 시스템에 보관 된 데이터베이스 생성 스크립트 또는 데이터 모델링 도구의 리포지토리 모델 일 수 있습니다. 선택해라. 이 모델에는 많은 수동 개입없이 스크립트에서 환경을 롤아웃 할 수있는 빌드 메커니즘이 있어야합니다.

참조 데이터가 많으면로드 메커니즘이 필요합니다. 원하는 방법에 따라 데이터베이스 또는 파일 세트에 보관할 수 있습니다. 파일의 장점은 코드 기반과 동일한 버전 제어 시스템에서 버전을 지정하고 레이블을 지정할 수도 있다는 것입니다. 소스 제어 저장소에있는 많은 CSV 파일과 벌크 로더 스크립트가이를 쉽게 수행 할 수 있습니다.

개발 환경을 배포하기위한 한 가지 옵션은 패치 된 프로덕션 데이터베이스를 적절한 버전으로 백업하여 개발자가 개발 환경으로 복원 할 수 있도록하는 것입니다.

쉽게 배포 할 수 있습니다. 모든 CI 빌드 프로세스와 마찬가지로 데이터베이스를 단일 스크립트에서 배포 할 수 있어야합니다. 데이터베이스 연결이 매개 변수화되거나 스크립트가 위치 독립적이며 연결을 통해 실행될 수 있도록 설정하십시오.

패치 스크립트 : 릴리스 된 각 버전에서 스크립트를 롤 포워드하고 롤백해야합니다.

리포지토리 모델에서 테스트 환경 구축 : 리포지토리와 동기화되지 않은 환경에서의 개발이 테스트에 걸리지 않도록합니다.

배포 프로세스 테스트 : 자동 패치 스크립트는 작성 가능하지만 테스트 가능해야합니다. 스키마 비교 도구는 패치 스크립트를 생성하는 데 사용하지 않더라도 매우 유용합니다.

• 테스트 한 저장소 모델 빌드를 사용하여 참조 환경을 작성하십시오.

• 프로덕션 릴리스 백업 또는 현재 릴리스 된 버전을 기반으로 빌드를 사용하여 연기 테스트 환경을 작성하십시오.

• 연기 테스트 환경에 대해 패치 스크립트를 실행하십시오.

• 스키마 비교 도구를 사용하여 연기 테스트 환경을 참조 환경과 비교하십시오. 패치 스크립트는 두 데이터베이스가 동일하므로 차이를 조사 할 수 있습니다.

이 과정에서 내가 좋아하는 것

이것은 약간 헤비급이며 상당히 관료적이고 불투명 한 프로덕션 환경에 배포하도록 설계되었습니다. 그러나 다음과 같은 장점이 있습니다.

• 개발자는 필요한 곳에 땜질을 할 수 있습니다.

• 여러 분기 및 개발 스트림을 수용 할 수 있습니다.

• 배포 스크립트 자체는 반복 가능한 방식으로 테스트 할 수 있습니다. 이는 반복성을 입증 할 수 있으므로 배포 bunfights를 종료하는 데 매우 유용합니다.

• 스키마 비교 도구는 배포 자체에 QA를 제공합니다.

• 테스트는 항상 릴리스 될 것으로 테스트되며, 동기화되지 않은 환경에서 발생하는 문제를 포착합니다.

• 리포지토리 모델 및 패치 스크립트를 기반으로 한 배포는 통제되지 않은 쓰레기가 개발 환경에서 생산 환경으로 우연히 마이그레이션되지 않음을 의미합니다.

• 배포 패치 스크립트를 수동으로 준비하고 테스트하는 것이 바람직하지만 많은 프로세스를 자동화 할 수 있습니다.

• 후프를 뛰어 넘지 않고도 저렴하고 배포가 쉬운 환경입니다.

• 개발자는 간단한 빌드 및 배포 프로세스를 수행 할 수있는 시스템을 만들어야합니다.

• 개발자는 기본 데이터베이스 관리 작업을 배워야하지만 테스트 및 프로덕션 환경은 멍청한 실수로부터 격리됩니다.

요구 사항을 해결하는 방법

1. 개발자는 개발 코드를 실행할 로컬 데이터 복사본을 가지고 있습니다
   
   . 배포 스크립트 또는 DB 이미지는 사용 가능한 모든 버전에서 환경을 설정할 수 있음을 의미합니다.

2. 데이터베이스 구조를 이전 변경 세트로 롤백 할 수 있음
   
   다시 배포 스크립트별로 정렬됩니다. 제어 된 프로세스를 통해 생성 된 DDL 또는 테스트 데이터베이스 백업 이미지를 통해 개발자는 보유한 특정 버전의 환경을 구축 할 수 있습니다.

3. 새로운 기능 스키마 변경 사항과 스키마 디자인 수정 변경 사항
   
   을 분리 할 수 ​​있음 공통 버전에 대한 패치는 svn 트리에서 별도의 포크로 유지 관리 할 수 ​​있습니다. 데이터베이스 백업이 참조 환경으로 사용되는 경우 소스 제어 프로젝트의 분기와 동일한 폴더 구조로 어딘가에 저장해야합니다.

4. 테스트를 위해 데이터베이스 구조를 로컬로 수정할 수 있음
   
   간단한 배포 프로세스를 통해 개발자는 환경을 로컬 상태로 땜질하고 쉽게 환경을 복원하거나 참조 환경을 만들어 비교하고 변경 세트를 만들 수 있습니다.