Bản vá hoặc Core Hack

Khi tôi tham gia dự án nâng cấp hệ thống, một trong những điều tôi làm là tìm hệ thống của khách hàng so với bản cài đặt Magento mới. Tôi đang tìm kiếm các bản hack lõi hoặc các tệp bổ sung không phải là một phần của Magento tiêu chuẩn để đảm bảo tôi nắm bắt được bất kỳ công việc quan trọng nào nhưng được thực hiện bởi một freelancer, nhà thầu, nhà tư vấn hoặc đại lý trước đó.

Một điều luôn làm tôi bối rối là các bản vá. Trong những năm qua, Magento đã phát hành các bản vá "giữa các phiên bản" - thường là để giải quyết vấn đề bảo mật hoặc thay đổi API của nhà cung cấp dịch vụ vận chuyển / thanh toán.

Vấn đề là, từ quan điểm của một khác biệt, các bản vá không thể phân biệt được với các bản hack cốt lõi - đặc biệt là khi bạn không biết bản vá nào (nếu có) đã được áp dụng cho hệ thống.

Điều đó dẫn đến câu hỏi của tôi.

Làm thế nào để bạn phân biệt giữa một hack lõi và một bản vá?

Các bản vá Magento được cung cấp bởi bộ phận hỗ trợ sẽ nối thêm nhật ký các loại app/etc/applied.patches.list. Tôi không biết khi nào hoặc bao lâu các "kịch bản" đã làm điều này. Các bản vá CE dường như cũng làm điều này.

Đây là điều tôi thường xuyên xử lý (và tôi đang làm việc ngay bây giờ), và thật không may, cho đến nay, đó là một quy trình hoàn toàn thủ công - chúng tôi có một quy trình tự động gắn cờ mọi tệp có thể được sửa đổi như một phần của kiểm toán tự động ban đầu của chúng tôi một khách hàng hỗ trợ mới. Sau đó, chúng tôi có ai đó khác các tệp đó và loại trừ bất kỳ thông báo sai rõ ràng nào (nghĩa là thay đổi khoảng trắng).

Sau đó, phần thú vị - một thành viên cao cấp trong nhóm của chúng tôi đã làm việc với Magento trong một thời gian khá lâu phải xem kết quả để xác định xem có bất kỳ tệp sửa đổi nào có thể là kết quả của một bản vá hay không. Chúng tôi đã xem xét việc cập nhật hệ thống của chúng tôi để kiểm tra tất cả các bản vá mà chúng tôi biết / có thể xử lý và có thể hoạt động cho CE, nhưng trên EE, điều đó thậm chí còn khó khăn hơn, vì đôi khi hỗ trợ EE trực tiếp phát hành các bản vá cho các khách hàng không bao giờ được phát hành theo bất kỳ cách nào khác hoặc được phân loại theo cách nhất quán.

Vì vậy, khi chúng tôi thực hiện cấp đánh giá này, chúng tôi dựa vào kinh nghiệm trong quá khứ áp dụng các bản vá này + ý thức chung (nghĩa là nó chỉ là một thay đổi đối với điểm cuối của API? Nếu vậy, điểm cuối đó có thay đổi trong phiên bản cập nhật không? nó là một bản vá và có thể bỏ qua).

Về mặt lý thuyết sẽ đơn giản để áp dụng tất cả các bản vá có sẵn trên trang tải xuống CE, v.v., cho mọi phiên bản CE áp dụng và kiểm tra các phiên bản đó (FYI, chúng tôi không sử dụng diff cho lần đầu tiên - chúng tôi sử dụng băm, trong một phần vì chúng tôi đã xây dựng công nghệ này thành một công cụ có thể kiểm tra từ xa trên một trang web mà không cần tải xuống trước). Điều đó sẽ loại trừ phần lớn các bản vá, nhưng nó vẫn không giúp ích cho bất kỳ bản vá CE hoặc EE nào không được đăng lên khu vực tải xuống công khai cho CE hoặc khu vực tải xuống của máy khách / được bảo vệ cho EE. Điều đó sẽ yêu cầu Magento đưa ra một chính sách nhất quán rằng TẤT CẢ các bản vá được cung cấp cho TẤT CẢ khách hàng và đưa những thông tin đó đến nơi chúng tôi có thể đến với họ.

Vì vậy, tôi không nghĩ rằng có một cách để tự động hóa 100% điều này cho đến khi những thay đổi xảy ra ở phía Magento, thật không may.

Một cách mà tôi đã tiếp cận điều này khi tôi đang thực hiện nhiều nâng cấp và cố gắng hệ thống hóa quy trình là thực sự cam kết các bản vá trực tiếp vào kho lưu trữ mã lõi của bạn mà bạn đang sử dụng để chống lại.

Điều này thực sự có hai lợi ích:

1. Không có dương tính giả hiển thị trong khác biệt của bạn.

2. Giả sử bạn có một trang web không có bản vá nhất định. Bạn có thể nói đó là một vấn đề bởi vì nó sẽ hiển thị dưới dạng mã bị thiếu trong diff của bạn mặc dù về mặt kỹ thuật họ không thiếu bất cứ thứ gì so với một bản tải xuống chưa được vá mới. Nhưng trên thực tế, việc họ thiếu một bản vá thực sự là một vấn đề cần được giải quyết - vì vậy thật hoàn hảo khi nó xuất hiện trong diff của bạn để bạn khắc phục cùng với bản nâng cấp.

Tôi không nghĩ rằng có một Magento trong repo dự án của bạn là một ý tưởng tốt ban đầu, trong trường hợp nếu bạn quản lý nhiều hơn 2-3 khách hàng. Vì nó luôn dễ dàng hơn để làm rối các bản vá hệ thống được áp dụng với các bản hack lõi.

Theo tôi, tùy chọn tốt nhất là có một máy nhân bản kho lưu trữ Magento với các thẻ phiên bản, trỏ đến một phiên bản Magento cụ thể với các bản vá chính thức có thể được áp dụng.

Ngoài ra, sẽ dễ dàng hơn để duy trì các bản vá của riêng bạn cho các tệp, như Mage_Core_Model_Config cho các trang web được tải cao và một số trang khác, bằng cách giới thiệu phần cài đặt của chúng thông qua trình soạn thảo với số phiên bản phù hợp với phần cài đặt Magento của bạn.

Vì vậy, trong trường hợp này, việc bạn nâng cấp tất cả các dự án của khách hàng lên mã Magento đã vá sẽ chỉ dẫn đến phiên bản gập của tệp soạn thảo của bạn. Ngoài ra, giữ mã dự án ngoài lõi, sẽ buộc các nhà phát triển của bạn không hack lõi.

Đối với định nghĩa của bản vá và hack, tôi thích gọi nó như thế này:

1. Thay đổi tệp lõi ban đầu bằng tệp vá chính thức - đó là bản vá
2. Một thay đổi trong tập tin lõi ban đầu của nhóm của bạn - đó là một hack.
3. Một thay đổi trong tệp lõi sao chép cục bộ nhằm mục đích sửa lỗi - đó là một bản vá
4. Một thay đổi trong tệp lõi sao chép cục bộ để cung cấp chức năng mới - đó là một bản hack

Vì vậy, bằng cách di chuyển lõi sang một repo riêng, bạn sẽ đảm bảo rằng bạn chỉ có phiên bản vá theo mục 1. Và bạn có thể dễ dàng cài đặt các bản vá của riêng mình qua trình soạn thảo vào nhóm mã cục bộ, do đó bạn có mọi thứ theo điểm 3. Trong trường hợp 2 và 4 bạn có thể tạo một hook hook git trong repo dự án để cấm bất kỳ cam kết mã nào vào thư mục đó.

Tôi tìm đến tập tin bản vá được áp dụng trong /app/etc/thư mục đó và làm việc ngược lại. Nhưng khi tôi học được từ việc nâng cấp, tôi chỉ có thể xóa tệp trên một phiên bản có tệp được vá trong đó và lần sau nó được vá.

Bất cứ điều gì từ Magento tôi sẽ gọi một bản vá. Mọi thứ khác là một hack.