Pengembangan Dev, Panggung dan Produksi untuk Situs WordPress?


41

Jadi saya harus dapat memiliki dev / tahap / iterasi produksi (lebih dari server terpisah) untuk situs WordPress, saya biasanya menggunakan git tetapi ini jelas tidak akan bekerja dengan situs WordPress karena ketergantungan pada database untuk utama konfigurasi ... well, hampir semuanya.

Jadi pertanyaan saya adalah bagaimana kalian melakukannya? Saya punya Google cepat dan melihat ada beberapa plugin, apakah ini satu-satunya cara? Mana yang paling baik melakukan pekerjaan dalam hal kemudahan penggunaan, kecepatan, keandalan, dll.?


pantheon.io memiliki dev, menguji dan hidup untuk satu domain. Mereka menggunakan git untuk file dan mentransfer database di antara mereka dengan satu klik. Ini gratis untuk dicoba dan Anda hanya membayar bila Anda 'hidup' - youtube.com/watch?v=KpGTDeqwgX4
jgraup

Jawaban:


27

Saya memiliki pengaturan yang sangat saya banggakan, dan itu bekerja dengan sangat baik untuk tim saya.

Struktur Umum

Saya menyimpan seluruh instalasi di bawah git. Semua perubahan, baik itu pembaruan sistem, menambah / memperbarui plugin, menambahkan / memperbarui tema, melalui alur kerja yang sama. Perubahan dapat dibatalkan pada saat itu juga. Saya memiliki server penyebaran (desktop P4 lama) yang menjalankan gitosis tetapi Anda bisa dengan mudah menggunakan github atau gitolite . Dalam git, saya memiliki dua cabang "khusus", masterdan develop(dijelaskan lebih lanjut di bawah). Server produksi dan pementasan saya berbasis cloud.

Lingkungan Pengembangan

Setiap pengembang menjalankan server pengembangan mereka sendiri di mesin mereka sendiri. Dalam hal database, membutuhkan data langsung hampir tidak pernah menjadi masalah. Kami terutama menggunakan data uji unit tema . Kalau tidak, ekspor dan impor mencakup sebagian besar hal. Jika DB piece sangat penting, Anda bisa mengatur replikasi atau menyiapkan sesuatu untuk sinkronisasi on-demand. Ketika saya awalnya menyiapkan struktur ini, saya pikir ini akan sangat penting jadi saya mulai menulis seperangkat alat untuk melakukan ini, tetapi saya terkejut mereka benar-benar tidak perlu. (catatan: karena mereka tidak diperlukan, saya tidak pernah memoles mereka, jadi ada bug misalnya akan mengganti domain dalam data serial).

Lingkungan Pementasan

Ketika komit didorong dari developcabang ke gitosis, mereka dapat secara otomatis dikerahkan ke server pementasan kami. Database pementasan adalah budak dari basis data produksi.

Lingkungan produksi

Ketika komit didorong ke gitosis di mastercabang, itu secara otomatis dikerahkan ke server produksi.

Masalah wp-config.php

Anda ingin wp-config.phpmenjadi unik dari server ke server, tetapi Anda juga ingin tetap di bawah kontrol versi. Solusi saya adalah menggunakan .gitignoreuntuk mengabaikan wp-config.php, dan menyimpan versi pementasan dan produksi sebagai file dengan nama yang berbeda. Kemudian pada setiap server, saya symlink misalnya wp-config.php -> wp-config-production.php. Setiap pengguna kemudian menyimpan DB mereka sendiri dengan kredensial mereka sendiri, dengan pengaturan wp-config.php mereka sendiri (tidak terlacak).

Catatan lain

Saya menggunakan Rackspace Cloud , yang fenomenal dan murah. Dengan itu saya dapat menjaga server pementasan dan produksi saya identik. Saya juga sedang menulis plugin saat ini yang menggunakan API mereka untuk memungkinkan saya untuk mengontrol layanan saya langsung dari dalam WordPress, itu luar biasa.

Direktori cache, direktori unggahan file, dll., Semuanya ditambahkan ke .gitignore. Jika Anda mau, Anda dapat mengatur tugas cron untuk secara rutin memeriksa unggahan dan mendorongnya ke gitosis, tetapi itu sepertinya tidak pernah perlu bagi saya.

Struktur master / mengembangkan diatur untuk sebagian meniru model percabangan Vincent Driessen . Saya juga menggunakan ekstensi git-nya git-flow dan saya akan sangat menyarankan itu juga.

Saya memiliki 10 atau lebih pengembang yang mengerjakan struktur ini selama lebih dari satu tahun sekarang dan merupakan impian untuk bekerja dengannya. Andal, aman, cepat, fungsional, dan gesit, Anda tidak bisa meminta lebih banyak lagi!


Saya akan mengatur instalasi wp dengan cara yang sama (tapi kami menggunakan svn) dan saya ingin mengonfirmasi proses Anda untuk memperbarui plugin dan wp: selesaikan pembaruan dan periksa pada dev, komit perubahan, sebarkan pada staging, periksa, mengandalkan hidup. Singkatnya, Anda tidak pernah benar-benar melakukan pembaruan instalasi wp di server langsung Anda membawa perubahan melalui pembaruan di repo?
paullb

1
Bagaimana dengan perubahan pada DB yang dilakukan oleh rutin pembaruan. Bagaimana dampaknya terhadap DB produksi?
paullb

Alur kerja itu benar @ paullb, dan Anda tidak perlu khawatir tentang pembaruan DB. Cara WordPress bekerja, pembaruan dipicu setelah perubahan terdeteksi, jadi ini bekerja dengan cara yang persis sama dengan pembaruan manual (ke inti atau plugin) berfungsi!
Matthew Boynes

@ MatthewBoynes, halo. apakah Anda masih menggunakan alur kerja ini untuk pengembangan Anda? jika demikian, saya akan menerapkan alur kerja ini ke proyek saya. terima kasih :)
khakiout

Saya tidak, tetapi hanya karena itu tidak berlaku untuk proyek yang sedang saya kerjakan, yang sebagian besar di-hosting di WordPress.com VIP. Jika itu berlaku, saya masih akan menggunakannya (dan pada kenyataannya, perusahaan tempat saya bekerja sebelumnya terus menggunakannya).
Matthew Boynes

4

Pertama, saya pikir ini penting untuk mempertimbangkan apa yang akan Anda Kontrol Versi. Saya akan merekomendasikan untuk tidak meletakkan seluruh direktori WP di bawah VC. Saya pikir paling masuk akal untuk meletakkan wp-content / themes / YourThemeName di bawah VC. Untuk situs besar dengan jumlah plugin kompleks yang tinggi saya bisa melihat case untuk menyertakan wp-content / plugins juga. Jika Anda benar-benar harus melakukannya, Anda dapat memasukkan wp-content / upload. Jawaban di bawah ini akan sedikit berubah, tergantung pada apa yang Anda kontrol versi.

Karena itu, inilah yang saya gunakan:

Lokal: Mengatur tumpukan LAMP pada mesin Anda. Gunakan URL yang sama dengan situs pengembangan Anda. Gunakan entri file VirtualHosts dan .host untuk mensimulasikan lingkungan pengembangan dari sudut pandang URL. Jika Anda hanya ingin mengubah tema, pertimbangkan untuk menggunakan SSHFS untuk menautkan ke wp-content / plugins, wp-content / upload. Pertimbangkan untuk menggunakan basis data pada instalasi pengembangan proyek Anda kecuali Anda benar-benar melakukan pekerjaan berat.

Pengembangan: Periksa salinan Repo Anda yang berfungsi di lingkungan WP Anda. Siapkan Hook POST-COMMIT di SVN untuk memperbarui repo ini di setiap komit. Ini akan tetap disinkronkan. (Anggap saja integrasi terus menerus orang miskin.)

Produksi: Lihat tag versi bernama yang mewakili kandidat akhir. Ketika Anda perlu menggunakan versi baru, alihkan tag dan perbarui repo.


Lingkungan pengembang sangat cocok untuk menguji bangunan malam, dan git wordpress diperbarui secara otomatis setiap 30 menit, selain terdesentralisasi dan bekerja lebih baik untuk tim, saya tidak tahu siapa pun yang telah pindah ke git / hg yang telah kembali untuk menggunakan svn.
Wyck

1
Hanya ingin tahu alasan Anda untuk tidak meletakkan seluruh direktori WP di bawah kontrol versi. Itu tampak seperti hambatan dalam alur kerja. Menempatkan WP di repo memberi semua devs basis kode dan versi WP yang sama. Ini juga memungkinkan konsistensi di seluruh lingkungan. Lihat tautan Wyck (pada jawabannya) ke file bersyarat wp-config.
Brian Fegter

2

Kami baru-baru ini menemukan RAMP . Catatan: ini hanya bagian dari keseluruhan proses, tetapi menyinkronkan basis data antar server mungkin adalah bagian yang paling sulit.


2

Saya melakukan ini dengan git dan lincah, pastikan Anda menggunakan repo pribadi.

Pilihan 1.

Satu-satunya masalah adalah config.php, yang bisa Anda katakan pada git untuk diabaikan saat ditekan atau sebelum init.

Gunakan .gitignoreatau git update-index --assume-unchanged config.php(baca sedikit tentang perintah yang diasumsikan tidak berubah sebelum menggunakannya)

Opsi 2.

Gunakan persyaratan dalam config.php yang memeriksa url dan menerapkan kredensial yang benar, di sepanjang baris "jika server url = dev lalu gunakan kredensial A, selain itu gunakan kredensial B", dll.

Markus menjelaskan hal ini dengan lebih baik, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

ps. Anda juga dapat server file langsung dari repo jarak jauh daripada memiliki "file server" tradisional. (video yang sangat membosankan yang saya buat tentang ini http://www.youtube.com/watch?v=8ZEiFi4thDI )

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.