Haruskah file database (skrip dll.) Di kontrol sumber? Jika demikian, apa metode terbaik untuk menyimpannya dan memperbaruinya di sana?

Apakah bahkan ada kebutuhan untuk file database untuk berada di kontrol sumber karena kita dapat meletakkannya di server pengembangan di mana semua orang dapat menggunakannya dan membuat perubahan jika diperlukan. Tapi, maka kita tidak bisa mendapatkannya kembali jika seseorang mengacaukannya.

Pendekatan apa yang paling baik digunakan untuk database pada kontrol sumber?

Iya. Anda harus dapat membangun kembali setiap bagian dari sistem Anda dari kontrol sumber termasuk database (dan saya juga akan berdebat data statis tertentu).

Dengan asumsi bahwa Anda tidak ingin memiliki alat untuk melakukannya, saya sarankan Anda menyertakan yang berikut ini:

• Skrip pembuatan untuk struktur tabel dasar termasuk skema, pengguna, tabel, kunci, default, dan sebagainya.
• Tingkatkan skrip (baik mengubah struktur tabel atau memigrasikan data dari skema sebelumnya ke skema baru)
• Skrip pembuatan untuk prosedur tersimpan, indeks, tampilan, pemicu (Anda tidak perlu khawatir tentang peningkatan untuk ini karena Anda hanya menimpa apa yang ada di sana dengan skrip penciptaan yang benar)
• Skrip pembuatan data untuk menjalankan sistem (satu pengguna, semua data daftar pilih statis, hal semacam itu)

Semua skrip harus menyertakan pernyataan drop yang sesuai dan ditulis sehingga dapat dijalankan sebagai pengguna mana pun (jadi termasuk skema terkait / awalan pemilik jika relevan).

Proses pemutakhiran / penandaan / percabangan harus persis seperti sisa kode sumber - ada gunanya melakukannya jika Anda tidak dapat mengaitkan versi database dengan versi aplikasi.

Kebetulan, ketika Anda mengatakan orang hanya dapat memperbarui server uji, saya berharap Anda maksud server pengembangan. Jika pengembang memperbarui server uji dengan cepat, maka Anda sedang melihat dunia yang penuh kesusahan dalam hal mencari tahu apa yang perlu Anda lepaskan.

Iya.

apa metode terbaik untuk menyimpannya dan memperbaruinya di sana?

Um Tulis skrip pembangun skrip. Periksa setelah membuat perubahan. Lihat sebelum menjalankannya.

Sulit untuk menentukan apa yang Anda minta.

Tulis skrip migrasi skema formal. Periksa setelah pengujian. Periksa sebelum menjalankannya.

Apa lagi yang ada di sana?

Apa yang terjadi adalah bahwa perubahan skema berubah menjadi masalah degil karena skema berkembang secara organik melalui serangkaian perubahan tidak berdokumen.

Evolusi organik ini membuat migrasi skema lebih sulit karena tidak ada sumber "otoritatif" untuk apa yang seharusnya ada di sana. Ada dua versi produksi yang sedikit berbeda, versi pementasan, versi QA dan delapan versi pengembangan. Semuanya sedikit berbeda.

Jika ada satu, sumber otoritatif, maka migrasi skema hanyalah delta antara versi terakhir dan versi ini.

Iya

Skrip basis data (ddl, dml) adalah kode. Semua kode harus dalam sistem kontrol versi.

Migrasi

• Gunakan migrasi basis data

Memungkinkan Anda menggunakan file db yang sama dalam pengembangan, qa dan rilis.

• Lepaskan ke database dengan nomor rilis

Simpan nomor rilis di suatu tempat untuk diaudit, banyak yang menyimpannya di db itu sendiri. Setiap rilis akan terdiri dari migrasi yang akan membawa database ke versi yang benar.

Ada alat seperti liquibase yang dimaksudkan untuk memberikan kontrol sumber untuk basis data. Sulit untuk mempertahankan skrip perubahan / pembaruan dalam alat kontrol sumber reguler Anda seperti banyak perusahaan melakukannya dan Anda tidak dapat selalu menggunakan kembali database dari awal.

Kami juga telah mencoba mengotomatiskan ini dengan alat perbandingan basis data (bandingkan master vs pelanggan db) dan itu membantu, tetapi Anda tidak dapat mempercayai alat tersebut 100%, Anda pasti perlu proses peninjauan juga.

Iya

Dan selanjutnya, Anda akan menginginkan cabang .

Saya menggunakan Git untuk cabang:

• untuk pengembangan per-fitur (seperti yang kami lakukan untuk pengembangan reguler dari sisa aplikasi)

• dan satu untuk server produksi juga karena pelanggan yang menggunakan aplikasi juga membuat konten.

Dengan begitu, Anda mendapatkan manfaat dari kontrol sumber dan percabangan untuk kode sumber dan basis data (dan file apa pun yang Anda miliki).

Saya belum menemukan sistem all-in-one [untuk PostgreSQL], jadi saya harus menulis fungsi / skrip untuk mengindeks ulang dengan benar ketika menggabungkan cabang (mis. Indeks apa pun dari cabang produksi tidak boleh dimodifikasi karena pelanggan mengandalkan mereka sedangkan indeks + kunci asing dari cabang pengembangan yang bersinggungan dengan konten produksi harus diindeks ulang: itu tidak akan bekerja untuk semua aplikasi, tetapi itu mencakup semua kasus aplikasi kita sehingga cukup baik).

Tetapi ide umumnya adalah bahwa isi basis data adalah bagian penting dari aplikasi, dan semua sumber daya harus dalam kontrol sumber , ya, Anda harus menggunakan kontrol sumber untuk basis data juga.

Untuk Java, tim kami menggunakan Flyway , yang kami temukan sangat mudah digunakan dan kuat.

Jika Anda bekerja di Ruby, Rails memiliki Migrasi yang juga merupakan cara ampuh untuk mengatasi masalah ini.

Liquibase telah disebutkan - ini adalah solusi yang baik tetapi saya merasa lebih rumit daripada alternatif seperti Flyway.

Juga, perangkat lunak RedGate menawarkan produk yang disebut SQL Source Control yang dirancang untuk SQL Server. Saya belum menggunakannya sendiri, tetapi salah satu rekan kerja saya mengatakan itu hebat.

Inilah masalah yang sering saya lihat ketika tidak ada kontrol versi atau manajemen perubahan pada database pengembangan. Programmer A membuat perubahan ke tabel, tampilan, atau proc. Programmer B membuat perubahan ke hal yang sama dan menimpa apa yang Programmer A lakukan. Atau, DBA mengembalikan DB produksi untuk pengembangan dan menimpa perubahan. Saya telah melihat hal-hal semacam ini menyebabkan banyak kesedihan yang berulang kali tidak lucu. Dan ini hanya pada sistem pengembangan. Hal-hal dapat menjadi sangat berantakan ketika melakukan staging / test dan bahkan server produksi terjebak dalam hal ini.

Kontrol versi database tidak harus sama dengan kontrol versi kode reguler agar efektif. Namun, beberapa jenis kontrol perubahan dan cadangan riwayat akan mencegah banyak masalah.

Anggap saja sebagai "Kontrol Versi" daripada "Kontrol Sumber". Ini menyiratkan bahwa Anda dapat melihat seluruh sejarah skrip tertentu itu. Apakah Anda dapat membangun kembali basis data ke bentuk saat ini akan lebih menjadi masalah praktik Anda mengenai skrip ini dan kerangka kerja apa pun yang digunakan untuk membuatnya.

Untuk proyek PHP / MySQL kami, kami telah menggunakan alat kecil (sekali) bernama Ladder . Ini dirancang untuk memfasilitasi pertumbuhan organik dari database dari waktu ke waktu. Semua migrasi untuk proyek disimpan dalam kontrol revisi / sumber / versi, dan dilacak bersama dengan kode.

Ini mendukung penambahan / pengubahan / penurunan kolom, menjalankan kueri, menambah / menjatuhkan indeks, kendala, dll, dll. Ini akan melacak keadaan basis data, dan menerapkan migrasi yang hilang. Ini juga memungkinkan Anda untuk "mundur dalam waktu" dengan menentukan migrasi yang Anda harus lakukan. ( php ladder.php migrate 15)

Oh, dan tambahan terbaru adalah basis data yang berbeda. Jalankan diff-saveperintah, tambahkan dan hapus beberapa kolom dari database, dan jalankan diffperintahnya. Anda akan melihat kode migrasi yang dibuat secara otomatis berdasarkan status basis data.

DataGrove memecahkan beberapa masalah yang disebutkan di sini (oleh jfrankcarr , misalnya).

Ini melacak semua perubahan ke DB dan memungkinkan Anda untuk menyimpan versi seluruh negara DB ke repositori. Ini kemudian memungkinkan Anda untuk menelurkan banyak salinan virtual dari DB yang sama, sehingga setiap pengembang atau DBA dapat memiliki salinannya sendiri-sendiri (setiap salinan virtual dapat dihasilkan dari versi yang berbeda). Ini akan memastikan tidak ada yang menimpa kode / perubahan orang lain. Setiap salinan virtual juga dilacak ke repositori yang sama sehingga semua negara DB dapat dengan mudah dibagikan dan diciptakan kembali.

Saya juga ingin membawa alat pemantauan yang dapat juga digunakan sebagai alat versi data. Alat yang saya bicarakan adalah MONyog, sebenarnya ini adalah alat pemantauan MySQL tetapi dengan sedikit peretasan, kita dapat dengan mudah menggunakannya sebagai versi data.

Tetapi sebelum melangkah lebih jauh saya akan mengutip bahwa tidak akan disarankan untuk memasang seluruh database untuk versi. Adalah pembunuh nyata untuk melacak perubahan untuk set data tertentu.

MONyog memiliki fitur yang disebut CSO (Custom SQL Objects), yang dapat memonitor perubahan dalam set data tertentu. Menambahkan CSO dijelaskan di sini . Sekarang di bagian riwayat monitor MONyog Anda bisa mendapatkan perubahan selama periode waktu tertentu. Terbaik, ini memberikan laporan visual di halaman html. Laporan akan terlihat seperti ini