SSDT dapat dibandingkan dengan Liquibase / Flyway karena melakukan apa yang mereka lakukan tetapi dengan mengambil pendekatan yang berbeda. Dengan SSDT Anda memiliki lingkungan pengembangan sehingga Anda mendapatkan hal-hal seperti pergi ke definisi, menemukan referensi dan akal budi serta kemampuan untuk mengkompilasi proyek menjadi dacpac dan kemudian menggunakan dacpac itu ke database.
Cara SSDT (dan redgate sql membandingkan cara) untuk melakukan deloyment adalah dengan menyatakan apa yang Anda inginkan jadi jika Anda ingin mengubah tabel yang terlihat seperti:
create table a(id int)
ke tabel yang terlihat seperti:
create table a(id int, another_column varchar(12))
dengan SSDT Anda cukup mengubah definisi tabel Anda menjadi yang kedua dan membiarkan SSDT khawatir tentang cara memutakhirkannya (dapatkah itu mengubah tabel, menambah kolom, atau melakukan perubahan urutan kolom sehingga Anda perlu membangun kembali tabel, dll).
Dengan Liquibase (DbUp, ReadyRoll, metode manual, dll.) Yang Anda lakukan dalam hal ini harus menulis sendiri tabel alter dan pastikan Anda menjalankan skrip dalam urutan yang benar, pertimbangkan skenario ini:
- Rilis 1 - buat kolom halo di atas meja
- Rilis 2 - ganti nama kolom halo menjadi joe_blogs
- Rilis 3 - ganti nama kolom joe_blogs menjadi halo
- Rilis 4 - buat kolom joe_blogs
Jika ada rilis yang terlewatkan, tidak ada yang berikutnya yang dapat dilanjutkan.
Manfaat skrip pemutakhiran (Liquibase, DbUp, dll):
- Anda memiliki kontrol penuh atas skrip
- DBA / Pengembang terbiasa dengan ini
Manfaat membandingkan / menggabungkan (SSDT, Redgate SQL Bandingkan):
- Tidak perlu menulis skrip pemutakhiran
- Sangat mudah untuk mendapatkan versi spesifik mana saja dengan hanya membandingkan dan menggabungkan versi itu
Kerugian dari skrip upgrade:
- Harus dijalankan secara berurutan
- Mengandalkan manusia tidak membuat kesalahan
- Bisa lambat terutama jika Anda memiliki banyak perubahan
- Kecuali jika tim Anda adalah basis data yang sangat disiplin dalam lingkungan yang berbeda (pengembang, pengujian, pementasan, dll) sering menjadi tidak sinkron sehingga pengujian apa pun tidak valid
- Menurunkan versi rilis berarti menulis kebalikan dari semua skrip yang telah Anda tulis
Kerugian menggunakan membandingkan / menggabungkan:
- Alat tidak 100% tepercaya, mungkin tidak adil
- SSDT memerlukan proyek yang berfungsi, banyak banyak basis data yang memiliki kode yang tidak benar-benar dikompilasi atau dijalankan (bayangkan tabel yang dijatuhkan tetapi bukan prosedur dll), saya telah melihat ini di sekitar 8/10 basis data yang telah saya warisi :)
- Banyak DBA / pengembang ragu untuk menyerah mengembangkan SSMS / notepad
Secara pribadi saya benar-benar berpikir SSDT adalah lingkungan pengembangan profesional dan itu berarti bahwa saya dapat berkonsentrasi pada penulisan kode dan tes yang berguna daripada menulis skrip upgrade yang dengan sendirinya hanya sarana untuk mencapai tujuan.
Anda meminta pendapat jadi begini :)
ed