(dis) keuntungan dari pementasan dev-> produksi menggunakan 'drush rsync' vs 'git'?

9

Saya membuat situs Drupal di bawah kontrol git untuk pekerjaan pengembangan.

Ini dipasangkan dalam master, repo telanjang GIT, dan karena perubahan dibuat di berbagai klon git proyek-pekerjaan saya, dan didorong kembali ke master, kait pasca-pembaruan segera mendorong perubahan ke satu situs web Staging langsung (http: / /staging.loc.). Tidak ada yang istimewa, bekerja seperti yang diharapkan.

Saya juga drush-alias situs "@STAGING". Kadang-kadang, saya ingin mempromosikan perubahan saya dari situs Pementasan ke server produksi.

Dua metode yang relatif langsung datang ke pikiran:

(1) Pada titik ketika situs Pementasan tampak stabil, buat situs Produksi sebagai git checkout dari master repo,

(2) menggunakan drush rsync+ drush sql-syncdari lokasi pementasan ke lokasi produksi.

Keduanya bisa dibuat bekerja. Selain fakta bahwa (2) tampaknya lebih Drupal-sentris / sadar secara alami - drush, bagaimanapun, adalah seperangkat alat khusus Drupal - apa manfaat relatif dari kedua pendekatan tersebut?

Apakah ada alasan khusus yang harus saya pertimbangkan (1) di atas (2)?

Dalam kedua kasus "Semuanya" di bawah setidaknya satu contoh kontrol revisi ...

drush version-control staging

— Clive
sumber

3

Saya telah menggunakan kedua teknik ini. Keduanya dapat digunakan untuk menjamin bahwa file yang sama yang Anda uji pada @stage berakhir pada @live. Keuntungan dari rsync adalah Anda tidak berakhir dengan file tambahan (mis. "Git" dan terkait) di server produksi Anda. Saya cenderung rsync ke vps, dan menggunakan git pada kotak yang saya miliki (misalnya situs intranet).

— greg_1_anderson
sumber

Terima kasih untuk intinya. Saya hanya melihat opsi pengecualian. Itu membantu menjaga kebersihan. Iiuc, saya perlu menentukan apa yang harus dikecualikan "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"dalam file .rc, meskipun saya belum yakin apakah saya memerlukannya baik dalam sumber atau target alias spesifikasi atau hanya satu atau yang lain.

.git harus diabaikan secara default. Jalankan 'drush --simulate rsync [options] @a @b' untuk melihat perintah rsync yang tepat yang akan dijalankan oleh Drush. Gunakan --include-vcs jika Anda ingin drush rsync menyertakan file .git dan vcs lainnya yang terkait.

— greg_1_anderson

Saya perlu membaca lebih detail; Saya tidak menyadari bahwa git dikecualikan. Terima kasih atas petunjuknya juga. Re: OP, saya pikir saya akan tetap dengan 'drush rsync' karena dirancang untuk menjadi metode penyebaran untuk drupal & bekerja. git dapat bekerja tentu saja tetapi sekarang saya telah menemukan cukup komentar yang tidak dirancang untuk digunakan ...

1

Masalah dengan menggunakan drush rsync adalah jika Anda memiliki banyak orang yang mendorong perubahan ke server.

Contoh Anda hanya menunjukkan satu orang yang mendorong perubahan.

Jika Anda memiliki pengembang A yang mendorong perubahannya dan kemudian pengembang B mendorong perubahannya, Anda ingin git menghapus konflik, atau membuat pengembang B menghapus konflik.

— Micheas Herman
sumber

1

Saya sebenarnya menggunakan keduanya. svn / git dan rsync melayani dua tujuan berbeda. svn / git untuk kontrol sumber, rsyncdan sql-syncuntuk menyinkronkan pementasan dan prod efisien. drush rsync @staging @prodsangat sulit dikalahkan dalam hal kesederhanaan, dan sangat mudah untuk diintegrasikan di sebagian besar continuous Integrationlingkungan apa pun jika Anda ingin menyelam lebih dalam dalam kegilaan / metodologi kualitas kode.

— stefgosselin
sumber

1

Secara pribadi saya menggunakan Git untuk kontrol versi, penyebaran dan sinkronisasi berbagai basis kode server dan kemudian rsync untuk memindahkan / menyinkronkan file pengguna (diabaikan dengan menambahkan jalur tertentu ke file .gitignore).

— danbohea
sumber