테스트가 프로덕션에 가까울수록 프로덕션 동작을 더 잘 모방 할 수 있습니다. 프로덕션에서 테스트 환경으로 데이터베이스 백업을 복사하고 싶지만 테스트가 작동하도록 변경하고 실제 고객에게 실수로 이메일을 보내지 않기 위해 web/%secure/base_url테스트 URL을 설정 하는 것 외에 무엇을 변경해야 합니까?
이 질문에 대해 생각하는 또 다른 방법 은 내 프로덕션 데이터에서 Magento 샘플 데이터 와 같은 것을 생성하는 방법을 고려하는 것 입니다.
답변:
1) DB 덤프
내보내기를 수행하면 다음 테이블의 구조 만 내보낼 수 있습니다.
core_cache
core_cache_option
core_cache_tag
log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online
enterprise_logging_event
enterprise_logging_event_changes
index_event
index_process_event
report_event
report_viewed_product_index
dataflow_batch_export
dataflow_batch_import또한 core_url_rewrite여러 테스트에 대해 모든 레코드가 필요하지 않은 경우 구조와 함께 만 가져 와서 카탈로그 URL 다시 쓰기 재 색인을 실행할 수 있습니다.
버려진 카트를 청소할 수도 있습니다 (힌트 :). sales_flat_quote필요하지 않은 주문을 제거하고 수량을 제한 할 수도 있습니다.
2) 구성 설정
system/smtp/disable실수로 이메일을 보내지 않도록 이메일 비활성화 ( )3) 고객 정보를 익명화하십시오
4) 모듈 설정
분기를위한 DB 덤프를 처리하는 스크립트를 작성했습니다. 이 기사를 읽으십시오 .
기본 원칙은 local.xmlDB 자격 증명을 가져 오기 위해를 읽고 그런 다음 데이터를 덤프합니다. 덤프를 두 부분 (구조 만)과 데이터로 나눕니다. 그러나 핵심은 필수적이지 않은 데이터 를 생략하여 기존 덤프 프로세스의 속도를 높이고 덤프 중 라이브 사이트를 차단 / 매단시키는 테이블 잠금을 가장 중요하게 방지하는 것입니다.
MySQL 덤프가 있으면 다음을 사용하여 URL을 매우 쉽게 변경할 수 있습니다. sed
sed -i 's/www.mydomain.com/staging.mydomain.com/g' ./var/db.sql그런 다음 새 DB로 mysql 가져 오기를 실행하십시오.
따라서 스크립트가 없으면 매우 기본적인 버전은 다음과 같습니다.
mysqldump -hHostname -uUsername LiveDbname -p > db.sql
sed -i 's/www.mydomain.com/staging.mydomain.com/g' db.sql
mysql -hHostname -uUsername DevDbname -p < db.sql이런 식으로 DB의 URL을 변경 한 경우 local.xml 파일을 삭제하거나 설치 프로그램을 다시 실행해야 할 이유가 없습니다.
분기의 전체 과정은 Magento GIT 안내서 있습니다. 이는 개발 브랜치를 생성하는 좋은 프로세스이지만 라이브 DB를 크게 줄입니다. 따라서 테스트는 실제 사이트와 완전히 동일하지 않습니다.
따라서 스테이징 사이트에 바닐라 DB 덤프, sed replace, DB 가져 오기를 수행하면 충분합니다. 라이브 사이트를 최대한 가깝게 미러링 / 일치시킵니다.
고객과의 의사 소통 방지 측면에서, 테스트를 위해 고의적으로 계정을 생성하고 테스트를 위해 실제 고객 주문을 사용하지 않기 때문에 반드시 필요한 것은 아닙니다.
아무것도. 안전하고 안전하지 않은 URL을 변경하면 충분합니다.
log_*덤프를 더 가볍게 만들기 위해 테이블 데이터 를 생략 할 수도 있습니다 .