시스템 업그레이드 프로젝트를 수행 할 때 클라이언트 시스템을 새로운 Magento 설치와 비교하는 것이 가장 중요합니다. 저는 이전 프리랜서, 계약자, 컨설턴트 또는 대행사가 수행 한 번거롭지 만 비즈니스 크리티컬 한 작업을 포착 할 수 있도록 표준 마젠 토의 일부가 아닌 핵심 핵 또는 추가 파일을 찾고 있습니다.
그래도 항상 나를 혼란스럽게하는 것은 패치입니다. 수년에 걸쳐 Magento는 일반적으로 보안 수정 또는 운송 / 지급 공급 업체의 API 변경을 해결하기 위해 "버전 간"패치를 발표했습니다.
문제는 diff의 관점에서 패치가 코어 핵과 구별되지 않는다는 것입니다. 특히 시스템에 적용된 패치 (있는 경우)를 모르는 경우에 특히 그렇습니다.
내 질문으로 이어집니다.
핵심 핵과 패치를 어떻게 구별합니까?
답변:
지원에 의해 제공되는 Magento 패치는에 로그를 추가합니다 app/etc/applied.patches.list. 패치 "스크립트"가이 작업을 수행 한 시간 또는 기간을 모르겠습니다. CE 패치도이 작업을 수행하는 것 같습니다.
이것은 내가 자주 다루는 것 (그리고 지금 당장 작업 중)이며, 불행히도 지금까지는 완전히 수동 프로세스입니다. 우리는 초기 자동 감사의 일부로 수정 될 수있는 모든 파일에 플래그를 지정하는 자동 프로세스를 가지고 있습니다. 새로운 지원 고객. 그런 다음 누군가 파일을 확인한 후 명백한 오 탐지 (예 : 공백 변경)를 배제합니다.
그런 다음 재미있는 부분-Magento와 꽤 오랫동안 협력해온 우리 팀의 선임 멤버는 수정 된 파일이 패치의 결과 일 수 있는지 확인하기 위해 결과를 살펴 봐야합니다. 우리는 우리가 알고 있거나 손에 넣을 수있는 모든 패치를 검사하기 위해 시스템을 업데이트하는 것을 보았습니다. CE에는 효과가있을 수 있지만, EE에서는 때때로 패치를 직접 발행하기 때문에 EE에서는 훨씬 더 어렵습니다. 다른 방식으로 출시되거나 일관된 방식으로 카탈로그되지 않은 고객에게.
따라서이 수준의 검토를 수행 할 때 이러한 패치 + 상식을 적용한 과거 경험에 의존합니다 (즉, API의 엔드 포인트 만 변경 되었습니까? 그렇다면 변경된 엔드 포인트가 업데이트 된 버전에 있습니까? 패치였으며 무시할 수 있습니다).
CE 다운로드 페이지 등에서 사용 가능한 모든 패치를 적용 가능한 모든 버전의 CE에 적용하고 해당 패치를 확인하는 것은 이론적으로 간단합니다. (FYI, 첫 번째 패스에는 diff를 사용하지 않습니다. 이 기술을 먼저 다운로드하지 않고도 사이트에서 원격으로 확인할 수있는 도구에이 기술을 구축했기 때문입니다. 패치의 대부분을 배제 할 수 있지만 CE의 공개 다운로드 영역이나 EE의 클라이언트 / 보호 된 다운로드 영역에 게시되지 않은 CE 또는 EE 패치에는 여전히 도움이되지 않습니다. 따라서 Magento는 모든 패치를 모든 고객이 사용할 수 있도록 일관된 정책을 만들고이를 고객에게 전달할 수 있도록 게시해야합니다.
따라서 불행히도 Magento 측에서 변경 사항이 발생할 때까지 100 % 자동화 할 수있는 방법이 없다고 생각합니다.
git diff depot/master origin/master. 도전은 .gitignore입니다. 다른 옵션은 버전을 별도의 디렉토리로 복제 한 다음 사이트 app/code/core디렉토리를 그 디렉토리에 복사하는 것입니다. git diff -w그러면 당신에게 말할 것입니다.
많은 업그레이드를 수행하고 프로세스를 체계화하려고 할 때 내가 접근 한 한 가지 방법은 실제로 패치를 코어 코드 리포지토리에 직접 커밋하여 비교하는 데 사용했습니다.
실제로 두 가지 이점이 있습니다.
diff에 더 이상 오 탐지가 나타나지 않습니다.
특정 패치 가없는 사이트가 있다고 가정 해 봅시다 . 기술적으로 패치되지 않은 새로운 다운로드와 비교하여 아무것도 누락되지 않았더라도 diff에 누락 된 코드로 표시되기 때문에 이것이 문제라고 말할 수 있습니다. 그러나 실제로 패치가 누락되었다는 것은 실제로 해결해야 할 문제이므로 업그레이드와 함께 수정하기 위해 diff에 표시하는 것이 완벽합니다.
2-3 명 이상의 클라이언트를 관리하는 경우 프로젝트 저장소에 Magento를 사용하는 것이 처음에는 좋은 생각이라고 생각하지 않습니다. 적용된 시스템 패치를 코어 핵으로 엉망으로 만드는 것이 항상 더 쉽기 때문입니다.
내 생각에 가장 좋은 방법은 공식 태그가 적용된 특정 Magento 버전을 가리키는 버전 태그가있는 작곡가 Magento 저장소 미러를 사용하는 것입니다.
또한 Magento 설치와 일치하는 버전 번호를 가진 composer를 통해 설치를 도입하여로드 량이 많은 웹 사이트 및 기타 일부의 경우 Mage_Core_Model_Config와 같은 파일에 대한 자체 패치를 쉽게 유지 관리 할 수 있습니다.
따라서이 경우 모든 고객 프로젝트를 패치 된 Magento 코드로 업그레이드하면 작곡가 파일의 버전이 충돌 할뿐입니다. 또한 프로젝트 코드를 핵심과 별도로 유지하면 개발자가 핵심을 해킹하지 않아야합니다.
패치와 핵의 정의에 관해서는 다음과 같이 호출하는 것을 선호합니다.
따라서 별도의 리포지토리로 코어를 이동하면 항목 1에 따라 패치 된 버전 만 있는지 확인할 수 있습니다. 또한 작곡가를 통해 로컬 코드 풀에 직접 패치를 설치할 수 있으므로 포인트 3에 따라 모든 것이 있습니다. 4 프로젝트 리포지토리에서 git commit hook을 생성하여 해당 디렉토리로의 코드 커밋을 금지 할 수 있습니다.
해당 /app/etc/폴더 에서 적용된 패치 파일을보고 뒤로 작업합니다. 그러나 업그레이드에서 배운대로 패치 된 파일이있는 버전의 파일을 삭제할 수 있으며 다음에 패치 할 때 깨끗합니다.
마젠 토의 어떤 것도 패치라고 부릅니다. 다른 모든 것은 해킹입니다.