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.