Apa praktik terbaik untuk meningkatkan inti Drupal tanpa melanggar repo Git dan situs web produksi


13

Saya punya repositori Git di mana semua kode saya ada di cabang master, dan saya sebelumnya hanya mengabaikan semua file Drupal, sehingga saya menjaga pemisahan ketat antara kode yang saya tulis (atau dimodifikasi atau mungkin dimodifikasi) dan kode yang bisa dihasilkan dengan Drush atau apa pun.

Ini sepertinya strategi yang bagus sampai saya harus memutakhirkan Drupal. Saya menyadari bahwa saya ingin dapat mundur jika segalanya berjalan buruk, dan alat apa yang lebih baik untuk digunakan daripada Git untuk melakukan itu. Saya berpikir sendiri ini akan menjadi situasi yang sempurna untuk fitur cabang, jadi saya membuat drupal-7.14cabang, memberikannya sendiri .gitignoreuntuk mengabaikan semua kode saya dan file pengaturan dan memperhatikan hanya file yang merupakan bagian dari instalasi Drupal yang saya tidak mau ' t menyentuh. Saya melakukan upgrade dengan tangan (unduh, unzip, untar, salin), memilah-milah kasus batas seperti robots.txt dan .htaccess, dan menimpa .gitignore Drupal dengan milik saya. Saya memperbaiki beberapa pengaturan yang berfungsi dengan 7.14 tetapi tidak dengan 7.15, untuk memulihkan dari kesalahan 500, dan kemudian semuanya tampak sempurna. Saya mengganti nama cabang drupal-7.15itu dan akan pergi dengan senang hati dalam perjalanan.

Sampai saya menyadari apa yang telah saya lakukan secara tidak sengaja: file yang sebelumnya tidak bisa dilacak oleh cabang master saya tetapi tertinggal di direktori kerja sekarang dihapus dari direktori kerja ketika saya memeriksa master, karena mereka bukan lagi file yang tidak terlacak! Doh!

Jika saya menggabungkan drupal-7.15cabang dengan master saya akan kehilangan pemisahan kode.

Mungkin ada beberapa cara untuk mengubah cabang menjadi submodule. Dengan asumsi itu mungkin, itu mungkin strategi terbaik. Saya tahu sebelum saya melakukan ini bahwa submodula adalah solusi "benar", tetapi karena saya tidak menyadari efek samping dari menggunakan cabang untuk file yang sebelumnya tidak terlacak, saya memutuskan untuk mengambil jalan pintas dan menempuh rute itu. (Juga, semua pendekatan yang saya lihat menggunakan submodul dengan Drupal menganggap bahwa Anda memulai proyek baru dan Drupal akan menjadi cabang utama. Tidak diinginkan bagi saya untuk membuat kode orang lain menjadi cabang utama, dan saya sudah memiliki repo dengan cabang master. Sepertinya ini tidak perlu rumit hanya untuk melakukan upgrade.)

Mungkin ada beberapa solusi lain yang belum saya pikirkan.

Bagaimana cara terbaik saya pulih dari ini dengan kerugian sesedikit mungkin?

PEMBARUAN : Ini sedang dikembangkan (dalam Linux VM di laptop saya), dan belum diproduksi. Pada saat kami pergi ke produksi, saya berencana untuk membungkus semuanya dalam modul fitur, tetapi itu belum ada.

UPDATE 2 : Submodules mungkin tidak berfungsi. Menurut Pro Git , "Submodules memungkinkan Anda untuk menyimpan repositori Git sebagai subdirektori dari repositori Git lain". Drupal tidak memberikan pemisahan yang bagus. Alih-alih semua kode Drupal berada dalam subdirektori, hubungannya lebih atau kurang terbalik, tetapi masih tidak ada pemisahan yang bersih, karena Anda mungkin mengedit .htaccess dan robots.txt Anda, sehingga kode Anda dan repo Drupal dicampur bersama. Saya mencari solusi untuk masalah ini .


Pertanyaan Anda sebenarnya tentang git. Saya pikir Anda akan mendapatkan jawaban yang lebih baik dengan memigrasi ini ke situs yang tidak spesifik untuk Drupal. Tentang pemutakhiran: Saya selalu melakukan pemutakhiran dengan membuat file make di direktori baru dan kemudian memperbarui symlink dari direktori publik lama ke baru, yang membuat kode-rollback sepele.
Letharion

2
@Letharion saya tidak setuju. Semua orang akan melalui proses peningkatan situs mereka dari versi mereka saat ini ke yang baru. Menggunakan git untuk meningkatkan inti cukup umum, karena ini adalah metode yang banyak digunakan untuk meningkatkan modul. Banyak orang akan bergumul dengan masalah ini seperti yang pernah saya alami sebelumnya. Saat ini tidak ada dokumentasi yang baik di web yang membahas masalah ini dan saya yakin ini adalah tempat yang bagus untuk itu.
iStryker

Hanya untuk memperjelas, saya pikir pertanyaan tentang "Praktik terbaik untuk meningkatkan Drupal" akan lebih cocok, karena pertanyaan ini benar-benar "Bagaimana cara memperbaiki kesalahan git", yang menurut saya tidak seharusnya ada di sini. Namun, saya tidak memiliki perasaan yang kuat pada topik tersebut, jadi saya akan membiarkannya begitu saja. :)
Letharion

OK cukup adil. Masalah yang dimiliki Brandon cukup umum. Mungkin saya harus membuat pertanyaan baru atau menulis ulang yang ini (dan memindahkan sisanya ke pertanyaan lain). 2-3 paragraf pertama adalah umum. Anda membuat repo git 7.x-1.0 dan Anda ingin memutakhirkan ke 7.x-1.1. File masalah adalah .gitignore, .htaccess dan robot.txt. Terkadang Anda ingin mereka melacak karena mereka di-mod, kadang-kadang Anda tidak ingin mereka dilacak karena karena mereka di-mod. Saat memutakhirkan repo Anda membuat cabang baru gabungan atau hanya memperbarui master. @Letharion Saran?
iStryker

@Letharion: Saya berpikir apakah akan meletakkan ini di StackOverflow sebagai pertanyaan Git atau di sini sebagai pertanyaan Drupal. Jika saya letakkan di sana, semua orang akan mengeluh dan mengatakan ini benar-benar tentang Drupal, dan saya pikir mereka benar. Meskipun Git dapat menjadi alat yang digunakan untuk memperbaiki situasi, arah yang diambil tergantung pada pengetahuan Drupal. Setiap pengguna Drupal menggunakan Git (atau mereka seharusnya jika tidak), tetapi hanya sebagian kecil dari pengguna Git yang menggunakan Drupal. Orang yang menanggapi pertanyaan tentang Git tidak akan memahami latar belakang Drupal.
iconoclast

Jawaban:


10

Tampaknya dari diskusi di atas bahwa pertanyaan Anda bukan tentang memperbaiki repo git Anda, tetapi tentang memelihara situs Drupal di git, dan bagaimana cara kerjanya dengan pembaruan inti.

Saya pikir praktik standar sebenarnya menyimpan semua file dalam repositori Anda, termasuk inti Drupal. Pemisahan kode Drupal dari kode kustom sepertinya ide yang bagus, tapi saya rasa itu tidak perlu, dan saya tidak melihat keuntungan apa yang diberikannya kepada Anda. Tampaknya juga menganggap bahwa Anda tidak akan pernah ingin menambal inti (atau harus melakukannya sebagai bagian dari penyebaran Anda), yang, meskipun bukan praktik terbaik, jelas merupakan sesuatu yang ingin Anda dapat lakukan jika ada yang rusak dalam produksi. Menjaga komitmen Anda tetap baik dan fokus juga membantu mendapatkan pemisahan seperti ini.

Solusi yang saya gunakan adalah menyimpan semua kode di repositori yang sama, memasukkan sebanyak mungkin di Fitur atau jenis ekspor / kode / konfigurasi lainnya, dan memelihara daftar tambalan yang perlu diterapkan ke luar -box inti dan contrib.

Ketika Anda memperbarui inti, mulailah di lingkungan dev Anda:

  • Pastikan direktori kerja bersih
  • Buang database terbaru ( drush sql-dump). Entah membuat komitmen dengan dump atau menyimpannya di tempat yang aman.
  • Perbarui inti ( drush up drupal)
  • Komit semua perubahan.
  • Periksa file tambalan. Jika ada tambalan yang perlu diterapkan, terapkan, dan buat komit lainnya
  • Jalankan update.php jika perlu (sudah dilakukan jika Anda menggunakan drush untuk pembaruan)
  • Uji situs pengembang Anda. Jika semuanya baik-baik saja, dorong kode ke produksi. Jalankan drush updbproduksi.
  • Jika ada masalah dan Anda harus kembali, kembalikan atau setel ulang repo Anda ( git reset --hard HEAD~2harus melakukannya), atau kembalikan kedua komit jika Anda ingin menyimpan riwayatnya. Ganti database Anda dengan dump.

Basis data diperlukan karena Anda tidak dapat membatalkan perubahan yang dilakukan ke basis data dengan pembaruan. Anda juga dapat melakukan pembaruan di cabang, dalam hal mengembalikan hanya berarti memeriksa master. Ini sedikit tidak disarankan jika Anda bekerja di satu situs dev karena Anda tidak dapat benar-benar beralih kembali ke master dan tetap bekerja di sana secara paralel karena database.

Menggunakan alur kerja git-side yang lebih sederhana ini akan memungkinkan Anda untuk menggunakan kekuatan penuh git ketika Anda membutuhkannya tanpa kerumitan submodul, dll. Jika ini tampaknya tidak memadai, dapatkah Anda menjelaskan mengapa Anda memerlukan pemisahan kode lebih lanjut?


0

Dari komentar saya di atas, pertanyaan yang Anda miliki adalah tentang memelihara file situs Drupal dengan git, dan bagaimana cara kerjanya dengan pembaruan inti. Anda tidak menyebutkan apa pun tentang mencadangkan dan meningkatkan basis data. Saya akan mencoba untuk tidak menyalin apa pun dari jawaban goron.

Saya telah membuat posting blog tentang masalah ini. Mengupgrade inti Drupal di situs web Anda dengan Git

Metode Alternatif

  1. Jalankan perintah Drush drush up drupal
  2. Terapkan tambalan perbedaan antara versi. Lihat http://drupal.org/node/359234 & http://fuerstnet.de/en/drupal-upgrade-easier

Anda tidak menyatakan ini, tetapi jika Anda tertarik melacak perubahan antara versi Drupal, saya akan melakukan ini dengan menggunakan tag, bukan cabang . Setelah Anda selesai dengan komit pemutakhiran Anda untuk dikuasai , beri tag kode Anda sebagai 7.x.


Jika saya mengerti dengan benar, Anda juga menyarankan agar saya menyimpan semua kode inti Drupal dalam repositori yang sama. Ini tampaknya menjadi konsensus. Saya enggan, tetapi saya mungkin harus menyerah dan melakukannya dengan cara itu.
iconoclast

Ya, semuanya dalam satu repositori. Saya memiliki modul, profil, dan tema di dalam repositori inti / utama yang merupakan repositori git mereka sendiri. Saya tidak tahu apakah cara terbaik, tetapi ini cara terbaik yang saya tahu.
iStryker

solusi ini tidak memberikan jalan untuk kembali. alasan saya untuk memilih.
Andre Baumeier

@Serpiente: Saya tidak melihat mengapa kurangnya cara untuk kembali harus menjadi alasan untuk downvote. Jika itu pendekatan terbaik, itu sudah cukup. Jika Anda tidak berpikir itu pendekatan terbaik, sebutkan mengapa tidak.
iconoclast

@iconoclast apa masalah sistem revisi jika Anda tidak dapat kembali ke timeline Anda? mis. pikirkan tentang pembaruan yang gagal - apa cara untuk memulihkan di sini? Versi perangkat lunak "apa pun" yang dikirim harus memiliki ketergantungan yang jelas, ini termasuk terutama kerangka kerja inti. Kalau tidak, Anda dapat dengan mudah menjatuhkan git dan mulai melakukan peluncuran FTP lagi. hanya 2 sen saya.
Andre Baumeier

0

Saya menjalankan pengaturan dengan dua cabang seperti OP: satu cabang dengan kode khusus saya saja, dan satu cabang yang memiliki file kustom dan inti. Saya mengalami situasi yang sama: file-file inti yang diabaikan dihapus ketika beralih antar cabang.

Saya akhirnya memiliki dua direktori git yang identik: - satu untuk mengerjakan kode kustom saya, dengan file inti yang ada tetapi diabaikan, dan saya tidak akan pernah beralih ke cabang "penuh" dalam direktori ini - satu untuk melakukan penggabungan, sehingga saya akan melakukan lakukan pemindahan cabang dan penggabungan di dalam direktori ini saja.

Alasan saya memilih pengaturan dua cabang ini adalah karena saya ingin dengan mudah melacak semua komit lokal ke file inti, lebih mudah untuk memeriksa dan menerapkan kembali mod inti saat memutakhirkan file inti.

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.