Haruskah saya menambahkan berkas migrasi Django dalam .gitignoreberkas?
Saya baru-baru ini mendapatkan banyak masalah git karena konflik migrasi dan bertanya-tanya apakah saya harus menandai file migrasi sebagai abaikan.
Jika demikian, bagaimana saya akan menambahkan semua migrasi yang saya miliki di aplikasi saya, dan menambahkannya ke .gitignorefile?
Jawaban:
Mengutip dari dokumentasi migrasi Django :
File migrasi untuk setiap aplikasi berada dalam direktori "migrasi" di dalam aplikasi itu, dan dirancang untuk digunakan, serta didistribusikan sebagai bagian dari, basis kodenya. Anda harus membuatnya sekali di mesin pengembangan Anda dan kemudian menjalankan migrasi yang sama di mesin rekan Anda, mesin staging Anda, dan akhirnya mesin produksi Anda.
Jika Anda mengikuti proses ini, Anda tidak akan mendapatkan konflik penggabungan apa pun di file migrasi.
Saat menggabungkan cabang kontrol versi, Anda masih mungkin menghadapi situasi di mana Anda memiliki beberapa migrasi berdasarkan migrasi induk yang sama, misalnya jika pengembang yang berbeda memperkenalkan migrasi secara bersamaan. Salah satu cara untuk mengatasi situasi ini adalah dengan memperkenalkan _merge_migration_. Seringkali ini dapat dilakukan secara otomatis dengan perintah
./manage.py makemigrations --mergeyang akan memperkenalkan migrasi baru yang bergantung pada semua migrasi head saat ini. Tentu saja ini hanya berfungsi jika tidak ada konflik antara migrasi head, dalam hal ini Anda harus menyelesaikan masalah secara manual.
Mengingat bahwa beberapa orang di sini menyarankan agar Anda tidak melakukan migrasi ke kontrol versi, saya ingin menjelaskan alasan mengapa Anda sebenarnya harus melakukannya.
Pertama, Anda memerlukan catatan migrasi yang diterapkan ke sistem produksi Anda. Jika Anda menerapkan perubahan pada produksi dan ingin memigrasi database, Anda memerlukan deskripsi tentang status saat ini. Anda dapat membuat cadangan terpisah dari migrasi yang diterapkan ke setiap database produksi, tetapi ini tampaknya tidak praktis.
Kedua, migrasi sering kali berisi kode tulisan tangan kustom. Tidak selalu mungkin untuk membuatnya secara otomatis dengan ./manage.py makemigrations.
Ketiga, migrasi harus dimasukkan dalam tinjauan kode. Itu adalah perubahan yang signifikan pada sistem produksi Anda, dan ada banyak hal yang bisa salah dengannya.
Jadi singkatnya, jika Anda peduli dengan data produksi Anda, periksa migrasi Anda ke kontrol versi.
Anda dapat mengikuti proses di bawah ini.
Anda dapat menjalankan makemigrationssecara lokal dan ini membuat file migrasi. Komit file migrasi baru ini ke repo.
Menurut pendapat saya, Anda tidak boleh menjalankan makemigrationsproduksi sama sekali. Anda dapat menjalankan migrateproduksi dan Anda akan melihat migrasi diterapkan dari file migrasi yang Anda lakukan dari lokal. Dengan cara ini Anda dapat menghindari semua konflik.
DI ENV LOKAL , untuk membuat file migrasi,
python manage.py makemigrations
python manage.py migrate
Sekarang komit file yang baru dibuat ini, seperti di bawah ini.
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...
DALAM PRODUKSI ENV , jalankan hanya perintah di bawah ini.
python manage.py migratemigratedan TIDAK PERNAH makemigrationsuntuk migrasi yang berkomitmen. Tidak pernah terpikir olehnya.
Kutipan dari dokumen 2018, Django 2.0. (dua perintah terpisah = makemigrationsdan migrate)
Alasan adanya perintah terpisah untuk membuat dan menerapkan migrasi adalah karena Anda akan melakukan migrasi ke sistem kontrol versi Anda dan mengirimkannya bersama aplikasi Anda; mereka tidak hanya membuat pengembangan Anda lebih mudah, mereka juga dapat digunakan oleh pengembang lain dan dalam produksi.
TL; DR: lakukan migrasi, selesaikan konflik migrasi, sesuaikan alur kerja git Anda.
Rasanya Anda perlu menyesuaikan alur kerja git Anda , daripada mengabaikan konflik.
Idealnya, setiap fitur baru dikembangkan di cabang yang berbeda, dan digabungkan kembali dengan permintaan penarikan .
PR tidak dapat digabungkan jika ada konflik, oleh karena itu siapa yang perlu menggabungkan fiturnya perlu menyelesaikan konflik, termasuk migrasi. Ini mungkin membutuhkan koordinasi antara tim yang berbeda.
Penting juga untuk melakukan file migrasi! Jika konflik muncul, Django bahkan mungkin membantu Anda menyelesaikan konflik tersebut ;)
Saya tidak dapat membayangkan mengapa Anda akan mendapatkan konflik, kecuali Anda mengedit migrasi entah bagaimana caranya? Itu biasanya berakhir buruk - jika seseorang melewatkan beberapa komitmen perantara maka mereka tidak akan meningkatkan dari versi yang benar, dan salinan database mereka akan rusak.
Proses yang saya ikuti cukup sederhana - setiap kali Anda mengubah model untuk suatu aplikasi, Anda juga melakukan migrasi, dan kemudian migrasi itu tidak berubah - jika Anda memerlukan sesuatu yang berbeda dalam model, maka Anda mengubah model dan melakukan migrasi baru bersama perubahan Anda.
Dalam proyek greenfield, Anda sering dapat menghapus migrasi dan memulai kembali dari awal dengan migrasi 0001_ ketika Anda merilis, tetapi jika Anda memiliki kode produksi, Anda tidak bisa (meskipun Anda dapat menekan migrasi menjadi satu).
Solusi yang biasanya digunakan adalah, sebelum apa pun digabungkan menjadi master, pengembang harus melakukan perubahan jarak jauh. Jika ada konflik dalam versi migrasi, dia harus mengganti nama migrasi lokalnya (migrasi jarak jauh telah dijalankan oleh pengembang lain, dan, berpotensi, dalam produksi), menjadi N + 1.
Selama pengembangan mungkin baik-baik saja untuk tidak melakukan migrasi (jangan tambahkan abaikan, jangan lakukan additu). Tetapi setelah Anda masuk ke produksi, Anda akan membutuhkannya untuk menjaga skema tetap sinkron dengan perubahan model.
Anda kemudian perlu mengedit file, dan mengubah dependencieske versi jarak jauh terbaru.
Ini bekerja untuk migrasi Django, serta aplikasi serupa lainnya (sqlalchemy + alembic, RoR, dll).
Memiliki banyak file migrasi di git itu berantakan. Hanya ada satu file di folder migrasi yang tidak boleh Anda abaikan. File tersebut adalah file init .py, Jika Anda mengabaikannya, python tidak akan lagi mencari submodul di dalam direktori, jadi setiap upaya untuk mengimpor modul akan gagal. Jadi pertanyaannya adalah bagaimana cara mengabaikan semua file migrasi kecuali init .py? Solusinya adalah: Tambahkan '0 * .py' ke file .gitignore dan itu melakukan pekerjaan dengan sempurna.
Semoga ini bisa membantu seseorang.
Abaikan migrasi, jika Anda memiliki DB terpisah untuk lingkungan Pengembangan, Pementasan dan Produksi. Untuk dev. tujuan Anda dapat menggunakan DB sqlite lokal dan bermain dengan migrasi secara lokal. Saya akan merekomendasikan Anda untuk membuat empat cabang tambahan:
Master - Bersihkan kode baru tanpa migrasi. Tidak ada yang terhubung ke cabang ini. Digunakan untuk review kode saja
Pembangunan - perkembangan sehari-hari. Dorong / tarik diterima. Setiap pengembang sedang mengerjakan sqlite DB
Cloud_DEV_env - lingkungan DEV cloud / server jarak jauh. Tarik saja. Pertahankan migrasi secara lokal di mesin, yang digunakan untuk penerapan kode dan migrasi jarak jauh database Dev
Cloud_STAG_env - lingkungan STAG cloud / server jarak jauh. Tarik saja. Simpan migrasi secara lokal di mesin, yang digunakan untuk penerapan kode dan migrasi jarak jauh database Stag
Cloud_PROD_env - lingkungan DEV cloud / server jarak jauh. Tarik saja. Pertahankan migrasi secara lokal di mesin, yang digunakan untuk penerapan kode dan migrasi jarak jauh database Prod
Catatan: 2, 3, 4 - migrasi dapat disimpan dalam repo tetapi harus ada aturan ketat penggabungan permintaan tarik, jadi kami memutuskan untuk mencari seseorang, yang bertanggung jawab atas penerapan, jadi satu-satunya orang yang memiliki semua file migrasi - penerapan kami -er. Dia menyimpan migrasi DB jarak jauh setiap kali ada perubahan dalam Model.
Jawaban singkat yang
saya usulkan tidak termasuk migrasi di repo. Setelah kode digabungkan, jalankan saja ./manage.py makemigrationsdan Anda siap.
Jawaban panjang Saya tidak berpikir Anda harus memasukkan file migrasi ke dalam repo. Ini akan merusak status migrasi di lingkungan pengembang orang lain dan lingkungan panggung dan panggung lainnya. (lihat komentar Sugar Tang untuk contoh).
Dalam sudut pandang saya, tujuan migrasi Django adalah untuk menemukan celah antara status model sebelumnya dan status model baru, dan kemudian serialisasi kesenjangan. Jika model Anda berubah setelah penggabungan kode, Anda dapat melakukannya dengan mudah makemigrationsuntuk mengetahui celahnya. Mengapa Anda ingin menggabungkan migrasi lain secara manual dan hati-hati ketika Anda dapat mencapai yang sama secara otomatis dan bebas bug? Dokumentasi Django mengatakan,
Mereka * (migrasi) * dirancang untuk sebagian besar otomatis
; tolong tetap seperti itu. Untuk menggabungkan migrasi secara manual, Anda harus memahami sepenuhnya apa yang telah diubah oleh orang lain dan ketergantungan apa pun dari perubahan tersebut. Itu banyak overhead dan rawan kesalahan. Jadi file model pelacakan sudah cukup.
Ini adalah topik yang bagus di alur kerja. Saya terbuka untuk opsi lain.
manage.py makemigrations --mergebekerja sepenuhnya secara otomatis untuk saya.
makemigrations some_app, tidak hanya model di bawah kendali anggota itu yang akan terpengaruh, tetapi model terkait lainnya juga akan terpengaruh. Artinya, file migrasi (00 * _ *) di aplikasi lain akan diubah. Dan itu menyebabkan banyak masalah konflik selama mendorong atau menarik dari GitHub. Karena saat ini sistem kami belum siap produksi, kami tinggal.gitignorefile migrasi. Kami masih belum tahu bagaimana menyelesaikannya saat sistem berproduksi. Apakah ada yang punya solusi?