Apa strategi penyebaran terbaik?

82

Menyiapkan toko Magento tidak hanya masalah mengembangkan ekstensi yang dapat dipasang sendiri tetapi juga membutuhkan banyak "entri manual" operasi seperti membuat atribut pengeditan akhir, kategori, produk, aturan harga halaman CMS dan sebagainya, belum lagi semua perubahan pada Konfigurasi Sistem.

Saya ingin bantuan Anda untuk menguraikan strategi terbaik ketika datang untuk menyebarkan toko Magento dari pengembangan ke lingkungan pementasan dan produksi.

Salah satu strategi saya adalah menulis "deploy module" yang secara terprogram menciptakan entitas yang disebutkan di atas, tetapi itu adalah tugas yang sangat memakan waktu dan kadang-kadang tampaknya bagi saya sedikit berlebihan.

Baru-baru ini saya mulai menggunakan Selenium IDE untuk mereproduksi tugas-tugas Admin tetapi waktu yang diperlukan untuk mengatur semua suite tes tidak jauh dari yang disebutkan di atas.

Mungkin solusi optimal dapat berupa penggunaan modul yang mampu melakukan snapshot dari Sistem Magento sehingga Anda dapat memilih apa yang akan digunakan.

Begitu:

  • apa strategi Anda untuk digunakan?
  • apakah ada modul yang mampu melakukan snapshot dari Sistem Magento sehingga Anda dapat memilih apa yang akan digunakan?
  • jika modul semacam itu tidak ada dan asalkan modul tersebut merupakan solusi yang masuk akal, adakah yang tertarik untuk berkontribusi dalam pengembangannya?

Terima kasih!

deploy admin entities Alessandro Ronchi
sumber
Ini mungkin menunjukkan perlunya tag lain atau kategori tag. Apakah Anda satu kali berbelanja atau sedang mencari saran umum sebagai penyedia layanan? Jika yang terakhir, jawaban apa pun harus dibumbui dengan "tergantung pada seberapa banyak kontrol klien inginkan atas data entitas".
Tanda
Pandangan saya adalah salah satu pengembang milik tim pengembang. Misalkan saya sedang mengembangkan bagian yang memerlukan beberapa data berfungsi, katakanlah struktur kategori. Saya membuat struktur melalui Admin, melakukan kode dan mendorong kode saya. Saya bertanya-tanya apakah strategi terbaik adalah juga menulis dan mendorong kode yang menciptakan struktur kategori yang diperlukan. Bagaimana jika struktur atau pengaturan kategori saya bertentangan dengan yang dibuat oleh pengembang lain yang mendorongnya sendiri? Bagaimana cara saya menangani konflik? Itu maksudku.
Alessandro Ronchi
@AlessandroRonchi Ini adalah poin yang bisa diperdebatkan, dan konflik yang seharusnya tidak pernah terjadi. Struktur kategori Anda bukanlah sesuatu yang harus berubah secara sembrono, sehingga satu pengembang tidak boleh mendorong perubahan besar pada struktur Anda, tanpa yang lain mengetahuinya. Jika ini terjadi, Anda perlu mengatasi komunikasi antar-dev Anda. Secara umum struktur kategori untuk suatu situs perlu dijabarkan dari hari pertama, dan tidak perlu diubah lagi, cukup ditambahkan. Jika Anda perlu mengubahnya, Anda tidak melakukannya dengan benar saat pertama kali.
ProxiBlue
@dedmeet sayangnya, di dunia yang saya kenal dan bekerja, segalanya berubah setiap hari; pelanggan berubah pikiran, pengembang berubah pikiran, angsa hitam terjadi. Saya harus siap dengan perubahan; Lagi pula, bahkan jika struktur kategori tidak perlu diubah sejak hari pertama, itu hanya sebagian kecil dari seluruh bagian dan seluruh bagian adalah proyek "pekerjaan yang sedang berjalan" yang seharusnya berubah untuk menyelesaikan sesuatu.
Alessandro Ronchi
ok, memang, kami bekerja di lingkungan yang selalu berubah, tapi saya tetap berpendapat bahwa konflik struktur kategori tidak boleh terjadi. Beberapa cabang seharusnya tidak ada di mana masing-masing mengubah struktur, yang hanya akan menyebabkan masalah, dan buang waktu dev. Mengapa dev menghabiskan waktu membuat perubahan struktur, sementara dev b melakukan hal yang sama, ke struktur yang berbeda, dan mereka berdua mendorong pekerjaan mereka? Jika struktur harus berubah, semua pengembang yang terlibat dalam proyek harus terlibat dalam proses pelingkupan struktur baru. Bisakah Anda memberikan contoh untuk membantu saya memahami kapan ini bisa terjadi?
ProxiBlue

Jawaban:

39

Pendapat saya adalah untuk menuliskan semuanya. Saya biasanya memiliki modul konfigurasi dasar untuk apa pun yang tidak terkait langsung dengan modul tertentu secara fungsional. (contoh membuat url kustom penulisan ulang untuk url situs sebelumnya ke url situs baru) dan menambahkan apa pun yang terkait dengan modul ke skrip instal sendiri.

Pola pikir di balik ini adalah bahwa jika situs perlu diinstal ulang, menggunakan db segar, maka semuanya kembali seperti semula. Ini juga membantu dalam kenyataan bahwa saya secara berkala memperbarui situs uat dengan salinan live db. Modul-modul di uat kemudian terus bekerja ketika mereka memasukkan konfigurasi mereka lagi.

Perubahan pada ongkos kirim, aturan keranjang, dll. (Pada dasarnya hal-hal yang dikelola sendiri oleh admin di admin) dianggap sebagai 'data volatil' dan tidak ditulis dalam skrip. Ini termasuk data produk. Klien memiliki opsi, dan didorong untuk menguji impor baru di situs uat terlebih dahulu.

Klien diberitahu untuk tidak membuat atribut, tetapi membuatnya dibuat melalui permintaan tiket. Ini kemudian memungkinkan saya untuk juga mengumpulkan informasi tentang maksud klien untuk atribut tersebut, dan kadang-kadang saya memiliki saran yang lebih baik, atau dapat membuat kode yang lebih baik karena saya memiliki pegangan tentang atribut apa yang ada, ditambah pada atribut yang dapat dipilih, memastikan data tersebut bersih.

Ya, scripting membutuhkan waktu lebih lama, tetapi akan membutuhkan waktu lebih lama untuk membuat ulang seluruh pengaturan konfigurasi situs secara manual nanti. Ini juga bisa memalukan jika Anda melupakan sesuatu dan menyebabkan situs tidak berfungsi dengan baik, atau memiliki pengembang baru yang bekerja di situs lokal yang tidak memiliki beberapa konfigurasi konfigurasi penting.

ProxiBlue
sumber
1
Saya setuju dengan dedmeet. Saat Anda pertama kali mempelajari cara membuat skrip semua pembaruan, ini mungkin merupakan pekerjaan awal tetapi jika Anda harus menerapkan pembaruan konfigurasi secara manual untuk 3-4 pengembang, pementasan, uat dan langsung, koordinasi dan pekerjaan aktual akan memakan waktu lebih lama. Alur kerja kami sangat mirip: jika konfigurasi diperlukan untuk ekstensi (dapat digunakan kembali), letakkan di sana. Jika konfigurasi khusus untuk klien, masukkan ke ekstensi khusus proyek. Salah satu dari sedikit pengecualian adalah aturan keranjang yang tidak menyenangkan untuk diperbarui / dibuat sama sekali.
Matthias Zeis
1
Saya baru saja merilis modul yang membantu membuat skrip konfigurasi yang diperlukan, sehingga menghilangkan pekerjaan biasa karena harus secara manual membuat skrip instalasi. Modul ini menggunakan tampilan grid dari tabel core_config_data untuk memungkinkan pemilihan nilai konfigurasi untuk diekspor. Jadikan hidup saya sedikit lebih sederhana, dan saya harap ini akan berhasil untuk orang lain. proxiblue.com.au/blog/magento-config-data-generator
ProxiBlue
27

Saya telah melakukan beberapa penelitian beberapa bulan yang lalu. Inilah situs yang bisa Anda referensikan.

URL Magento Base dan instalasi dev / staging
Magento Pengembangan dan Penempatan
Panduan Magento Git dan Alur Kerja
Pembuangan Lebih Cepat dari Magento Database MySQL untuk Percabangan

Oğuz Çelikdemir
sumber
1
Terima kasih, saya akan membaca semuanya dan kembali dengan beberapa pertimbangan.
Alessandro Ronchi
Saya telah membaca semua sumber informasi; Saya sudah kenal beberapa dari mereka, yang lain saya tidak tahu sangat menarik. Tak satu pun dari mereka, yang merupakan solusi untuk masalah saya dan saya telah memutuskan untuk membuat sketsa ekstensi yang akan mencoba memenuhi kebutuhan saya. Terima kasih kepada Anda semua yang memberi saya nasihat berharga. Saya berharap untuk kembali ke sini dengan beberapa hasil.
Alessandro Ronchi
Dear Alessandro, aku ingin melihat caramu yang aku cari teknik yang lebih nyaman juga!
Oğuz Çelikdemir
18

Saya ingin mengucapkan terima kasih kepada Anda semua karena pertimbangan Anda telah mengilhami dan mendorong saya untuk mengembangkan ekstensi, yang disebut "Mageploy" dengan maksud untuk memecahkan masalah menjaga lingkungan yang berbeda dalam sinkronisasi.

http://www.mageploy.com

Mageploy masih harus diperpanjang, didokumentasikan dengan baik dan sepenuhnya diuji bahkan jika saya sudah menggunakannya dalam beberapa proyek yang memiliki beberapa manfaat.

Ini open source dan bantuan atau saran apa pun akan dihargai.

Salam

Alessandro Ronchi
sumber
7

Sehubungan dengan menginstal skrip dan membuat entitas, perasaan umum saya adalah bahwa jika diperlukan atau diharapkan oleh modul, itu harus dibuat sebagai bagian dari skrip instalasi.

Baru-baru ini, dalam hal dev / stage / produksi, kami menggunakan situs pementasan sebagai salinan utama dari database untuk konten karena itu berarti bahwa klien dapat berkolaborasi. Di masa lalu, mungkin masalah terbesar yang kami temui adalah mengoordinasikan entri konten dengan klien, terutama yang berkaitan dengan pengunggahan produk.

Bagaimana menurut Anda foto itu akan berfungsi? Saya pikir di dunia yang ideal, Anda akan memiliki alat yang menunjukkan perbedaan antara dua database pada jenis tertentu (produk, kategori, CMS dll) dan memungkinkan Anda untuk menggabungkan perubahan menjadi satu sama lain, tetapi saya tidak mengetahui apa pun yang tersedia seperti bahwa.

Paul
sumber
1
"Sehubungan dengan menginstal skrip dan membuat entitas, perasaan umum saya adalah bahwa jika itu diperlukan atau diharapkan oleh modul, itu harus dibuat sebagai bagian dari skrip instalasi." Ini adalah titik paling penting untuk dipertimbangkan, dan berlaku untuk pengaturan konfigurasi. Tes cepat saya: ketika saya membutuhkan dev baru untuk mengkloning repo dan menginstal lingkungan, apa yang perlu ada agar sistem berfungsi?
tanda
Berbagi situs pementasan dengan klien untuk berkolaborasi dalam konfigurasi sangat bagus secara teori. Dalam praktiknya, klien tidak memberi tahu Anda segala sesuatu yang mereka ubah 99% dari waktu yang membuatnya mudah untuk mengacaukan sesuatu. Kami mungkin mengizinkan klien untuk mengerjakan hal-hal seperti aturan keranjang, kategori, produk, atau sejenisnya tetapi kami tidak membiarkan mereka mengganggu konfigurasi.
Matthias Zeis
6

Menurut pendapat saya membuat dan mengedit atribut, kategori, produk, aturan harga tidak ada hubungannya dengan "strategi penyebaran" Semua item ini cukup unik untuk sebuah toko, dan dalam kebanyakan kasus menuntut sedikit analisis dan penelitian yang tepat dari produk yang Anda akan menjual.

Jika Anda membuat toko "satu ukuran cocok untuk semua" dengan konfigurasi yang sama dari semua elemen yang Anda sebutkan, Anda bisa melakukan ekspor "snapshot" dari database Anda setelah Anda melakukan semua pengaturan yang Anda butuhkan untuk setiap toko.

Rutger
sumber
Tidak, "satu ukuran cocok untuk semua" bukan itu intinya; ini adalah situasi yang sama dengan kita, sebagai pengembang, ketika saatnya untuk menggabungkan kode sumber kami dengan salah satu anggota tim pengembang lainnya: dalam hal ini kami memiliki sistem kontrol sumber yang melakukan keajaiban. Pertanyaan saya lebih terkait dengan peluang menggabungkan "non dev" hal-hal seperti pengaturan konfigurasi dan pengaturan dan entri admin yang khas.
Alessandro Ronchi
Ah ok, Itu membuatnya lebih jelas
Rutger
Katakanlah kita membuat situs web baru yang lengkap, jadi tidak ada masalah dengan data lama dll. Hampir sepanjang waktu semua pengembang kita menggunakan database yang sama untuk pengembangan. Itu memecahkan banyak masalah. Untuk kasus lain saya tidak punya solusi yang lebih baik (belum) daripada menulis semua langkah yang diperlukan dalam semacam peta jalan / skrip dan mendaftar ulang semuanya setelah bergabung. Jika hanya satu orang yang bertanggung jawab atas pengaturan admin "magento core" ini seharusnya tidak banyak langkah. Saya pernah menemukan ini, tetapi belum pernah mencobanya tinybrick.com/magento-modules/admin-tools/…
Rutger
2

Saya ingin menambahkan dua alat penghemat waktu yang sangat baik:

  • Untuk pengembangan: PhpStorm IDE dengan plugin Magicento
  • Untuk penyebaran: Magentify , resep Capistrano untuk Magento
osondoar
sumber
Terima kasih telah memberi tahu kami tentang Magentify, saya tidak mengetahuinya dan saya akan mencobanya. Fokus saya, meskipun, lebih pada sinkronisasi lingkungan pengembangan yang berbeda daripada penyebaran dalam arti menerbitkan basis kode. Mageploy dapat diintegrasikan dengan Magentify tetapi merupakan alat yang berbeda, yang digunakan untuk secara otomatis menjaga sebagian dari perubahan basis data selaras terlepas dari ID tertentu yang berbeda antara lingkungan yang berbeda. Hormat kami, Alessandro
Alessandro Ronchi