Menjaga database WP disinkronkan di beberapa pengembang menggunakan git


33

Saya sedang bekerja untuk meningkatkan alur kerja git saya sebagaimana berlaku untuk proyek pengembangan WordPress saya. Seringkali, ketika mengembangkan sistem manajemen konten, saya akan membuat server pengembangan (seperti http://dev.finalsitename.com) yang berisi jenis pos kustom dan taksonomi yang akan digunakan dalam versi produksi. Ini memungkinkan klien saya untuk mulai menambahkan konten mereka ke situs.

Sementara mereka mengerjakan tugas ini, saya biasanya membangun tampilan dan nuansa serta pemrograman / plugin kustom yang akan digunakan pada lingkungan localhost saya. Untuk memastikan bahwa saya tidak menimpa pembaruan mereka, saya biasanya menarik salinan database mereka dan mengganti milik saya. Namun, ada kalanya saya hanya perlu melompat ke area admin WP dan mengubah pengaturan atau sesuatu yang kecil ...

Jika ada beberapa pengembang yang mengerjakan proyek WordPress, kita masing-masing melakukan dump database (timestamped) versi situs kami dan memasukkannya ke dalam direktori root sebelum melakukan dan mendorong cabang lokal mereka kembali ke repositori jarak jauh. Masalah dengan pendekatan ini adalah bahwa database sering kali tidak sinkron tanpa cara yang mudah untuk menentukan mana yang akan digunakan.

Apa yang dilakukan pengembang lain untuk menjaga sinkronisasi basis data mereka sementara masih memungkinkan banyak pengembang (dan klien / produsen konten) untuk bekerja pada proyek yang sama?

Jawaban:


12

Ada 3 opsi dari yang paling mudah ->

  1. Gunakan hanya satu basis data jauh yang Anda semua sambungkan dengan banyak cadangan. Dengan begitu Anda hanya perlu khawatir tentang file dan bukan db.

  2. Gunakan fungsi impor dan ekspor yang dibangun di WordPress dan melemparkannya ke kontrol versi Anda langsung ke root wp (seperti di folder baru). Tentu dibutuhkan beberapa menit ekstra tetapi sederhana dan Anda dapat mengotomatisasi, tetapi yang lebih penting itu akan menjadi bagian dari kontrol versi.

  3. Gunakan skrip pembaruan khusus untuk versi sinkronisasi database aktual. Jujur saya tidak tahu bagaimana Anda bisa mengelolanya dengan git karena itu hanya sebuah skrip dan tidak benar-benar tahu apa yang sedang terjadi, saya tahu ada alat pihak ke-3 yang melakukan ini komersial dan gratis ( http: // www. liquibase.org/ ).


1

Jika Anda perlu menjaga sinkronisasi database sepenuhnya, yaitu. skema dan data, Anda dapat mengembangkan sistem versi kustom berdasarkan cadangan.

Atau jika Anda ingin menjaga data dari produksi tetapi mengembangkan skimnya, Anda dapat bekerja dengan solusi khusus (file versi dengan semua perubahan skema), atau dengan solusi standar berdasarkan konsep migration. Anda dapat menemukan banyak info di utas stackoverflow ini: Mekanisme untuk melacak perubahan skema db .



1

Saya minta maaf jika ini tampak sangat jelas tetapi jika Anda semua perlu memiliki salinan yang sama dari database dengan struktur yang sama, tidakkah masuk akal untuk memiliki kantor / pusat SQL server dan menggunakannya? Kloning secara lokal jika Anda perlu bereksperimen tetapi tetap sebagai standar defacto otoritatif dan mengambil cadangan dari server itu dan hanya server itu.

Kalau tidak, ketika saya sedang mengerjakan proyek grup kami memiliki setup sendiri dengan konten yang berbeda. Kode menangani pembaruan dan migrasi struktur tabel dan kita dapat mengakses instalasi kode lain yang berjalan satu sama lain di mesin kami melalui LAN, jadi tidak perlu bagi kami untuk berbagi konten.

Jika kita memasukkan konten, kita menjalankannya pada server uji yang kemudian dapat kita ekspor dan impor ke server langsung, atau kita dapat bermigrasi langsung ke server produksi jika tidak ada instance live saat ini ada.

Jika suatu saat Anda membutuhkan pemisahan data uji hidup dan WIP, maka cukup gunakan cabang langsung, uji, dan pengembangan dalam repositori Anda

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.