Tổng quan:

Câu hỏi này ban đầu được hỏi và sau đó được đóng lại trên StackOverflow . Chúng tôi đã tuyên bố trong meta , rằng đây là nơi thích hợp cho câu hỏi này.

Câu hỏi này được ủng hộ để giúp nhiều người tìm ra cách thích hợp để ước tính các bản nâng cấp Magento.

Câu hỏi:

Tôi muốn biết làm thế nào để bạn đo thời gian cần thiết để nâng cấp Magento? Tôi đoán rằng hầu hết các bạn đều gặp khó khăn khi trả lời câu hỏi của khách hàng: "Sẽ mất bao lâu để nâng cấp cửa hàng Magento của tôi?"

Thông thường khách hàng chỉ cần nghe một số ví dụ: "Sẽ mất X giờ và sẽ tốn Y đô la."

Ý tưởng chính đằng sau câu hỏi là về khía cạnh kỹ thuật và những gì bạn kiểm tra với tư cách là nhà phát triển để thực hiện các tính toán của riêng bạn để nâng cấp Magento.

Tôi đã tạo danh sách kiểm tra tiếp theo, chỉ để tính toán của riêng tôi:

• Là lõi Magento chạm?
• Là lược đồ Magento DB được chạm vào?
• Chúng ta có dữ liệu không nhất quán trong DB không?
• Có bao nhiêu tiện ích mở rộng tùy chỉnh được cài đặt trong nhóm mã địa phương và cộng đồng?
• Phần mở rộng tùy chỉnh có tương thích với phiên bản mới nhất của Magento không?
• Có phải nhà phát triển chủ đề đã sử dụng tệp local.xml cho các chỉ thị bố cục hoặc chỉ sao chép các tệp xml từ cơ sở / mặc định / bố cục vào thư mục bố cục của chủ đề tùy chỉnh?
• Chúng ta có các chỉ thị bố cục / phương thức chặn không dùng trong các tệp xml bố cục không?
• Tôi đã phát triển cửa hàng Magento này chưa?

Bạn có nghĩ rằng tôi đang thiếu một cái gì đó và nếu có, bạn có muốn chia sẻ với tôi và cộng đồng những điểm bổ sung của bạn cho danh sách kiểm tra không?

Ước tính nâng cấp Magento là một quá trình thu thập thông tin về các sửa đổi được áp dụng cho cài đặt mà bạn sắp cập nhật, kiểm tra xem các sửa đổi đó có thể gây ra sự cố không và sau đó đánh giá thời gian cần thiết để xử lý chúng.

Tất cả những thay đổi có thể được chia thành nghĩa đen off-core và trong lõi .

Sửa đổi ngoài lõi là những sửa đổi sẽ không được ghi đè bằng nâng cấp. Đó là các tiện ích mở rộng của bên thứ 3 , các tệp cốt lõi được đưa vào phạm vi cục bộ (ứng dụng / mã / cục bộ / Pháp sư) và một chủ đề tùy chỉnh .

Sửa đổi trong lõi được áp dụng trực tiếp trên các tệp lõi Magento (ứng dụng / mã / lõi), tệp bản địa hóa (app / locale / en_US), các mẫu lõi và một số thứ như javascripts , thư viện bên ngoài hiếm khi được tùy chỉnh. .

Sửa đổi ngoài lõi

Gia hạn bên thứ 3

Trong quá trình nâng cấp, tiện ích mở rộng của bên thứ 3 là nguồn chính của vấn đề. Điều đó có nghĩa là nhiều tiện ích mở rộng bạn có nhiều thời gian hơn bạn sẽ cần phân tích chúng.

Điều đầu tiên cần kiểm tra là nếu chức năng được cung cấp bởi tiện ích mở rộng chưa được triển khai trong phiên bản Magento mà bạn đang nâng cấp lên. Ví dụ: một số tiện ích mở rộng như Yoast_CanonicalUrl, Mxperts_CustomerAddresshoặc Fontis_Wysiwygđược sử dụng rộng rãi trong Magento 1.3.xx trở lên nhưng giờ đây là một phần của chức năng Magento cốt lõi và không còn cần thiết nữa.

Sau đó, nên kiểm tra (hỏi khách hàng của bạn) nếu bạn thực sự cần tất cả các tiện ích mở rộng mà bạn có. Có thể có một số tiện ích mở rộng bạn đã cài đặt nhưng chưa bao giờ thực sự được sử dụng. Vì vậy, tại thời điểm này là tốt để thực hiện một loại dọn dẹp.

Sau đó, một điều quan trọng cần kiểm tra là khả năng tương thích của từng tiện ích mở rộng còn lại với phiên bản Magento bạn đang nâng cấp lên. Trong trường hợp một số tiện ích mở rộng không tương thích và không có tiện ích mở rộng tương tự nào, bạn sẽ có một lựa chọn khó khăn là mất một số chức năng hoặc sửa đổi các tiện ích mở rộng hiện có để làm cho chúng tương thích.

Lưu ý: Không sửa đổi trực tiếp tiện ích mở rộng của bên thứ 3 mà tạo một tiện ích mở rộng mới sẽ mở rộng tiện ích mở rộng đã lỗi thời và sau đó đặt phụ thuộc vào XML bootstrap của tiện ích mở rộng mới.

Sau khi tất cả những người thực hiện phân tích thực tế của từng phần mở rộng còn lại có thể được cung cấp. Nó sẽ luôn luôn bắt đầu với việc kiểm tra các etc/config.xmltập tin. Có 3 điều cần tìm:

• Lớp viết lại không phải là một kỹ thuật sạch, nhưng trong một số trường hợp không có cách nào khác. Vì vậy, nếu lớp viết lại đã được thay đổi trong phiên bản mới của Magento thì đây có thể là một vấn đề tiềm năng.
• Các bản cập nhật bố cục sẽ ít có khả năng gây ra sự cố với bản nâng cấp của bạn, nhưng nếu phần mở rộng đang tham chiếu một khối không được dùng trong phiên bản Magento mới hơn, bạn sẽ phải làm việc này.
• Các bản cập nhật SQL là nguồn gây ra sự đánh giá thấp trong quá trình nâng cấp. Sự cố xảy ra khi tiện ích mở rộng của bên thứ 3 đang tạo khóa ngoại tham chiếu đến một số trường trong bảng Magento mặc định. Kết quả là lĩnh vực này bị khóa từ sửa đổi. Và sau đó nếu tập lệnh cài đặt gốc sẽ cố gắng cập nhật trường này, nó sẽ thất bại trong âm thầm. Sau đó, mỗi tập lệnh cài đặt tiếp theo tham chiếu đến trường này sẽ làm hỏng bản nâng cấp của bạn.

ứng dụng / mã / cục bộ / Pháp sư

Sau khi bạn hoàn thành các tiện ích mở rộng của mình, đã đến lúc xem app/code/local/Magethư mục của bạn . Ở đây bạn sẽ tìm thấy các tập tin cốt lõi sửa đổi được chuyển vào một localphạm vi. Mỗi người trong số họ chắc chắn sẽ trả cho bạn một số tóc bạc bởi vì bạn không bao giờ biết (nếu không phải là bạn đã đặt chúng ở đó) những gì đã được sửa đổi ở đó và vì lý do gì. Vì vậy, bạn phải so sánh từng trong số chúng với một nguồn gốc và di chuyển chức năng được thêm vào tệp tương ứng của phiên bản mới.

Chủ đề tùy chỉnh

Các sửa đổi off-core cuối cùng là chủ đề tùy chỉnh. Điều này có vẻ không phải là một vấn đề lớn nhưng thực tế đây là một khu vực màu xám. Chủ đề cơ sở Magento đang được sửa đổi từ phiên bản này sang phiên bản khác và mỗi chủ đề tùy chỉnh phải bắt chước một số sửa đổi đó. Thật không may, không có viên đạn bạc để xác định những gì cần tìm và những gì phải di chuyển. Vì vậy, chỉ cần chuẩn bị cho một số bất ngờ lớn và nitpicking nhỏ sau khi nâng cấp của bạn.

Sửa đổi trong lõi

Trong thế giới hoàn hảo không có ai. Nhưng khi bạn cài đặt Magento sau khi nó bị lạm dụng bởi các nhà phát triển bên thứ ba, những người đang cung cấp nhiều thứ với giá rẻ, bạn có thể mong đợi bất cứ điều gì. Vì vậy, sửa đổi trong lõi là những sửa đổi sẽ được ghi đè trong quá trình nâng cấp. Trong hầu hết các trường hợp, nó sẽ không tạo ra bất kỳ lỗi nào, nhưng kết quả là bạn sẽ mất chức năng được thêm vào theo cách tàn bạo như vậy.

Cách duy nhất để phát hiện các sửa đổi trong lõi là so sánh tất cả các tệp cài đặt Magento của bạn với các tệp sạch của cùng một phiên bản. Tôi khuyên bạn nên làm điều đó với git. Tại sao? Đơn giản vì nó sẽ xử lý tất cả các dòng mới và khoảng trắng độc đáo.

Ngay cả khi cài đặt Magento của bạn không dưới git, bạn vẫn có thể sao chép các tệp của mình vào một thư mục riêng và sau đó chạy git init. Sau đó thực hiện cam kết ban đầu, sao chép các tập tin Magento trong sạch và chạy git status. Bạn sẽ nhận được một cái gì đó như thế này:

Bây giờ tùy thuộc vào số lượng tệp sửa đổi, bạn có thể chạy git difftrên mỗi tệp hoặc trên toàn bộ lô cùng một lúc. Điều này sẽ cung cấp cho bạn một tài liệu tham khảo toàn diện về tất cả các sửa đổi trong lõi được thực hiện. Nếu bạn có bất kỳ trực quan git nào như phpStorm, cuộc sống sẽ dễ dàng hơn nhiều đối với bạn:

Tôi đề nghị làm git diff > changes.txtnhư vậy bạn sẽ luôn có một danh sách sửa đổi bằng tay.

Có danh sách các sửa đổi cốt lõi, bạn có thể ước tính những gì phải được chuyển sang phiên bản mới và cần bao nhiêu thời gian để làm điều đó.

Bây giờ tôi muốn đưa ra một số lời khuyên cho việc nâng cấp thực tế. Quá trình này được ghi lại tốt vì vậy tôi sẽ không viết những lệnh nào để chạy và nhấp vào đâu. Tuy nhiên tôi muốn làm điểm nhấn cho một số điều quan trọng:

• Chúng tôi giả định rằng bạn đang nâng cấp trong môi trường phát triển của mình. Chạy nâng cấp tại máy chủ sản xuất của bạn là một vụ tự sát.
• Đừng để họ thay đổi bất cứ điều gì trong sản xuất trong khi bạn đang nâng cấp. Đặt Magento của bạn dưới sự kiểm soát phiên bản hoặc thậm chí các tệp khóa tạm thời khỏi văn bản.
• Vô hiệu hóa tất cả các tiện ích mở rộng của bên thứ 3 nhưng lưu ý những tiện ích mở rộng nào ban đầu bị vô hiệu hóa để bạn không kích hoạt chúng sau đó.
• Kiểm tra xem có tập lệnh dọn dẹp Magento nào đang chạy trên máy chủ không. Nếu không cắt tất cả các bảng bắt đầu với dataflow_*, log_*, report_*.
• Hoàn nguyên về chủ đề mặc định về thời gian nâng cấp.

Sau khi hoàn thành nâng cấp tập lệnh:

• Tham khảo những changes.txtgì bạn đã thực hiện trước khi di chuyển tất cả các sửa đổi trong lõi thực sự đáng di chuyển.
• Di chuyển app/code/local/Magesửa đổi được tìm thấy trước khi nâng cấp.
• Từng người một cho phép mở rộng bên thứ 3.
• Đặt lại chủ đề của bạn và so sánh toàn diện kết quả với máy chủ sản xuất.
• Triển khai để sản xuất một khi bạn hài lòng với kết quả.

Phần kết luận

Tôi biết tất cả điều này nghe có vẻ đáng sợ nhưng nếu bạn nâng cấp thường xuyên, hãy giữ cho lõi của bạn sạch sẽ và chỉ cài đặt các tiện ích mở rộng từ các nhà cung cấp mà bạn thực sự tin tưởng và chỉ khi bạn thực sự cần chúng, bạn sẽ không phải đối mặt với hầu hết những khó khăn được mô tả trong bài viết này. Giữ cho Magento EcoSystem của bạn khỏe mạnh và bạn sẽ được thưởng.

Đoạn tái bút

Trong những trường hợp rất phức tạp, thật hợp lý khi bắt đầu lại với một bản cài đặt Magento mới nhất và di chuyển từng bước chủ đề và chức năng cửa hàng của bạn. Điều này chắc chắn sẽ mất thời gian nhưng cuối cùng bạn sẽ có một hệ thống Magento lành mạnh với nhận thức đầy đủ về những gì đang diễn ra.

Nói chung, mã Core không bao giờ được chạm vào trong khi phát triển. Có nhiều cơ chế trong Magento để cho phép bạn giải quyết mọi vấn đề, thậm chí là các lỗi nội bộ. Điều đó đang được nói, có những vấn đề khác để tìm là tốt.

1. Do bất kỳ mô-đun cộng đồng hoặc cục bộ nào ghi đè mã lõi (Có thể được tìm kiếm trong thư mục mô-đun <rewrite>và đó là một thực tế xấu vì họ thực sự nên sử dụng mã không gây khó chịu như các sự kiện)
2. Magento cố gắng giữ mã tương thích ngược, nhưng đôi khi mã thay đổi đáng kể ( Có thể tìm thấy ở đây ), nếu nhiều thay đổi không tương thích ngược là nhiều, điều đó có thể thêm vào quy trình.
3. Có dễ dàng / có thể sao chép mã vào môi trường phát triển không. nếu có, chỉ cần chạy nâng cấp và thử nghiệm có thể là tất cả những gì cần thiết.
4. Là nâng cấp cần thiết? Có các tính năng trong phiên bản mới mà khách hàng không thể rời khỏi? Bất kỳ vấn đề bảo mật nào (nhiều lần Magento cũng cung cấp bản vá lỗi)

Theo như mẫu có liên quan, từ kinh nghiệm trước đây tôi có thể nói với bạn rằng nó hầu như không bị phá vỡ, trừ khi nhà phát triển phát điên với mã hóa mẫu (Dù sao cũng phải ở trong các khối).

Dưới đây là một số điều cần lưu ý:

• Kiểm tra xem chủ đề có tương thích không (kiểm tra xem liệu có mã hóa rộng rãi trong các tệp mẫu không - đôi khi các nhà phát triển cơ sở thực hiện việc này)
• Kiểm tra phương tiện đang được lưu trữ (chúng có sử dụng CDN không, v.v.)
• Kiểm tra xem có phương pháp lưu trữ đặc biệt nào không (APC Memcached, v.v.)

Một cách để xử lý loại yêu cầu khách hàng này là thực hiện đánh giá ước tính.

Điều này đòi hỏi phải nói với khách hàng rằng bạn sẽ dành thời gian (có thể tính hóa đơn) để xem xét nó và sẽ cung cấp cho họ khung thời gian / chi phí chính xác hơn để thực hiện dự án.

Đi tuyến đường này có lợi cho cả bạn và khách hàng.

Khách hàng thường sẽ cảm thấy tin tưởng hơn vào ước tính của bạn và sẽ tôn trọng các đề xuất của bạn, điều này sẽ mang lại lợi ích cho bạn, bằng cách giảm căng thẳng có thể.

Đánh giá ước tính:

Đánh giá ước tính thực tế sẽ là một cái gì đó dọc theo những dòng này:

• Kết xuất cơ sở dữ liệu trực tiếp và nhập nó vào máy phát triển
• Sao chép các tập tin magento từ máy trực tiếp của họ vào máy dev của bạn
• Hãy chắc chắn rằng tất cả đều tốt và làm việc
• Thử nâng cấp và thực hiện một số thử nghiệm ban đầu để xem những gì có thể bị phá vỡ

Quá trình này sẽ mất trung bình hai giờ có thể lập hóa đơn và sẽ cung cấp cho bạn cái nhìn sâu sắc cần thiết về hệ thống trong tay.

Chúng tôi đã thực hiện nhiều nâng cấp khác nhau trên Magento CE, điều tồi tệ nhất là từ 1.3 đến 1.7, chúng tôi mất gần 4 ngày. Ước tính ban đầu là 1-2 ngày. Tôi đoán rằng việc nâng cấp từ 1.x lên 2.x sẽ là một công việc khổng lồ tương tự và ngay cả khi các công cụ di chuyển sẽ được cung cấp bởi nhóm nòng cốt, có thể sẽ dễ dàng hơn để bắt đầu lại từ đầu.

Tôi muốn thêm một điều vào các câu trả lời xuất sắc ở trên:

• Kiểm tra nếu một VCS và quy trình triển khai thích hợp được đưa ra.

Tôi sẽ không thực hiện nâng cấp nếu không có các quy trình phù hợp đằng sau nó và khả năng lùi lại khi có sự cố xảy ra (thậm chí nhiều hơn nếu tôi không làm việc trên trang web trước đó). Khoảng 90% khách hàng tiếp cận chúng tôi để nâng cấp Magento (trước đây chưa từng là khách hàng của chúng tôi) chỉ có môi trường sống mà không có bất kỳ thử nghiệm / dàn dựng nào, VCS dù thế nào đi nữa.

Tích hợp với các thực thể khác là một điều quan trọng để hỏi về. Đây là điều mà bạn có thể không thể phát hiện ra bằng cách xem trang web - ví dụ, khách hàng thường có các hệ thống back-end tìm nạp các đơn đặt hàng thông qua API Magento, và nếu bạn không xử lý sự liên tục của tích hợp đó trong khi nâng cấp cho bạn có thể vào một mớ hỗn độn.

Khi bạn đang xem xét các thành phần, hãy tìm những bộ phận nói chuyện với các hệ thống khác - mỗi bộ phận này sẽ có nhiều lông để kiểm tra vì bạn không muốn vô tình đẩy dữ liệu kiểm tra vào hệ thống trực tiếp. Thường có một điểm cuối thử nghiệm tồn tại được sử dụng bởi các nhà phát triển ban đầu, nhưng bạn có thể không có thông tin đó nữa khi nâng cấp.