Latar Belakang

Saya mendekati tahap akhir membangun situs WordPress pertama saya yang cukup besar, dan saya sekarang menghadapi beberapa gesekan. Sebagian besar, situs ini dikembangkan di komputer lokal saya dan saya akan mendorong perubahan ke server pementasan untuk ditinjau ( lihat pertanyaan ini untuk latar belakang lebih lanjut ). Solusi yang akhirnya saya gunakan bekerja cukup baik ketika saya hanya mengedit konten, tetapi sekarang beberapa orang mengedit konten sementara saya masih memiliki fitur untuk ditambahkan. Idenya adalah: kita bisa menyelesaikan sesuatu lebih cepat jika fitur dan kontennya digabungkan bersama ... tapi sekarang saya tidak begitu yakin.

Saat ini ada konten yang berbeda di database pada server pementasan daripada di mesin lokal saya. Tidak masalah dengan sendirinya, karena saya tidak memerlukan salinan tubuh terakhir pada mesin lokal saya, tetapi saya perlu melakukan lebih banyak pengembangan yang akan mempengaruhi basis data (instal / tulis beberapa plugin lagi yang memerlukan tabel mereka sendiri).

Pertanyaanku adalah:

Apakah ada cara mudah untuk mengotomatiskan penggabungan basis data sehingga banyak orang dapat bekerja pada instalasi WordPress? Saya bisa, tentu saja, hanya mengekspor tabel yang saya tahu telah berubah pada mesin lokal saya dan mendorongnya ke server staging, tetapi mungkin juga ada beberapa hal di server staging yang ingin saya hancurkan. Saya bisa mengambil output SQL dari kedua DB dan diff mereka ... tapi itu membosankan dan membosankan. Saya ingin tahu apakah ini masalah yang dipecahkan orang lain; jika ada cara yang diterima masyarakat untuk menangani hal semacam ini.

Terima kasih!

Saya mengajukan pertanyaan ini lebih dari setahun yang lalu, dan selama waktu itu kami telah menambahkan lebih banyak orang ke tim kami dan mengembangkan lebih banyak situs di WordPress. Saya ingin berjalan melalui proses kami jika itu dapat membantu orang lain.

Semuanya ada di Git

Ini adalah sesuatu yang saya lakukan bahkan ketika saya mengajukan pertanyaan, tetapi ada baiknya menyebut hal ini. Menggunakan Git tidak hanya membantu kami menjadi lebih produktif, tetapi juga menghemat penilaian kolektif kami beberapa kali.

Pernahkah Anda perlu melakukan renovasi struktural besar-besaran ke sebuah situs, mendapatkan persetujuan untuk renovasi tersebut dari klien, dan sementara itu melakukan pembaruan kecil pada versi yang tidak direnovasi? Kami punya, dan Git membiarkan kami melakukannya. Menjabarkan pengaturan ini akan sedikit bertele-tele, tetapi dasar-dasarnya adalah bahwa kita membuat cabang baru, menarik cabang itu ke server, dan melampirkan subdomain ke cabang itu.

Kami juga telah diselamatkan oleh Git. Tentu saja memungkinkan kita untuk memutar kembali perubahan, yang bagus, tetapi juga memungkinkan kita untuk mengembalikan file versi lama. Ini berarti bahwa jika seorang klien bertanya, "Ingat bagaimana bagian situs ini bekerja sekitar setahun yang lalu? Bisakah kita mengembalikannya?", Jawabannya adalah ya - bahkan jika orang yang ditanyai tidak berada di proyek itu setahun. lalu.

Selain poin-poin ini, itu juga berarti bahwa kita tidak pernah terjebak tanpa file yang kita butuhkan. Kami selalu dapat menurunkan versi terbaru situs dari mesin apa pun dan mulai membuat perubahan.

Gunakan Git untuk menyebarkan

Kami melakukan hosting WordPress kami di Media Temple , dan kami sangat menyukainya. Mereka bukan penyedia termurah, tetapi layanan mereka sangat baik dan server mereka diatur dengan sangat baik. Git juga menyediakan secara default. Ini berarti kita dapat mengatur server sebagai repositori Git, dan menarik perubahan dengan cara itu alih-alih menggunakan SFTP. Ini juga berarti bahwa melakukan pekerjaan pada server tidak dalam bahaya ditimpa (karena perubahan itu hanya dapat digabungkan dan didorong kembali).

Karena kami menggunakan BitBucket sebagai host Git kami, ada sedikit pekerjaan tambahan yang diperlukan di sini. Pertama-tama kita menggunakan file .ssh / config sehingga kita dapat mengetik hal-hal seperti ssh sitenameuntuk masuk ke server kami (kami juga menggunakan SSH tanpa kata sandi , yang membuatnya sangat mudah). Kami juga memastikan untuk selalu menggunakan kata sandi ssh (Mac OS X membuat ini sangat mudah dengan memungkinkan Anda untuk menyimpan kata sandi Anda di Keychain.app ). Akhirnya, kita menambahkan baris ForwardAgent ke entri .ssh / config pada host yang ingin kita tarik. Ini berarti bahwa kita hanya memerlukan kunci publik SSH setiap orang di BitBucket, dan bukan kunci publik dari setiap server. Kami juga memastikan untuk menjaga .gitdirektori satu direktori di atas direktori HTML publik.

Kesedihan database otomatis

Setelah server berada dalam mode produksi, kami memastikan untuk membuat cadangan database kami secara otomatis, untuk berjaga-jaga .

Setiap orang memiliki konfigurasi wp mereka sendiri

Karena kita semua memiliki nama pengguna dan kata sandi basis data lokal kita sendiri, dan karena kita dapat menggunakan nama dan mekanisme penyajian yang berbeda, kita masing-masing menyimpan file wp-config kita sendiri. Masing-masing disimpan di Git dengan nama seperti wp-config-gavin.php, dan ketika kita ingin menggunakan konfigurasi itu, kita symlink ke wp-config.php(yang diabaikan oleh Git menggunakan .gitignore ).

Ini juga memungkinkan kita untuk menimpa siteurlopsi dalam wp_optionstabel database seperti:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Ini mencegah WordPress dari melihat basis data untuk lokasi server, dan berarti tidak ada perbedaan aneh dalam lokasi antara pemasangan lokal dan server.

Satu catatan terakhir tentang file wp-config.php: pastikan untuk menyimpannya di atas direktori HTML publik dan buat izin hanya untuk pengguna web . Ini membuat perbedaan besar dalam mengamankan WordPress.

Masalah basis data

Akhirnya, daging masalahnya.

Apa yang harus saya terima adalah, ketika menggunakan WordPress, tidak ada cara yang baik untuk "menggabungkan" perubahan basis data. Sebaliknya, kami perlu mengembangkan aturan perilaku untuk menyelesaikan ini. Peraturannya cukup sederhana, dan sejauh ini telah melayani kami dengan baik.

Selama pengembangan, ada satu orang yang "memiliki" situs tersebut. Orang itu biasanya melakukan pengaturan (menyatukan paket hosting, memulai proyek Basecamp, mengiris desain, hal semacam itu). Setelah orang itu ke titik yang masuk akal, dump database untuk menginstal WordPress dan memasukkannya ke Git. Sejak saat itu, semua orang yang melakukan pengembangan menggunakan dump database itu, dan pemilik adalah satu-satunya yang membuat perubahan pada database.

Setelah membangun situs menjadi sedikit lebih jauh, situs diletakkan di server. Sejak saat itu, basis data server bersifat kanonik. Setiap orang (termasuk pemilik) harus membuat semua perubahan basis data di server dan menarik perubahan ke bawah untuk pengembangan dan pengujian lokal.

Proses ini tidak sempurna. Masih mungkin bahwa seseorang mungkin perlu membuat perubahan di backend WordPress secara lokal selama pengembangan, dan kemudian harus membuat perubahan itu lagi dalam produksi. Namun, kami menemukan hal semacam itu jarang terjadi, dan proses ini bekerja cukup baik bagi kami.

Saya mengerjakan instalasi seperti itu dan telah menjawab pertanyaan seperti ini sebelumnya . Di bawah ini adalah pengaturan pilihan saya untuk jenis pekerjaan ini. Karena Anda ingin menggabungkan database alih-alih mengganti database yang sudah ada, saya akan menambahkan peringatan ini untuk tidak menggunakan flag --add-drop-table saat melakukan dump MySQL.

• Langkah 1. Mysqldump basis data pengembangan Anda
• Langkah 2. Ganti semua instance development.domain.com ke production.domain.com ^^
• Langkah 3. Login ke MySQL, jalankan perintah SOURCE untuk mengimpor data mis source /path/to/file

^^ Bagaimana cara mengganti semua instance dari domain lama dengan yang baru: (1) Salin skrip di bawah ini. (2) chmod +xitu. (3) Jalankan.

Pemakaian: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Saya sedang bereksperimen dengan solusi berbeda untuk masalah yang sama ini sekarang. Ini pasti yang rumit.

Solusi saya saat ini adalah melakukan dump mysql lokal menggunakan flag --skip-extended-insert. Saya percaya bendera ini menyebabkan pernyataan catatan insert dihasilkan untuk setiap baris database, membuat dump lebih ramah gabungan. Saya mengambil trik itu dari artikel ini: http://www.viget.com/extend/backup-your-database-in-git/ .

Saya kemudian sumber mengontrol file datadump .sql yang dihasilkan menggunakan Git bersama dengan file sumber situs. Ketika pengembang lain menarik ke bawah perubahan kode, file .sql datang bersamanya. Dia kemudian mengimpor file ini ke dalam database versi lokalnya. Kami telah menyiapkan basis data lokal kami masing-masing dengan cara yang sama di kedua mesin, menggunakan MAMP, sehingga tidak perlu melakukan pencarian dan penggantian.

Ada masalah penggabungan sehingga kami mencoba mengadopsi pendekatan "bergiliran" untuk apa pun yang akan menyebabkan perubahan basis data. Sebelum saya melakukan apa pun di Wordpress yang akan mengubah database saya memastikan dia memeriksa dump terbarunya, menarik dan mengimpornya, dan daripada memintanya untuk tidak melakukan perubahan DB sampai saya membuat dan memeriksa di tambang saya. Ini jelas tidak ideal dan saya mencari solusi yang lebih baik tapi ini awal. Ini juga memberi kita kontrol versi DB yang bagus.

Saya mungkin akhirnya mengatur kami database dev bersama di server dan mencoba menghubungkan kedua salinan lokal kami dari situs web ke DB yang sama melalui tunneling SSH. Namun, pendekatan ini akan mengalami masalah setiap kali salah satu dari kami memasang plugin. Pada dasarnya file PHP dan MySQL DB tidak sinkron.

Saya ingin sekali mendengar bagaimana orang lain menghadapi masalah ini.