Pementasan situs, bagaimana Anda mengelola sinkronisasi pembaruan di DB?

Sudah diterima secara luas bahwa pengembang harus menguji pembaruan melalui situs pementasan sebelum melepaskannya ke server langsung, namun begitu pembaruan pengembangan memerlukan modifikasi dalam Wordpress DB, hal-hal menjadi rumit, karena pengguna di situs langsung akan memperbarui DB juga.

Satu-satunya aliran (kacau) yang bisa saya bayangkan adalah sebagai berikut:

1. Tes di server lokal (WAMP, XAMP, dll)
2. Setelah siap digunakan, taruh situs langsung dalam mode pemeliharaan
3. Cadangkan situs langsung (Duplikator, sqldump, dll)
4. Buat tiruan dari situs langsung yang dikunci ke situs pementasan
5. Unggah modifikasi dari lingkungan lokal ke situs pementasan
6. Uji situs pementasan
7. Dorong situs pementasan untuk hidup.
8. Hapus mode perawatan

Kelemahan dari aliran di atas:

• waktu henti mungkin lebih lama dari yang diharapkan untuk pengguna sementara pengembang dengan hati-hati menguji pembaruan di situs pementasan;
• mungkin memerlukan manajemen modifikasi manual: misalnya, layout pagebuilder siteorigin disimpan di db, jadi setelah layout dimodifikasi, itu harus diimpor secara manual di situs pementasan; dalam hal ini cukup memadai untuk hanya menjatuhkan & mengimpor halaman ke situs pementasan, dan jika berfungsi, mengimpornya di situs langsung

Saya ingin tahu apakah ada cara yang lebih baik dan lebih otomatis untuk mencapai ini.

Bagaimana menurut anda?

EDIT, seperti yang diminta, beberapa solusi telah diusulkan di masa lalu tetapi tidak ada yang menawarkan solusi yang pasti:

• 9/2010 - Sinkronisasi basis data antara dev / staging dan produksi
• 12/2011 - Menyebarkan Plugin Diperbarui atau Baru Itu Memodifikasi Tabel wp_options
• 9/2014 - Bagaimana cara mengunggah perubahan lokal ke server langsung tanpa mengabaikan posting / halaman baru?
• 1/2015 - Bagaimana cara mempertahankan blog situs wordpress dalam produksi dan pementasan?

Penyedia hosting baru yang melayani secara khusus untuk WordPress biasanya memiliki alat di tempat untuk meringankan rasa sakit ini. Saya menempatkan klien saya di Pantheon yang memiliki alur kerja yang diaktifkan Git yang rapih ini , di mana kode hanya bergerak ke atas (dari dev ke pementasan ke produksi) dan hal-hal DB hanya bergerak ke bawah (sebaliknya dari kode). Menyalin database dari produksi ke pementasan adalah satu klik dengan antarmuka mereka. Asalkan alur kerja ini dihormati, ini cukup banyak menghilangkan masalah yang pernah mengacaukan basis data produksi, memungkinkan saya untuk selalu menguji perubahan saya pada klon baru dari data produksi DB baik dalam tahap pengembangan.

Anda tidak harus menggunakan Pantheon - Anda dapat mengadopsi pendekatan serupa dalam proses Anda menggunakan alat Anda sendiri (Git + plugin kloning DB seperti WP Migrate DB). Saya hanya menemukan cara ini bekerja dengan baik untuk saya.

Pertanyaan: mengapa Anda menempatkan lokasi produksi Anda dalam mode pemeliharaan saat menguji pementasan? Seharusnya tidak ada kebutuhan untuk itu dalam sebagian besar kasus. Satu-satunya kasus yang dapat saya pikirkan adalah memiliki semacam sistem yang sangat rapuh yang sangat sensitif terhadap data pengguna tambahan yang dimasukkan ke dalamnya, dengan bug bencana untuk di-boot - tetapi itu mungkin merupakan indikasi masalah yang berbeda, lebih besar, di mana orang akan membutuhkan untuk memikirkan kembali seluruh arsitektur produk mereka.

Lihat VersionPress yang membawa versi GIT ke seluruh proses (file dan basis data)

Seperti yang dijelaskan di situs mereka:

VersionPress menyediakan pementasan tanpa rasa sakit . Ini berarti bahwa Anda dapat dengan mudah membuat lingkungan pengujian yang aman untuk perubahan Anda dan hanya menggabungkannya kembali ketika sudah siap. Menggabungkan adalah kata kunci di sini - VersionPress menangani situasi di mana situs langsung Anda memiliki konten baru sementara itu mulus.