Menangani perubahan skema database saat mendorong versi baru

Selama masa perkembangan yang berat, skema basis data berubah dengan cepat dan terus-menerus, dan pada saat dorongan mingguan kami untuk pengembangan beta muncul, skema tersebut telah berubah begitu banyak sehingga satu-satunya pilihan yang masuk akal adalah dengan menghapus semua tabel yang saya bisa dan salin versi baru dari basis data dev saya. Jelas, ini tidak akan berfungsi begitu kami meluncurkan, karena nuking data produksi adalah resep untuk bencana, jadi saya bertanya-tanya strategi apa yang ada di luar sana untuk mengelola perubahan skema database dari satu versi / revisi ke yang lain?

Beberapa yang saya temukan atau alami:

1. Nuke-and-dump langsung dari satu basis data ke basis data lain (apa yang saya lakukan sekarang)
2. Mempertahankan file UPDATE.sql dengan pernyataan SQL yang dijalankan melalui skrip atau dengan tangan.
3. Mempertahankan file update.php dengan nilai "db-schema-version" yang sesuai di database aktif

Opsi ketiga tampaknya menjadi yang paling masuk akal, tetapi masih ada kemungkinan query SQL yang dibangun dengan buruk gagal di tengah-skrip, meninggalkan database dalam keadaan setengah-diperbarui, mengharuskan pemulihan cadangan.

Sepertinya bukan masalah, tapi itu memang terjadi, karena kita sebagai sebuah tim, kita menggunakan phpMyAdmin, dan sepertinya aku bahkan tidak bisa mengandalkan diri saya sendiri mengingat menyalin pernyataan SQL yang dieksekusi untuk menempel ke file update.php. Setelah Anda menavigasi ke halaman lain, saya harus menulis ulang pernyataan SQL dengan tangan, atau membalikkan perubahan saya dan melakukannya lagi.

Saya kira apa yang saya harapkan adalah solusi yang tidak memengaruhi alur kerja pengembangan kami yang sudah mapan?

Mengotomatisasikan. Mengotomatisasikan. Mengotomatisasikan.

Anda berada di jalur yang benar dengan nomor versi DB yang eksplisit, tetapi saya akan melangkah lebih jauh dan membuat kode secara eksplisit menyadari skema apa yang diharapkan untuk dikerjakan (misalnya dengan melakukan skrip DDL yang sebenarnya dan meminta pengupdate menguraikannya ); maka pada saat pembaruan Anda hanya perlu menemukan skema yang ada melalui metadata database dan INSERT / DROP / ALTER seperlunya, tidak peduli dari versi apa ke versi apa yang Anda perbarui. (Anda juga bisa menyimpan nomor versi eksplisit di dalam basis data itu sendiri dan mengirimkan seluruh riwayat skema dengan installer sehingga Anda bahkan tidak memerlukan penemuan skema.)

Galat sintaksis potensial dalam skrip SQL pembaruan adalah masalah, tetapi Anda dapat menyelesaikannya dengan memverifikasi bahwa pembaru hanya dapat menghasilkan pernyataan DDL yang benar. (Bukti formal hampir tidak pernah berharga dalam pengembangan perangkat lunak perusahaan - terlalu banyak upaya untuk terlalu sedikit jaminan - tetapi saya merasa bahwa integritas basis data adalah salah satu dari sedikit pengecualian: SQL dasar bukan bahasa yang sulit untuk ditangkap secara formal, dan manfaat dari melindungi data produksi sangat besar sehingga hampir semua upaya di muka satu kali dibenarkan, terutama jika harus bekerja untuk pemasangan tanpa pengawasan,)

Versi skema database adalah cara untuk pergi - setiap versi hanya memiliki satu perubahan ke database, atau setidaknya perubahan yang dapat dikembalikan secara keseluruhan. DBDeploy adalah alat yang hebat untuk mengotomatisasi itu.

Beberapa hal yang saya pelajari bermanfaat adalah:

1. Selalu uji perubahan Anda secara lokal, dan uji kode Anda dengannya, hanya ALTERoperan saja tidak cukup
2. Anda harus menyinkronkan yang mana yang dapat melakukan perubahan mereka terlebih dahulu - halaman wiki sederhana tempat Anda dapat "mengambil nomor" bekerja sangat baik untuk tim saya.
3. Jangan mencoba memperbaiki perubahan yang rusak, tambahkan kontra-perubahan baru untuk meniadakannya, itu jauh tidak menyakitkan
4. Kode Anda bergantung pada perubahan itu - pastikan untuk menautkan masalah di sistem pelacakan bug Anda dengan perubahan DB. Itu sangat membantu saat menggunakan waktu.
5. Sertakan perubahan DB ke CI Anda - lakukan terapkan perubahan Anda ke database CI di komit. Juga, jika Anda memiliki tes apa pun yang menggunakan database, jalankan dengan komit.

Karena Anda menggunakan phpMyAdmin, maka saya menganggap Anda juga menggunakan MySQL.

Lihatlah diagram EER Model di MySQL Workbench. Mereka sangat membantu saya dalam memelihara dan memperbarui skema.

Pertama, Anda dapat menyinkronkan model dengan sumber basis data. Sehingga perubahan dalam diagram didorong sebagai perintah ALTER TABLE. Hal ini memungkinkan Anda untuk melakukan perubahan skema Anda pada diagram, tetap selalu up to date sambil juga mendorong pembaruan ke database pengembangan Anda bila diperlukan.

Kedua, Anda dapat merekayasa balik diagram EER dari sumber basis data. Yang bisa berguna dengan mengambil perubahan pada database pengembangan, dan memperbarui database produksi karena akan menghitung perbedaannya.

Ketiga, ini dapat digunakan untuk membantu menciptakan SQL yang harus masuk ke file "update.sql" Anda.

CONS:

Pemicu dan kendala basis data adalah masalah dengan updater sinkronisasi. Sepertinya tidak tahu urutan yang benar. Batasan kunci asing sering menghasilkan kesalahan, tetapi ini dapat diatasi dengan mengedit SQL yang dihasilkannya.

Ini bukan alat migrasi data. Setiap perubahan yang berada di luar skema murni masih akan membutuhkan SQL khusus.

Lihatlah http://south.aeracode.org - ini adalah perpustakaan migrasi DB untuk Django (kerangka Python) tetapi:

1. Anda bisa mendapatkan ide-ide hebat dari itu (dan bahkan mungkin menemukan klon PHP)
2. Anda benar-benar dapat menggunakannya secara terpisah dari Django untuk mengelola tabel aplikasi PHP / MySQL Anda.

Itu juga dapat menghasilkan skrip pembaruan skema; itu juga menangani perubahan pembalikan secara otomatis sebagian besar waktu.