개발과 프로덕션 간의 WordPress 데이터베이스 동기화에 문제가 있으며 다른 사람들이이를 해결하는 방법이 궁금합니다. 나는 이 질문 에 대해 알고 있지만 실제로 더 나쁘고 현실적인 사용 사례를 다루지는 않습니다.
라이브 WordPress 웹 사이트가 있다고 가정 해보십시오. 나는 모든 것을 버려서 개발 환경에서 복제했습니다. 나는 변화를 시작했다. 1 주일 후 업데이트를 배포 할 준비가되었습니다. 그 동안 프로덕션 사이트의 데이터베이스 (새 게시물, 새 댓글 등)가 변경되었습니다. 롤아웃 중에 생산과 개발 간의 변경 사항을 어떻게 동기화하고이 프로세스를 자동화 할 수 있습니까?
답변:
dev로 가져와 데이터베이스를 프로덕션으로 옮기는 것이 가장 좋습니다. 가져올 때 프로덕션에서 모든 새 미디어 파일을 다운로드하기 때문입니다.
그 동안 제작이 변경되었습니다 (새 게시물, 새 댓글 등).
이렇게하면 변경된 내용을 가져 오는 문제를 해결할 수 있습니다.
MySql을 사용하기 전에 두 데이터베이스를 모두 백업하고 gz 데이터베이스를 프로덕션 서버로 이동하고 덤프를 업로드하십시오 (프로덕션과 동일한 경우 dev 이름 변경).
INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`
MySql 명령에 익숙하지 않으므로 옵션 1을 사용합니다.
정확히 동일한 유형의 데이터 (일부 새로운 블로그 게시물, 새로운 의견)에 가깝다면 실제로 동기화 해야하는 이유를 모르겠습니다. 사이트의 코드가 동일하게 작동하기 때문에 사이트의 코드 작동 방식을 변경하는 것은 아닙니다. 새로운 유형의 데이터가 아닌 한 일반적으로 걱정하지 않습니다.
나는 항상 사이트의 모든 게시물, 페이지, 코멘트가 사이트에 대한 좋은 데이터 샘플을 가지고 있는지 확인합니다.
id데이터베이스 의 게시물 / 페이지 에 적합합니다.
병렬로 변경 주제를 터치하자마자 구성 관리 영역을 터치합니다. 패턴이 많으면 자체 커뮤니티 (http://www.cmcrossroads.com/)와 버전 관리 (svn / git와 같은)는 아니지만 클리어 케이스와 같은 구성 관리 (패턴)를 지원하는 도구가 있습니다. (완전히 다른 지역).
이 경우 여전히 간단한 상황이므로 일부 제한 사항 및 일부 수동 작업 및 일부 목록으로 작업 할 수 있습니다.
시나리오는 이상적인 코드 솔루션을 설명하기 위해 생각하고 있습니다. 여러 개발자가 동일한 코드베이스에서 작업하고 여러 테스트 환경, 여러 수락 환경, 여러 곳에서 가능한 모든 프로덕션 수락 환경.
좀 더 전문적인 작업을 원한다면 :
a) 발생하는 모든 구성 항목의 목록을 작성하십시오. 이것은 WordPress 코드 자체, 외부의 플러그인, 컨텐츠, 메타 데이터 일 수 있으며, 어떤 종류의 "관리"하에 가져올 구성 요소를 결정합니다.
b) 발생할 수있는 워크 플로우를 기술한다. 예를 들어 수정으로 발생하는 일, 새로운 개발에서 발생하는 일, 어떤 경우에 귀하의 콘텐츠를 변경 하는가, 누가 무엇을하고, 누가, 누가 그것을, 누가 그것을 소유하고 있는가 예 : 새 게시물 또는 새 플러그인
c) 병렬 작업을 위해서는 먼저 관리하려는 CI를 설명하고 흐름이 항상 개발에서 생산에 이르는지 또는 실제로 두 가지 방법 모두를 수행해야하는지 결정하십시오.
d) (a)의 각 CI 유형에 대해 해결책을 작성하십시오. 예를 들어 텍스트 (또는 php 파일과 같이 내 보낸 텍스트이지만 XML 파일의 일반 텍스트)와 같은 모든 경우 병합이 가능합니다. 이것은 실제로 문제가되지 않지만 훌륭한 병합 도구가 필요합니다. 예를 들어 ClearCase를 사용하면 다음과 같은 상황에서 3 가지 방식으로 병합됩니다. 1) 사소한 병합 : 자동으로 수행됩니다. 2) 사소하지 않은 자동 :이를 자동으로 수행하지만 확인해야합니다. 예를 들어 한 줄에서 몇 가지 변경 사항이 있습니다. 사소하지 않은 부분은 수동으로 관리해야하는 최소한의 부분입니다. 좋은 병합 도구를 사용하면 다음과 같은 이점을 얻을 수 있습니다 (예 : 단어 병합 및 특정 파일에 대해 다른 상업 또는 비 상업 합병에서 연결할 수있는 곳). 유형). 또한 (a) 복사 전용 파일에서 식별 한 경우 해당 파일의 동작은 병합되지 않고 병합없이 다른 버전을 덮어 쓰는 방식으로 복사됩니다 (예 : 수정하지 않은 플러그인). 이러한 유형의 대부분은 다른 행동으로 가능합니다. 그러나 CI 간의 관계를 적어 두십시오.
그런 다음 텍스트가 아닌 병합의 경우 2 개 위치에서 변경된 이미지 (예 : 이미지)를 처리하는 방법을 결정해야합니다. 여기서 생산은 항상 선호도가 있다고 생각할 수 있습니다 (적어도 그것이 내가 생각하는 것입니다).
따라서 ...이 문제를 해결하려면 다른 스트림을 지원하는 버전 관리 도구가 필요합니다. 각 스트림은 한 부분을 나타냅니다. (이것은 귀하의 요구에 따라 상당히 복잡 할 수 있지만이 경우에는 매우 간단하다고 생각합니다).
이제 이러한 스트림을 WordPress 설치에서 관리하고 데이터베이스의 내용과도 동기화 할 수 있다면 CM / 버전 관리 도구에서 병합을 수행 한 다음 다른 환경으로 다시 내보낼 수 있습니다.
문제는 ... 이것을 먼저 적어야합니다. 이것은 기술적 해킹이 아닙니다. 구성 관리와 관련된 기본 패턴이므로 여기서 이상한 점은 없지만 적어 두어야합니다. 예를 들어 설치된 플러그인이 다른 환경과 다른 일부 데이터로 데이터베이스를 변경한다는 것을 알 수 있으므로 이에 대한 추가 절차가 필요합니다.
기술적으로는 거의 모든 것이 가능합니다. http://www.cmcrossroads.com/forums 는 항상 동일한 접근 방식과 동일한 CM 패턴 세트를 사용하지만 수십 또는 수백 배 더 복잡한 시나리오를 확인 하십시오 .
한마디로 : 버전 관리 계층을 그 아래에 놓고 병합을 자동화하고 충돌을 처리 한 다음 대상 환경으로 가져옵니다. 여기에 맞는 스트림 전략을 생각해 적어보십시오. 조그마한 비트 비트 CM 관리를 수행하십시오. 그렇지 않으면 전문적인 솔루션이 될 것입니다. 그렇지 않으면 일부 DB 복사 해킹, 스크립트 등을 설치하십시오.
방금 프로덕션 데이터를 스테이징에 동기화하는 방법에 대한 게시물을 작성했습니다. http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database 에서 블로그 게시물을 확인하십시오. -제작에서 스테이징 환경으로 /
코드와 다른 것들도 동기화하려면 관련 무시 파일로 git 또는 mercurial 리포지토리를 만드는 것이 좋습니다.
스테이징에서 prod를 차등 업데이트하려면 마이그레이션 스크립트를 만드는 것이 가장 안전하고 최선의 방법이라고 생각합니다.