WP 사이트의 v2를 시작하기위한 효과적인 전략이 있습니까?

우리 팀과 저는 기존의 워드 프레스 사이트를 보유한 고객과 함께 상당한 양의 콘텐츠와 맞춤 테마를 사용하고 있습니다. 그룹 블로그로, 전 세계에 항상 콘텐츠를 추가 및 편집하는 여러 블로거가 있습니다.

우리의 임무는 몇 가지 새로운 기능으로 완전히 새로운 테마를 만드는 것입니다. 이러한 기능 중 일부에는 새로운 사용자 정의 위젯, 플러그인 및 데이터베이스 필드가 필요합니다.

현재 자체 개발 시스템을 개발하고 단일 개발 서버에 통합하고 있습니다. 모든 코드는 SVN 버전입니다. 우리가 임명 한 DBA는 데이터베이스 변경 사항을 개발자 DB에 수동으로 병합하고 있지만 곧 자동화 할 수 있기를 바랍니다.

방금 프로덕션 릴리스 프로세스에 대해 이야기하기 시작했습니다. 의미 : 완료되면 모든 사용자 지정 코드를 프로덕션 (실제) 서버에 원활하고 가능한 한 중단없이 어떻게 가져올 수 있습니까?

우리는 몇 가지 계획을 염두에두고 있지만 다른 사람들도이 문제를 어떻게 해결했는지 듣고 싶습니다. 피해야 할 모범 사례 나 알려진 함정이 있습니까?

SethMerrick의 조언을 따르면 IP 주소를 변경하기 전에 적절한 DNS 레코드의 TTL을 5 분 또는 몇 시간 (현재 TTL이 무엇인지에 따라)으로 낮추어 전환 시간을 크게 줄일 수 있습니다.

이렇게하면 원격 DNS 서버에 5 분 동안 만 주소를 캐시하도록 지시합니다. IP를 변경하면 TTL을 이전의 것으로 늘릴 수 있습니다. 영향을 더욱 최소화하려면 트래픽이 적은 기간 동안 전환을 수행하십시오.

이것이 적용 가능한지 확실하지 않지만 트래픽이 많은 사이트를 동시에 마이그레이션하고 업그레이드하는 비슷한 프로세스를 거쳤습니다.

기본 전략은 준비 서버에서 작업 한 다음 모든 준비가 완료되면 라이브 서버에서 mysql 덤프를 수행하고 준비 서버로 가져와 필요한 정리를 수행 한 다음 DNS 레코드를 준비 서버로 지정하는 것입니다. 준비 서버를 새 라이브 서버로 만듭니다.

까다로운 점은 DNS 전파 중에 누적 된 모든 데이터를 준비 서버 (현재 라이브 서버)에 병합하는 것입니다. 즉, mysql 덤프 / 업데이트 DNS 수행 시점과 DNS 전파 완료 시점 사이에 30 시간이 지나면 이전 사이트에서 새 사이트로 30 시간의 레코드를 선택적으로 병합해야합니다.

매끄럽게 진행되는 과정은 아니지만 일주일이지나면서 모든 꼬임이 사라졌습니다.

@Mike Lee : 훌륭한 질문이자 WordPress의 성배 중 하나 (또는 ​​Drupal, Joomla 등의 문제에 익숙한 주류 오픈 소스 CMS)

그것은 확실히 체크 아웃 할 당신의 사용 사례를 해결하기 위해 의미 아니지만 관련 질문에 대한 내 대답을 난 그냥 워드 프레스를 통해 제공 플러그인 교환라는 답변 베타 수준을 설명 WP 마이그레이션 웹 호스트를 그래, 내가 빨아 (그것은 창조적 인 이름에 관해서 .)

그러나 나는 또한 플러그인으로 설명하는 유스 케이스를 해결하고 현재 그것을 달성하는 방법에 대해 생각하고 있습니다. 나는 그것에 접근하는 방법이 그것을 일반적으로 해결하는 것을 포기하고 대신 WordPress에 존재하는 알려진 패턴을 해결하고 다른 사람이 특별한 유스 케이스를 위해 플러그인 을 " 연결 " 하도록 허용하고 있다고 생각합니다 . 또한 WordPress의 데이터와 구조를 PHP 파일의 데이터로 직렬화하여 향후 플러그인이 소스 코드 제어 시스템과 같이 델타를 적용하여 현재 버전의 소스에 도달 할 때 델타를 적용함에 따라 변경 사항을 적용 할 수 있도록 접근 방식을 생각하고 있습니다. 암호.

따라서 귀하의 문제에 대한 답을 완전히 얻거나 풀지 않는 동안 나는 여러분에게 좋은 음식을 제공하고 귀하 또는 다른 사람이 최종 해결책에 대해 협력하기를 희망합니다.