Bagaimana cara saya mengelola pengembangan kolaboratif di situs Drupal?

Saya bekerja dengan pengembang lain di situs Drupal. Kami telah berjuang untuk menemukan cara yang baik untuk bekerja di berbagai bagian situs pada saat yang sama tanpa saling menghalangi. Kami telah mencoba mengerjakan instans pengembangan yang sama dari situs tersebut, tetapi kami sering menginjak kaki masing-masing, atau menjatuhkan situs dengan beberapa kode buruk sehingga tidak mungkin bagi yang lain untuk terus bekerja sampai diselesaikan. Jadi kami telah pindah ke memisahkan contoh pengembangan. Tapi sekarang sangat menyebalkan untuk menggabungkan pekerjaan kami menjadi satu contoh situs. Pada dasarnya kami akhirnya mengulang semuanya pada salinan yang dibagikan.

Masalah terbesar yang kita miliki sekarang adalah bagaimana kita menggabungkan perubahan basis data, dan bagaimana kita memasukkan basis data ke dalam sistem kendali sumber kita? File-file itu mudah, cukup lacak semuanya (kami menggunakan git) dan menggabungkan pekerjaan kami, menyelesaikan konflik jika diperlukan. Tetapi ini tidak benar-benar berfungsi dengan database. Kita bisa mengambil SQL dump dan memasukkannya ke dalam repositori git kita, tetapi kita tidak bisa benar-benar menggabungkan database. The Fitur Modul membantu sedikit, membiarkan kita mengekspor beberapa pekerjaan database kami ke dalam kode yang kemudian dapat diversi dan digabungkan. Namun, bahkan tidak dekat dengan semuanya mendukung Fitur. Begitu...

• Langkah apa yang bisa kita ambil untuk dengan mudah menggabungkan perubahan basis data kita?

• Bagaimana seharusnya kita versi database (apakah menempatkan file dump di git cara yang baik untuk melakukannya)?

• Apakah ada modul yang tersedia yang membantu dengan beberapa masalah ini?

• Atau, apakah kita terjebak dengan mengerjakan salinan situs yang sama? (tolong jangan tidak)

Sunting: Dalam komentar kami membahas hal-hal apa yang tidak dapat diekspor dengan Fitur dan salah satunya adalah Taksonomi. Ada pertanyaan lain yang berhubungan dengan itu .

Ini adalah perubahan alur kerja tetapi Anda harus terbiasa bekerja pada dump segar dari DB hidup. Ada tiga cara untuk mendapatkan perubahan ke dalam DB.

1. Fitur. Ini tidak akan bekerja untuk semuanya tetapi akan untuk banyak hal yang Anda butuhkan.
2. perbarui kait. Ketika fitur-fitur tidak berfungsi, Anda dapat membuat kode yang sulit menjadi sebuah kait pembaruan dari modul yang Anda miliki.
3. Perubahan manual. Gunakan hemat. Beberapa hal tidak datang secara alami ke fitur atau memperbarui pengait dan hanya lebih mudah dilakukan secara manual. Ini adalah pilihan terakhir, tetapi terkadang satu-satunya cara pembajakan.

Jika kamu bisa. Beberapa kali sehari mendapatkan tempat sampah baru dan menguji bangunan Anda, Anda seharusnya memiliki lebih sedikit masalah integrasi.

Saya menjawab pertanyaan serupa dan akan sedikit menyesuaikannya untuk menjawab pertanyaan Anda di sini. Saran root saya adalah bahwa Anda memiliki server pengembangan / pementasan di mana perubahan kode diperiksa menggunakan sistem integrasi berkelanjutan secara rutin (mis. Setiap 5 menit). Dengan demikian, pada mesin lokal Anda, Anda hanya bekerja pada satu permintaan fitur / laporan bug pada suatu waktu, pastikan untuk dengan jelas menggambarkan tugas ini dari orang lain yang orang mungkin sedang kerjakan dan berkomunikasi dengan rekan tim Anda bahwa Anda sedang mengerjakannya (redmine atau pelacakan bug lainnya bagus untuk ini). Kemudian, Anda melakukan perubahan secara teratur, dan mereka ditarik ke server dev / staging, seperti halnya rekan tim Anda. Idealnya, Anda memiliki unit test yang dibangun ke dalam sistem integrasi berkelanjutan Anda (sangat merekomendasikan luntbuild atau QuickBuild untuk hal ini, tetapi Hudson juga berfungsi). Sistem atau pengujian CI dapat secara otomatis menjawab setiap konflik yang mungkin Anda perkenalkan segera setelah Anda memeriksa kode Anda. Jika Anda perlu melakukan perubahan konten (bukan kode), Anda melakukannya di server dev / staging.

Mengenai bagian basis data, pada dasarnya saya telah mengadopsi dua aliran pemikiran (aliran pemikiran ketiga, melakukan perbedaan basis data, saya tidak akan membahas karena kompleksitasnya cukup tinggi).

1) Menyebarkan dengan menjatuhkan basis data produksi, dan mengimpor mysqldump dari database pengembangan. Secara opsional, jalankan regex find / replace terlebih dahulu di tautan absolut apa pun yang dikodekan keras yang mereferensikan URL dev di dump SQL. Setelah mengimpor dev db ke dalam prod, secara otomatis menjalankan pernyataan SQL (biasanya melalui skrip) setelah itu untuk mengubah pengaturan yang berbeda untuk prod daripada dev (misalnya, mungkin Anda memiliki dalam tabel variabel beberapa pengaturan koneksi untuk menghubungkan ke sistem eksternal yang Anda perlu ubah untuk menunjuk pada prod sistem eksternal dan bukan pada versi dev).

2) Gunakan modul Fitur, sebagaimana disebutkan oleh budda, untuk pengaturan admin, dan gunakan modul Node Export untuk ekspor / impor konten dalam kombinasi dengan modul Delete All. Jadi alur kerjanya adalah:

gunakan node_export dan fitur untuk mengekspor node / fitur ke file Opsional (dan semoga) kontrol versi Memuat file pada sistem prod Gunakan drush atau antarmuka admin untuk memuat fitur Gunakan drush delete-all atau admin antarmuka untuk menghapus semua node dari jenis yang ingin Anda impor Gunakan drush ne-import atau antarmuka admin untuk mengimpor node dari file node yang Anda ekspor. Satu catatan, saya akan sangat menyarankan mengadopsi alur kerja standar, di mana konten berjalan satu arah saja. Entah Dev -> Prod atau Prod -> Dev (Saya lebih suka yang ini).

Saya telah melakukan ini, dan saya melakukan ini pada beberapa sistem besar, dengan hasil yang cukup baik, tetapi akan selalu ada banyak cara untuk mengiris apel ini, pilih cara mana yang paling cocok untuk Anda.

Meskipun ini adalah pertanyaan lama dengan jawaban yang diterima, saya percaya bahwa masih ada ruang untuk yang lain.

Pertama, izinkan saya mengatakan sebelumnya bahwa saya tidak berpikir Fitur adalah alat yang tepat untuk tugas ini, dan akan mengusulkan seperangkat alat alternatif.

Prasyarat untuk kolaborasi tim adalah memiliki server staging untuk menguji versi pengembangan proyek yang terpisah dari server produksi Anda. Semua kode devlopment diuji di server staging, dan hanya didorong ke server produksi ketika stabil dan siap untuk ditempatkan. Namun, pengembang tidak bekerja langsung di server pementasan. Setiap pengembang bekerja di stasiun kerjanya sendiri, menggunakan kontrol revisi dan manajemen kode sumber (SCM) untuk mengoordinasikan pekerjaannya dengan anggota tim lainnya.

Sistem SCM memungkinkan anggota tim untuk bekerja secara paralel pada cabang kode yang berbeda tanpa mengganggu satu sama lain. Hanya cabang master yang digunakan pada server pementasan untuk tujuan pengujian.

Untuk mencerminkan database antara produksi, staging, dan workstation, ada modul bernama Cadangkan dan migrasi yang dapat digunakan jika Anda menggunakan hosting bersama dan tidak mengelola database Anda sendiri. Jika Anda mengelola server database Anda sendiri, ini adalah satu-satunya proyek di server itu, dan Anda menggunakan mysql , pasangan perintah berikut ini berguna:

Membuang:

mysqldump --all-databases --opt -u root -p > DUMP.sql

Untuk mengembalikan:

mysql -u root -p < DUMP.sql

Jika milik Anda bukan satu-satunya basis data di server itu, skrip beberapa versi mysqldump(atau setara jika Anda tidak menggunakan mysql ) yang hanya membuang basis data Anda.

Buat kebijakan bahwa itu adalah database di server produksi yang master. Server pementasan dan workstation harus merupakan salinan dari basis data produksi, bukan sebaliknya.

Perhatikan bahwa Drupal 7 menyimpan semua pengaturan adminnya di database. Ini berarti bahwa mirroring database antara situs produksi, situs pementasan dan workstation akan memigrasi pengaturan admim tanpa Fitur .

Sekarang, untuk berbagi kode:

Cara standar untuk berbagi kode di antara anggota tim pengembangan adalah dengan menggunakan sistem SCM. Drupal secara default dikelola dengan sistem yang bernama git .

Git memungkinkan penggunaan repositori lokal atau jarak jauh. Jika anggota tim berada di ruang fisik yang sama, Anda dapat mengatur repositori lokal di server pementasan Anda. Jika tersebar secara geografis, Anda dapat mengatur repositori jarak jauh. Jika Anda tidak keberatan orang lain memiliki akses baca pada kode Anda dalam pengembangan, Anda dapat menggunakan kotak pasir di Drupal.org sebagai repositori jarak jauh. Anda juga dapat menggunakan area proyek di GitHub . GitHub bukan hanya repositori, tetapi dilengkapi dengan beberapa alat untuk kolaborasi, dan memungkinkan repositori publik dan pribadi.

Pada dasarnya, sistem SCM memungkinkan anggota tim untuk menarik kode sumber dan dokumentasi dari tempat penyimpanan yang dibagikan oleh anggota tim, dan mendorongnya kembali setelah bekerja di dalamnya. SCM melacak perubahan dan jika ada konflik (yaitu seseorang mencoba mendorong kode yang tidak mengandung perubahan yang dilakukan anggota tim lain), itu akan memberi tahu Anda dan juga menyarankan cara untuk menyelesaikan konflik ini.

Biasanya, dengan beberapa komunikasi yang ramah tentang bagaimana tugas dibagi di antara anggota tim, tidak akan ada konflik. Tetapi dengan sistem SCM melacak hal-hal, konflik menjadi dikelola bahkan jika kesalahan dibuat atau komunikasi gagal.

Ada banyak tutorial untuk memulai dan menggunakan git (GIYF). Dua yang akan saya rekomendasikan adalah: situs web git-scm dan Pro Git oleh Scott Chacon.