답변:
이것은 거의 모든 사람들이 다른 답을 가지고 있다는 사소한 문제입니다. 프로덕션 푸시에 대한 준비를 처리하는 표준 Drupal 방법은 없습니다. Drupal 쇼를 운영하는 Dries Buytaert 는 Drupal 8 의 주요 이니셔티브 중 하나였습니다 . 물론 Drupal 7은 방금 출시되었으므로 어느 정도의 열매를 맺기까지는 시간이 걸릴 것입니다.
이 문제는 두 가지 별도의 문제로 나눌 수 있습니다.
전자는 대부분 기능 모듈로 처리 할 수 있습니다.이 기능 은 사이트 구성을 가져 와서 Drupal 설치에 추가 할 수있는 모듈로 바꿉니다. 이렇게하면 버전 관리 시스템에 추가 할 수 있으며 걱정할 필요가 없습니다. 콘텐츠를 마이그레이션 할 때 날아갑니다.
후자는 실제로 까다 롭습니다. 활성 사이트에서는 개발 환경과 처음 동기화 한 후에도 프로덕션 환경에서 내용이 변경 될 수 있기 때문입니다. 이렇게하면 구성 중에 할 수있는 것처럼 스테이징 중에 컨텐츠를 도매로 교체 할 수 없습니다.
또한 Drupal은 컨텐츠에 UUID (Universally Unique Identifier)를 사용하지 않습니다. 노드 나 사용자가 추가 될 때마다 ID가 1 씩 증가합니다. 따라서 개발 사이트의 노드 45는 프로덕션 사이트의 노드 90 일 수 있습니다.
불행히도, 나는 이것을위한 훌륭한 해결책을 가지고 있지 않습니다 : 콘텐츠 준비는 Drupal의 진정한 약점입니다. 내가 개인적으로하는 것은 프로덕션 사이트에만 콘텐츠를 추가하는 것입니다. 클라이언트가 컨텐츠를 게시하기 전에 어떻게 보이는지 확인하려면 클라이언트 만 액세스 할 수있는 프로덕션 사이트의 복제본을 설정합니다. 그런 다음 승인되면 동일한 변경 사항이 프로덕션에 직접 적용됩니다.
또 다른 대안은 배포 모듈입니다. 준비 컨텐츠를 비교적 고통스럽게 만들기 위해 서비스 를 활용해야합니다 . 그러나 나는 그 효과를 보증 할 수 없으며 Drupal 7 버전이 없습니다.
우리의 과정에서.
우리는 Hudson을 사용하여 개발 / 스테이지 브랜치를 재구성하여 라이브 및 개발 브랜치를 동기화합니다.
Git을 사용하고 있기 때문에 우리가 수행하는 모든 작업에는 자체 브랜치가 있으며 QA에 전달되면 회귀 테스트를위한 스테이징 서버로 마스터에 병합됩니다.
마스터가 준비되면 Release Server
라이브 (구성, 하드웨어 등)의 복제 본인 테스트 릴리스를 수행합니다 .
Feature
모듈을 사용 하여 구성을 배포합니다. 일부 기능은 아직 기능에서 지원되지 않으므로 hook_update_N을 사용하고 updatedb.php 또는drush -vd updb
drush fra --yes
)를 수행 하여 모든 대체 기능을 되 돌리십시오.Boost (Move to Varnish)와 Memcache를 사용하고 있으므로 cache ( drush cc all
) 를 지워야합니다 .
우리는 rsync를 사용하여 이미지 / 비디오 등을 동기화하고 있습니다 ...
XAMPP 서버에서 다른 서버로 마이그레이션하기 위해이 사이트 의 지침을 따랐습니다 .
개발 서버에서와 동일한 방식으로 프로덕션 서버에서 동일한 구조를 유지해야합니다. 또한 admin / config / media / file-system에 있는 Drupal 관리 대시 보드에서 일부 파일을 편집해야했습니다.
공용 파일 시스템 경로 및 임시 디렉토리 에 올바른 위치가 설정되어 있는지 확인하십시오 .