단계적 환경에서 모듈을 올바르게 제거하는 방법은 무엇입니까?

일부 모듈에는 분리 루틴이 있습니다. 일반적으로 해당 모듈의 데이터베이스 테이블, 변수 테이블의 변수 및 해당 모듈에서 소개 된 로케일을 제거합니다. 이 루틴 .install은 해당 모듈에 있습니다.

따라서 해당 모듈이 없으면 실행할 수 없습니다. 현재 단계는 다음과 같습니다. 내 질문은 : 이보다 간단하고 효과적으로 수행 할 수 있습니까? foo_bar 모듈을 제거한다고 가정 해보십시오.

RCS에서 새 릴리스를 준비하십시오.
- foo_bar 위에서 사용하거나 빌드 한 모든 CSS 및 테마 재정의가 제거됩니다.
- foo_bar에 따라 모듈에 대한 모든 CSS 및 테마 재정의가 제거됩니다.
해당 릴리스를 승인으로 푸시하십시오. 최신 프로덕션 데이터베이스 복사본으로 관리 (모듈 / 관리자)에서 deïnstallation을 테스트하십시오.
문제가 해결되지 않으면 새로운 코드베이스를 프로덕션 환경에 배포하고 foo_bar 및 해당 종속 항목을 정의하십시오. 이것은 다양한 모듈에서 설치 제거를 호출하여 데이터베이스를 정리합니다.
RCS (git)에서 코드가 실제로 제거되는 새 릴리스를 준비하십시오.
우연히 이것에 의존하지 않는 경우 테스트 할 위치에 수용하십시오 (어떤 추악한 모듈 또는 테마 기능에는 다른 모듈의 파일, 특히 CSS, JS 또는 이미지 파일)이 직접 포함됩니다.
수락되면 프로덕션에 새 릴리스를 배포하십시오. 프로덕션에는 이제 깨끗한 데이터베이스와 깨끗한 코드베이스가 있습니다.

해결 방법을 볼 수없는 문제는 항상 두 개의 릴리스가 필요하다는 것입니다. Drupal에서 릴리스를 수행하려면 사이트가 오프라인 상태 여야하므로 모듈 하나만 제거하면 다운 타임이 두 배가됩니다. 또한 전문 호스팅 환경에서는 비용이 많이 들고 시간이 많이 걸리거나 실망 스러울 수있는 두 가지 릴리스 절차가 필요합니다.

첫 번째 반복에서 코드베이스에서 모듈을 제거하면 데이터베이스에 많은 보푸라기를 유지하면서 제거 후크를 실행할 수 없습니다. 몇 개의 테이블뿐만 아니라 대부분 변수와 로케일. 코드베이스에서 모듈을 제거하지 않으면 코드베이스가 오래되고 사용되지 않는 코드로 커집니다. 이렇게하면 성능 오버 헤드가 발생하지 않지만 코드를 유지 관리하기가 더 어렵고 어렵습니다.

이것을 어떻게 처리합니까?

[편집 : 배포가 까다로운 절차라는 참고 사항이 추가됨]

nodes deployment

— 틈새
소스

준비 서버에서 1-6 단계를 먼저 수행 한 경우 라이브 사이트를 HEAD ^로 업데이트하고 제거를 수행 한 다음 HEAD (모두 한 자리에)로 업데이트 할 수 없습니까?

— Andy

내 모든 프로젝트가 자식 배포 된 경우 예. 그러나 일부는 타르볼을 우편으로 보내야하는 반면, 다른 일부는 ftp 등을 사용합니다. 그러나 자식과 일부 자식 후크 스크립트를 살펴 보는 것은 매우 흥미로운 아이디어입니다.

— berkes

왜 사이트를 중단해야합니까?

— Letharion

@Letharion : 1) 사이트를 중단하면 해당 데이터베이스를 변경하는 과정에서 데이터베이스에 원치 않는 쓰기가 금지됩니다. Drupal은 거래를 사용하지 않습니다. 2) 특정 데이터베이스 상태 (예 : 특정 cck 필드가 필요한 테마)에 의존하는 새 코드를 배포하면 코드 롤아웃과 데이터베이스 업데이트 사이에 사이트가 중단됩니다.

— berkes

데이터베이스와 코드를 동기화하는 데 매우주의하십시오. 질문에서 언급했듯이 제거 할 모듈이 라이브 데이터베이스에서 실행될 때까지 제거 할 모듈이 코드베이스에 있어야합니다. 이것은 git pull 워크 플로만으로는 해결되지 않을 Drupal의 한계입니다.

프로세스를 조정하는 대신 업데이트를 처리하는 데 필요한 가동 중지 시간을 줄일 수있는 방법을 찾는 것이 좋습니다. 이 문제를 해결하려면 잉 / 양 멀티 사이트 준비 환경 을 설정하는 것이 좋습니다 . nb 이전 링크에 포함 된 스크립트를 사용하지 않았습니다. 배포하는 동안 라이브 사이트와 스테이지 사이트를 교환 할 수 있다는 동일한 아이디어에 따라 다르게 설정하는 것이 좋습니다 .

다음과 같이 조정하여 질문에 설명 된 것과 동일한 절차를 계속 수행하십시오.

ㅏ. 평소와 같이 dev에서 stage로 동기화합니다. 제거 할 모듈을 제거한 후 코드 제거 등을 수행하여 테스트하십시오. Git 워크 플로우 참고 사항 : 태그를 작성하거나 코드의 다른 상태의 숨겨 짐을 확인하십시오. 재정의 & c. 필요에 따라 제거 등. 아마도 두 개의 참조 만 필요합니다.

비. 테스트가 완료되고 승인되면 스테이지 (양)의 코드를 라이브 상태 (잉)로 복원하십시오.

씨. 사용자가 시스템의 컨텐츠를 변경할 수 없도록하여 라이브 (잉잉) 사이트를 업데이트 할 수 있도록 준비하십시오. 권한 테이블에 대한 SQL 업데이트는 일반적으로 여기에서 수행됩니다. 이 시점에서 사용자는 여전히 라이브 사이트에서 컨텐츠를 읽을 수 있지만 컨텐츠를 업데이트하려고하면 권한 거부 오류가 발생합니다. (멋진 경우 권한 거부 처리기를 변경하여 함수를 일시적으로 사용할 수 없다는 적절한 알림을 인쇄 할 수 있습니다.)

디. 이제 업데이트에서 권한 테이블을 제외하고 라이브 (잉) 데이터베이스를 다시 스테이지 (양) 데이터베이스로 푸시하십시오.

이자형. a 단계를 반복하십시오. 다시. 해시 태그가 편리한 경우 제거 할 모듈이있는 상태로 쉽게 복원하고 데이터베이스에서 설치 제거 후크를 실행 한 다음 1 단계의 항목이 병합 된 코드 상태로 돌아가십시오. 다시.

에프. 이제 잉과 양을 교환 할 준비가되었습니다. Apache 구성 지시문을 조정하여이를 수행하십시오. 을 수행하면 /etc/init.d/apache restart일부 연결이 끊어 지지만 /etc/init.d/apache reload깨끗한 스왑이 가능합니다.

지. 라이브는 이제 '양'입니다. 권한 테이블은 여기에서 수정되지 않으므로 사용자는 컨텐츠를 작성할 수 있습니다. 단계를 자동화하는 경우 e. f. 사용할 수없는 시간이 매우 짧아야합니다.

h. 코드와 데이터베이스 모두에서 라이브 (양)를 다시 스테이지 (잉)로 푸시하거나 필요에 따라 개발자로부터 푸시합니다. 이제 다음 반복을위한 깨끗한 환경이 준비되었습니다.

— greg_1_anderson
소스

단계 c에서 잉 양은 끔찍하게 실패한다. 편집 중심의 비 액세스 전용과 같은 매우 구체적인 사이트 만 작동합니다. 주석, 노드 등을 비활성화해야 할뿐만 아니라 세션 테이블, 워치 독, 카운터 등이 업데이트되어 기록되기 때문입니다. 가동 중지 시간은 유감 스럽지만 피할 수없는 부작용입니다. 실제로 특정 사이트의 경우 잉 양은 배포 할 때 사용할 수있는 매우 흥미로운 개념입니다.

— berkes

물론 당신은 맞습니다; 그러나 최종 단계를 스크립팅하면 가동 중지 시간이나 정보 손실이 줄어 듭니다. 세션 테이블에서 항목이 손실되면 사용자는 다시 로그인해야합니다. 카운터가 조금 떨어져있을 수 있습니다. 워치 독에서 알림이 두 개 누락 될 수 있습니다. 이것이 "이 사이트가 유지 관리를 위해 다운되었습니다"라는 짧은 기간보다 더 나쁘다면 반드시 더 간단한 솔루션을 사용하십시오. 당신이 경우 정말 원한, 당신은 스왑 후 카운터 및 감시 메시지를 복구하려고 시도 할 수 있습니다. info + uptime이 매우 귀중하지 않으면 이는 가치보다 복잡 할 수 있습니다.

— greg_1_anderson

mysql 이진 로그를 사용하여 전환 사이트에서 트랜잭션을 추적하는 것을 고려할 수 있습니다. dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html을 참조하십시오 . 나는 물건을 하나로 합치기를 꺼려하지만 카운터 / 워치 독 메시지를 대역 외에서 추적 할 수 있습니다. 세션 테이블을 처리하는 가장 쉬운 방법은 전환 중에 로그인을 비활성화하는 것입니다.

— greg_1_anderson

귀하의 의견으로 다른 가능한 해결책을 얻었습니다. 모듈에 대한 모든 hook_uninstall을 특수 목적 모듈의 hook_update_n () s : uninstall.module로 집계하십시오. 그렇게하면 첫 번째 반복에서 코드베이스를 제거하고 실제 릴리스에서 훨씬 더 빠른 결정을 얻을 수 있습니다. 이 정보를 긁어내는 drush-script 일 수 있습니다.

— berkes

조금 도움이 될 것입니다. 제거 할 모듈에 대한 참조가 래핑되도록 모든 사용자 정의 PHP 코드를 변경하십시오 if (module_exists('removeme')) { ... }. 해당 코드를 배포하십시오. 모듈을 제거해도 더 이상 사용자 지정 코드가 손상되지 않는지 테스트하고 확인하면 배포가 간단 해집니다. 아직 활성화되지 않은 사이트에서 비활성화 단계를 수행하는 것이 좋습니다. 그러나 이로 인해 창의 범위가 약간 좁아 질 수 있습니다. 사용자 정의 업데이트 후크가 라이브 모듈 비활성화를 수행하는 것이 더 안전하다고 생각하지 않습니다.

— greg_1_anderson