Gambaran:

Pertanyaan ini awalnya ditanyakan dan kemudian ditutup pada StackOverflow . Kami menyatakan dalam meta , bahwa di sini adalah tempat yang tepat untuk pertanyaan ini.

Pertanyaan ini mendukung untuk membantu banyak orang menemukan cara yang tepat untuk memperkirakan peningkatan Magento.

Pertanyaan:

Saya tertarik untuk mengetahui bagaimana Anda mengukur waktu yang dibutuhkan untuk peningkatan Magento? Saya kira, sebagian besar dari Anda kesulitan menjawab pertanyaan klien: "Berapa lama waktu yang diperlukan untuk meningkatkan toko Magento saya?"

Biasanya klien hanya perlu mendengar angka misalnya: "Ini akan memakan waktu X jam dan itu akan menghabiskan biaya Y."

Gagasan utama di balik pertanyaan ini adalah tentang sisi teknis dan apa yang Anda periksa sebagai pengembang untuk membuat perhitungan Anda sendiri untuk peningkatan Magento.

Saya membuat daftar periksa berikutnya, hanya untuk perhitungan saya sendiri:

• Apakah inti Magento tersentuh?
• Apakah skema DB Magento tersentuh?
• Apakah kita memiliki data yang tidak konsisten dalam DB?
• Berapa banyak ekstensi khusus yang dipasang di kumpulan kode lokal dan komunitas?
• Apakah ekstensi khusus kompatibel dengan Magento versi terbaru?
• Apakah pengembang tema menggunakan file local.xml untuk arahan tata letak, atau hanya menyalin file xml dari basis / default / tata letak ke direktori tata letak tema khusus?
• Apakah kita memiliki arahan tata letak / metode blok usang dalam file tata letak xml?
• Sudahkah saya mengembangkan toko Magento ini?

Apakah Anda pikir, bahwa saya kehilangan sesuatu dan jika ya, apakah Anda ingin berbagi dengan saya dan komunitas poin tambahan Anda untuk daftar periksa?

Memperkirakan peningkatan Magento adalah proses mengumpulkan informasi tentang modifikasi yang diterapkan pada instalasi yang akan Anda perbarui, memeriksa apakah modifikasi itu dapat menyebabkan masalah dan kemudian mengevaluasi berapa banyak waktu yang diperlukan untuk mengatasinya.

Semua modifikasi dapat secara harfiah dibagi menjadi off-core dan in-core .

Modifikasi off-core adalah yang tidak akan ditimpa dengan peningkatan. Itu adalah ekstensi pihak ke-3 , file inti yang dimasukkan ke dalam cakupan lokal (app / code / local / Mage) dan tema khusus .

Modifikasi dalam-inti diterapkan langsung pada file inti Magento (app / code / core), file pelokalan (app / locale / en_US), templat inti dan beberapa hal seperti javascripts , perpustakaan eksternal yang jarang dikustomisasi namun harus dipertimbangkan. .

Modifikasi Off-Core

Ekstensi Pihak Ketiga

Selama peningkatan, ekstensi pihak ketiga adalah sumber utama masalah. Yang berarti lebih banyak ekstensi, Anda memiliki lebih banyak waktu, Anda perlu menganalisisnya.

Hal pertama yang harus diperiksa adalah apakah fungsionalitas yang disediakan oleh ekstensi belum diimplementasikan dalam versi Magento yang sedang Anda tingkatkan. Misalnya beberapa ekstensi suka Yoast_CanonicalUrl, Mxperts_CustomerAddressatau Fontis_Wysiwygbanyak digunakan di Magento 1.3.xx dan lebih lama tetapi sekarang merupakan bagian dari fungsi inti Magento dan tidak lagi diperlukan.

Maka itu ide yang baik untuk memeriksa (meminta pelanggan Anda) jika Anda benar-benar membutuhkan semua ekstensi yang Anda miliki. Mungkin ada beberapa ekstensi yang Anda instal tetapi tidak pernah benar-benar digunakan. Jadi pada titik ini ada baiknya melakukan semacam pembersihan.

Maka hal yang penting untuk diperiksa adalah kompatibilitas masing-masing ekstensi yang tersisa dengan versi Magento yang sedang Anda tingkatkan. Jika beberapa ekstensi tidak kompatibel dan tidak ada ekstensi serupa yang tersedia, Anda akan memiliki pilihan yang sulit baik kehilangan beberapa fungsi atau memodifikasi ekstensi yang ada untuk membuatnya kompatibel.

Catatan: Jangan memodifikasi ekstensi pihak ke-3 secara langsung tetapi buat ekstensi baru yang akan memperpanjang yang sudah usang dan kemudian atur ketergantungan pada bootstrap XML dari ekstensi baru.

Setelah semua yang dilakukan analisis sebenarnya dari masing-masing ekstensi yang tersisa dapat disediakan. Itu akan selalu dimulai dengan pemeriksaan etc/config.xmlfile. Ada 3 hal yang harus dicari:

• Penulisan ulang kelas bukanlah teknik yang bersih dengan sendirinya tetapi dalam beberapa kasus tidak ada jalan lain. Jadi, jika kelas yang ditulis ulang diubah dalam versi baru Magento, ini bisa menjadi masalah potensial.
• Pembaruan tata letak kemungkinan besar tidak akan menyebabkan masalah dengan peningkatan Anda tetapi masih jika ekstensi mereferensikan blok yang sudah usang dalam versi Magento yang lebih baru, Anda harus menyelesaikannya.
• Pembaruan SQL adalah sumber masalah yang sangat diremehkan selama peningkatan. Masalah terjadi ketika ekstensi pihak ketiga membuat kunci asing referensi ke beberapa bidang di tabel Magento default. Akibatnya bidang ini dikunci dari modifikasi. Dan kemudian jika skrip instal asli akan mencoba memperbarui bidang ini, maka akan gagal secara diam-diam. Setelah itu, setiap skrip pemasangan berikutnya yang merujuk ke bidang ini akan merusak pemutakhiran Anda.

app / code / local / Mage

Setelah Anda selesai dengan ekstensi, inilah saatnya untuk melihat app/code/local/Magedirektori Anda . Di sini Anda akan menemukan file inti yang dimodifikasi dipindahkan ke locallingkup. Masing-masing dari mereka pasti akan dikenakan biaya beberapa uban karena Anda tidak pernah tahu (jika bukan Anda yang meletakkannya di sana) apa yang dimodifikasi di sana dan untuk alasan apa. Jadi, Anda harus membandingkan masing-masing dengan sumber dan memigrasikan fungsionalitas yang ditambahkan ke file koresponden versi baru.

Tema Khusus

Modifikasi banyak off-core terakhir adalah tema khusus. Ini mungkin tampaknya bukan masalah besar tetapi sebenarnya ini adalah wilayah abu-abu. Tema dasar Magento sedang dimodifikasi dari versi ke versi dan setiap tema khusus harus meniru beberapa modifikasi tersebut. Sayangnya tidak ada peluru perak untuk menentukan apa yang harus dicari dan apa yang harus dimigrasi. Jadi bersiaplah untuk beberapa kejutan besar dan nitpicking kecil setelah peningkatan Anda.

Modifikasi In-Core

Di dunia yang sempurna tidak ada. Tetapi ketika Anda mendapatkan instalasi Magento setelah disalahgunakan oleh pengembang pihak ketiga, yang menawarkan banyak untuk murah Anda bisa mengharapkan apa saja. Jadi modifikasi in-core adalah mereka yang akan ditimpa selama proses peningkatan. Dalam kebanyakan kasus itu tidak akan menghasilkan kesalahan tetapi sebagai akibatnya Anda akan kehilangan fungsionalitas yang ditambahkan dengan cara yang brutal.

Satu-satunya cara untuk mendeteksi modifikasi dalam inti adalah membandingkan semua file instalasi Magento Anda dengan file bersih dari versi yang sama. Saya sarankan melakukannya dengan git. Mengapa? Hanya karena itu akan menangani semua baris baru dan spasi putih dengan baik.

Walaupun instalasi Magento Anda tidak di bawah git, Anda masih dapat menyalin file ke direktori terpisah dan kemudian menjalankan git init. Kemudian buat komit awal, salin file Magento "bersih" dan jalankan git status. Anda akan mendapatkan sesuatu seperti ini:

Sekarang tergantung pada jumlah file yang dimodifikasi, Anda dapat menjalankan git diffpada setiap file atau pada keseluruhan batch sekaligus. Ini akan memberi Anda referensi komprehensif dari semua modifikasi in-core yang dibuat. Jika Anda memiliki visualisasi git seperti phpStorm, hidup ini jauh lebih mudah bagi Anda:

Saya menyarankan git diff > changes.txtagar Anda selalu memiliki daftar modifikasi dengan tangan.

Dengan memiliki daftar modifikasi inti, Anda dapat memperkirakan apa yang harus ditransfer ke versi baru dan berapa banyak waktu yang diperlukan untuk melakukannya.

Sekarang saya ingin memberikan beberapa saran untuk peningkatan yang sebenarnya. Proses ini didokumentasikan dengan baik sehingga saya tidak akan menulis perintah apa yang harus dijalankan dan ke mana harus mengklik. Namun saya ingin memberi aksen pada beberapa hal penting:

• Kami mengasumsikan bahwa Anda meningkatkan di lingkungan pengembangan Anda. Menjalankan peningkatan di server produksi Anda adalah bunuh diri.
• Jangan biarkan mereka mengubah apa pun dalam produksi saat Anda meningkatkan. Letakkan Magento Anda di bawah kontrol versi atau bahkan file kunci sementara dari penulisan.
• Nonaktifkan semua ekstensi pihak ketiga tetapi perhatikan mana yang awalnya dinonaktifkan sehingga Anda tidak akan mengaktifkannya setelah itu.
• Periksa apakah ada skrip pembersihan Magento yang berjalan di server. Jika tidak memotong semua tabel dimulai dengan dataflow_*, log_*, report_*.
• Kembalikan ke tema default pada waktu peningkatan.

Setelah skrip pemutakhiran selesai:

• Merujuk changes.txtAnda yang dibuat sebelum memigrasi semua modifikasi inti yang benar-benar layak dimigrasi.
• Migrasikan app/code/local/Magemodifikasi yang ditemukan sebelum meningkatkan.
• Satu per satu mengaktifkan ekstensi pihak ke-3.
• Pasang kembali tema Anda dan bandingkan hasilnya dengan server produksi secara komprehensif.
• Sebarkan ke produksi setelah Anda puas dengan hasilnya.

Kesimpulan

Saya tahu ini semua terdengar menakutkan tetapi jika Anda meningkatkan secara teratur, menjaga inti Anda tetap bersih dan menginstal ekstensi hanya dari vendor yang benar-benar Anda percayai dan hanya jika Anda benar-benar membutuhkannya, Anda tidak akan menghadapi sebagian besar kesulitan yang dijelaskan dalam artikel ini. Jadikan Magento EcoSystem Anda sehat dan Anda akan diberi hadiah.

Skrip Posting

Dalam kasus yang sangat rumit, masuk akal untuk memulai dari awal dengan pemasangan baru Magento terbaru dan memigrasikan tema dan fungsi toko Anda langkah demi langkah. Ini pasti akan memakan waktu tetapi pada akhirnya Anda akan memiliki sistem Magento yang sehat dengan kesadaran penuh Anda tentang apa yang sedang terjadi.

Secara umum, kode Core tidak boleh disentuh saat dikembangkan. Ada banyak mekanisme di Magento untuk memungkinkan Anda mengatasi masalah apa pun, bahkan bug internal. Yang sedang berkata, ada masalah lain yang harus diwaspadai juga.

1. Apakah modul komunitas atau lokal menimpa kode inti (Dapat dicari dalam folder modul untuk <rewrite>, dan itu adalah praktik yang buruk karena mereka benar-benar harus menggunakan kode yang tidak mencolok seperti acara)
2. Magento mencoba untuk menjaga kode yang kompatibel ke belakang, tetapi kadang-kadang kode itu berubah secara signifikan ( Dapat ditemukan di sini ), jika perubahan mundur yang tidak kompatibel banyak, yang dapat menambah proses.
3. Apakah mudah / mungkin untuk menggandakan kode ke lingkungan pengembangan. jika ya, cukup jalankan pemutakhiran dan pengujian yang mungkin diperlukan.
4. Apakah perlu upgrade? Apakah ada fitur di versi baru yang tidak bisa ditinggalkan klien? Masalah keamanan apa pun (berkali-kali Magento menyediakan back-patch juga)

Sejauh menyangkut template, dari pengalaman sebelumnya saya dapat memberitahu Anda bahwa itu hampir tidak rusak, kecuali pengembang menjadi gila pada template coding (Yang harus di blok lagi pula).

Berikut beberapa hal yang perlu diingat:

• Periksa apakah tema kompatibel (periksa untuk melihat apakah ada pengkodean luas dalam file templat - terkadang pengembang junior melakukan ini)
• Periksa bagaimana media disimpan (apakah mereka menggunakan CDN, dll.)
• Periksa apakah ada metode caching khusus di tempat (APC Memcached dll)

Salah satu cara untuk menangani permintaan klien jenis ini, adalah dengan melakukan tinjauan perkiraan.

Ini berarti memberi tahu klien bahwa Anda akan menghabiskan waktu (yang dapat ditagih) untuk melihatnya, dan akan memberi mereka kerangka waktu / biaya yang lebih akurat untuk melakukan proyek tersebut.

Melewati rute ini menguntungkan Anda dan klien.

Klien biasanya akan merasa lebih percaya diri dalam perkiraan Anda, dan akan menghormati rekomendasi Anda, yang pada gilirannya menguntungkan Anda, dengan mengurangi kemungkinan stres.

Perkirakan ulasan:

Ulasan estimasi aktual akan menjadi sesuatu seperti ini:

• Buang database hidup dan impor pada mesin pengembangan
• Salin file magento dari mesin live mereka ke mesin dev Anda
• Pastikan semuanya baik-baik saja dan berfungsi
• Coba upgrade dan lakukan beberapa pengujian awal untuk melihat apa yang mungkin melanggar

Proses ini seharusnya memakan waktu rata-rata dua jam yang dapat ditagih, dan akan memberi Anda banyak wawasan yang diperlukan tentang sistem yang ada.

Kami telah melakukan berbagai peningkatan pada Magento CE, yang terburuk dari 1,3 menjadi 1,7 yang membawa kami hampir 4 hari penuh. Estimasi awal adalah 1-2 hari. Saya kira meningkatkan dari 1.x ke 2.x akan menjadi pekerjaan yang sangat besar dan bahkan jika alat migrasi akan disediakan oleh tim inti, mungkin lebih bersih untuk memulai dari awal.

Saya ingin menambahkan satu hal ke jawaban luar biasa yang diberikan di atas:

• Periksa apakah VCS dan proses penyebaran yang tepat sudah ada.

Saya tidak akan melakukan upgrade tanpa proses yang benar di belakangnya dan kemungkinan untuk mundur ketika masalah terjadi (bahkan lebih jika saya tidak bekerja di situs sebelumnya). Sekitar 90% klien yang mendekati kami untuk peningkatan Magento (yang belum pernah menjadi klien kami sebelumnya) hanya memiliki lingkungan hidup tanpa pengujian / pementasan, VCS apa pun yang ada.

Integrasi dengan entitas lain adalah hal penting untuk ditanyakan. Ini adalah sesuatu yang Anda mungkin tidak dapat melihatnya dengan melihat situs - contohnya adalah umum bagi klien untuk memiliki sistem back-end mengambil pesanan melalui Magento API, misalnya, dan jika Anda tidak menangani kontinuitas integrasi tersebut saat meningkatkan Anda bisa menjadi berantakan.

Saat Anda meninjau komponen, cari komponen yang berbicara dengan sistem lain - masing-masing komponen ini akan berbulu untuk diuji karena Anda tidak ingin secara tidak sengaja mendorong data pengujian ke sistem langsung. Seringkali ada titik akhir pengujian yang digunakan oleh pengembang asli, tetapi Anda mungkin tidak memiliki informasi itu lagi ketika meningkatkan.