Kenyataannya adalah apa yang kita inginkan adalah ini: http://www.liquibase.org/
Liquibase adalah open source (Apache 2.0 Licensed), pustaka independen-basis data untuk melacak, mengelola, dan menerapkan perubahan basis data. Itu dibangun di atas premis sederhana: Semua perubahan database disimpan dalam bentuk yang dapat dibaca manusia namun dapat dilacak dan diperiksa ke dalam kontrol sumber.
Namun proses pengembangan kami tidak mendukungnya. Kami biasanya tidak memodifikasi database melalui skrip diskrit yang kami tulis sendiri, kami menggunakan plugin yang kami aktifkan. Kami tidak menulis skrip DML untuk mengubah data pencarian yang kemudian kami periksa ke dalam kontrol kode sumber, kami menggunakan UI di halaman admin dan karenanya tidak memiliki kode sumber untuk digunakan nanti dalam mereplikasi perubahan itu selama migrasi.
Namun, kami dapat meniru beberapa - menggunakan beberapa alat yang tercantum di halaman ini:
/programming//q/225772/149060
Sebagai contoh, liquidbase memiliki fitur diff yang juga, secara opsional menyertakan perubahan data. Kami dapat, berpotensi, menampilkan skema dan data berbeda ke skrip, mengecualikan (mungkin) tabel tertentu yang mungkin menyertakan data uji (mis. Pos, dll.) Dan kemudian menerapkan skrip ke basis data produksi.
MySQLDiff (dibahas pada pertanyaan StackOverflow) melakukan schema diffs, dan penulisnya merekomendasikan mysql_coldiff untuk perbedaan data tabel - keduanya diimplementasikan dalam perl, jika alat java (liquidbase) terlalu banyak sumber daya untuk server Anda - meskipun membawa kedua database lokal dan menjalankan alat di PC Anda memecahkan masalah itu ...
Jika kita benar-benar ingin melakukannya dengan benar, kita harus mencatat sql apa pun yang berhubungan dengan pengaturan, opsi, atau perubahan konfigurasi lainnya, dan perubahan skema apa pun - dan mengonversi kode yang dicatat menjadi skrip migrasi untuk dimainkan melawan server produksi kami. Mainkan skrip migrasi melawan server, salin file situs wordpress (tidak termasuk unggahan, jika ada) dan kami adalah emas.
Jadi, menurut saya, jalan keluar terbaik adalah plugin migrasi-pembangun-pengembang yang menjebak sql yang kita butuhkan, menyimpannya, dan kemudian membuat skrip migrasi dari kode yang dicatat, daripada membangun cara untuk menggabungkan basis data. antara pementasan dan produksi. Tampaknya masalah yang lebih sederhana untuk dipecahkan juga.
Jika kita melihat kode plugin hook panggilan instruktur @bueltge untuk inspirasi: https://gist.github.com/1000143 (terima kasih kepada Ron Rennick via G + karena menunjukkan saya ke arah SAVEQUERIES dan kait penutup, yang tuntunlah aku untuk menemukannya)
- ganti saja untuk mendapatkan output SAVEQUERIES sebagai gantinya
- hanya dijalankan saat di admin
- saring semua pilihan
- Simpan hasil ke tabel di hook shutdown
- kita dapat secara selektif beralih perangkap output berdasarkan apa yang kita lakukan saat ini.
Sebagai contoh:
Nama Pengambilan: Aktifkan & Konfigurasi Plugin XYZ
Tangkap Status nyala
... instal dan konfigurasikan plugin XYZ
Tangkap Status Toggle - off
Ekspor Migrasi Script untuk: Aktifkan & Konfigurasi Plugin XYZ
Tekan Tombol Ekspor - untuk menghasilkan bidang teks popup dengan SQL terperangkap yang difilter - idealnya diformat sebelumnya sebagai skrip shell dengan panggilan baris perintah ke mysql. Salin & tempel ke folder kode migrasi Anda dan tambahkan ke repositori kode sumber Anda.
Perhatian yang cermat untuk mengaktifkan dan menonaktifkan tangkapan saat Anda bekerja dan Anda akan dapat menghasilkan skrip migrasi yang sempurna untuk membawa basis data produksi Anda ke konfigurasi yang setara dengan basis data pementasan Anda.
Apa yang lebih baik, Anda akan memiliki skrip (atau serangkaian yang sama) yang dapat Anda TES. Pencitraan memiliki skrip migrasi yang dapat ditiru, diuji, !!
Aku sudah jatuh cinta.
Ada orang lain