Beberapa modul memiliki rutinitas instalasi. Yang biasanya menghapus tabel data untuk modul itu, variabel dari tabel variabel dan lokal yang diperkenalkan oleh modul itu. Rutinitas ini hidup dalam .installmodul itu.
Oleh karena itu, mereka tidak dapat dijalankan tanpa modul itu ada. Jadi, inilah langkah kita saat ini. Pertanyaan saya adalah: dapatkah ini dilakukan dengan lebih sederhana dan lebih efektif? Katakanlah saya menghapus modul foo_bar.
- Di RCS, siapkan rilis baru, di mana:
- Semua css dan theme-override yang menggunakan atau membangun di atas of foo_bar dihapus.
- Semua css dan theme-override untuk modul tergantung pada foo_bar dihapus.
- Dorong rilis itu ke penerimaan. Uji deinstalasi (dari admin / modul) dengan salinan terbaru dari basis data produksi.
- Jika semuanya berjalan dengan baik, gunakan basis kode baru untuk produksi, dan deïnstall foo_bar dan dependensinya di sana. Ini akan memanggil uninstall di berbagai modul, membersihkan database.
- Di RCS (git), siapkan rilis baru di mana kode sebenarnya dihapus.
- Sebarkan itu ke penerimaan tempat kami menguji jika tidak ada yang secara tidak sengaja bergantung pada ini (beberapa modul jelek atau fungsi tema menyertakan file langsung dari modul lain. Terutama CSS, JS atau file gambar).
- Jika diterima, gunakan rilis baru untuk produksi. produksi sekarang memiliki basis data yang bersih dan basis kode yang bersih .
Masalah yang tidak bisa saya pecahkan, apakah ini selalu membutuhkan dua rilis. Karena dalam Drupal, rilis mengharuskan situs offline, ini berarti dua kali downtime hanya untuk menghapus satu modul. Ini juga memerlukan dua prosedur rilis, yang, dalam lingkungan hosting profesional bisa sangat mahal, memakan waktu atau membuat frustrasi.
Jika kita menghapus modul dari basis kode di iterasi pertama, kita tidak bisa menjalankan kait instalan, menyimpan banyak serat dalam basis data; bukan hanya beberapa tabel, tetapi kebanyakan variabel dan lokal. Jika kita tidak menghapus modul dari basis kode, itu berarti basis kode akan tumbuh dengan basi, kode yang tidak digunakan; ini tidak memberikan kinerja overhead, tetapi membuat pemeliharaan kode semakin sulit.
Bagaimana Anda menangani ini?
[sunting: catatan tambahan tentang penyebaran menjadi prosedur yang sulit, sering kali]
sumber
Jawaban:
Berhati-hatilah dalam menjaga sinkronisasi database dan kode Anda; seperti yang Anda sebutkan dalam pertanyaan Anda, modul-modul yang akan dihapus perlu tetap berada di basis kode sampai kait-kait instalannya dijalankan pada database langsung. Ini adalah batasan Drupal bahwa alur kerja git pull saja tidak akan menyelesaikannya.
Saya akan merekomendasikan bahwa alih-alih mencoba menyesuaikan proses Anda, Anda malah mencari cara untuk mengurangi waktu henti yang diperlukan untuk memproses pembaruan Anda. Saya akan merekomendasikan pengaturan lingkungan pementasan multisite ying / yang untuk menyelesaikan masalah ini. nb Saya belum menggunakan skrip yang terkandung dalam tautan sebelumnya; Anda mungkin ingin mengatur berbagai hal secara berbeda, mengikuti gagasan yang sama dengan Anda dapat menukar situs langsung dan panggung Anda selama pemasangan.
Lanjutkan untuk mengikuti prosedur yang sama yang Anda uraikan dalam pertanyaan Anda dengan penyesuaian berikut:
Sebuah. Sinkronkan dari dev ke stage (yang) seperti biasa. Uji dengan melakukan uninstall modul yang akan dihapus diikuti dengan penghapusan kode, dll. Git workflow note: buat tag atau catat hashid dari berbagai status kode Anda: semua modul ada di tempat sebelum dihapus, modul modul dihapus, Anda menimpa & c. dihapus, dll sesuai kebutuhan. Mungkin hanya dua referensi yang dibutuhkan.
b. Ketika pengujian selesai dan diterima, kembalikan kode di atas panggung (yang) ke status live (ying).
c. Persiapkan situs live (ying) untuk dimutakhirkan dengan menonaktifkan kemampuan setiap pengguna untuk mengubah konten pada sistem. Pembaruan sql ke tabel izin biasanya akan dilakukan di sini. Pada titik ini, pengguna masih dapat membaca konten di situs langsung, tetapi akan mendapatkan izin ditolak kesalahan jika mereka mencoba memperbarui konten. (Jika Anda keren, mungkin Anda bisa mengubah izin penangan yang ditolak untuk mencetak pemberitahuan yang sesuai bahwa fungsi sementara tidak tersedia).
d. Sekarang dorong database live (ying) kembali ke database stage (yang), tidak termasuk tabel izin dari pembaruan.
e. Ulangi langkah a. lagi. Jika Anda memiliki tagar yang berguna, semestinya mudah untuk mengembalikan ke keadaan di mana modul yang akan dihapus ada, jalankan kait instal pada database, dan kemudian kembali ke status kode tempat item Anda dari langkah 1 digabungkan. kembali.
f. Anda sekarang siap untuk menukar ying dan yang. Lakukan ini dengan menyesuaikan arahan konfigurasi Apache Anda. Perhatikan bahwa jika Anda melakukan
/etc/init.d/apache restart, beberapa koneksi mungkin terputus, tetapi/etc/init.d/apache reloadakan memungkinkan untuk swap bersih.g. Live sekarang 'yang'; tabel izin tidak dimodifikasi di sini, sehingga pengguna dapat membuat konten. Jika Anda mengotomatiskan langkah-langkah e. dan f., waktu tidak tersedia harus sangat rendah.
h. Dorong langsung (yang) kembali ke tahap (ying), baik kode dan basis data - atau dorong dari dev, sesuai kebutuhan. Anda sekarang memiliki lingkungan yang bersih siap untuk iterasi berikutnya.
sumber
if (module_exists('removeme')) { ... }. Sebarkan kode itu. Jika Anda menguji dan mengonfirmasi bahwa menghapus modul tidak lagi merusak kode khusus Anda, itu akan menyederhanakan penerapan Anda. Masih disarankan untuk melakukan langkah menonaktifkan pada situs yang tidak aktif, tetapi mungkin ini akan mempersempit jendela Anda sedikit. Saya tidak berpikir bahwa kait pembaruan khusus Anda akan membuatnya lebih aman untuk menonaktifkan modul langsung.