Saya telah memperbarui posting asli saya di bawah ini untuk mencerminkan perubahan dalam versi terbaru dari SQL Source Control (3.0) dan SQL Compare (10.1).
Karena pertanyaan ini diajukan lebih dari setahun yang lalu, tanggapan saya mungkin tidak begitu membantu Anda, tetapi bagi orang lain yang mungkin sedang mengevaluasi SSC, saya pikir saya akan memberikan dua sen saya. Kami baru saja mulai menggunakan SQL Source Control (SSC) dan secara keseluruhan saya cukup puas dengannya sejauh ini. Itu memang memiliki beberapa kebiasaan, terutama jika Anda bekerja di lingkungan basis data bersama (sebagai lawan dari setiap pengembang yang bekerja secara lokal) dan khususnya bekerja di lingkungan lama di mana objek dalam basis data yang sama dibagi secara acak di antara tim pengembangan.
Untuk memberikan gambaran singkat tentang bagaimana kami menggunakan produk di organisasi kami, kami bekerja di lingkungan bersama di mana kami semua membuat perubahan pada database pengembangan yang sama, jadi kami melampirkan database bersama ke repositori kontrol sumber. Setiap pengembang bertanggung jawab untuk membuat perubahan pada objek dalam database melalui SQL Server Management Studio (SSMS), dan setelah selesai, mereka dapat melakukan perubahan ke kontrol sumber. Saat kita siap untuk menerapkan ke staging, master build (saya) menggabungkan cabang pengembangan kode database ke cabang utama (staging) dan kemudian menjalankan SQL Bandingkan menggunakan versi repositori cabang utama database sebagai sumber dan live database pementasan sebagai target, dan SQL Bandingkan menghasilkan skrip yang diperlukan untuk menyebarkan perubahan yang dibuat ke lingkungan pementasan. Pementasan untuk penyebaran produksi bekerja dengan cara yang sama. Satu hal penting lainnya yang perlu diperhatikan adalah, mengingat fakta bahwa kami berbagi database yang sama dengan tim pengembangan lain, kami menggunakan fitur SSC bawaan yang memungkinkan Anda membuat filter pada objek database berdasarkan nama, jenis, dll. Kami secara manual mengatur filter pada objek tim khusus kami, tidak termasuk semua objek lain, sehingga kami tidak secara tidak sengaja melakukan perubahan tim pengembangan lain saat kami melakukan penerapan kami.
Jadi secara umum ini adalah produk yang cukup sederhana untuk disiapkan dan digunakan dan ini sangat bagus karena Anda selalu bekerja dengan objek langsung di SSMS, berbeda dengan file skrip yang terputus yang disimpan dalam repositori sumber terpisah yang berisiko tidak sinkron . Ini juga bagus karena SQL Bandingkan menghasilkan skrip penerapan untuk Anda sehingga Anda tidak perlu khawatir tentang memperkenalkan kesalahan seperti yang Anda lakukan jika Anda membuat skrip sendiri. Dan karena SQL Bandingkan adalah produk yang sangat matang dan stabil, Anda dapat merasa cukup yakin bahwa itu akan membuat skrip yang tepat untuk Anda.
Namun demikian, berikut adalah beberapa kebiasaan yang saya temui sejauh ini:
- SSC cukup cerewet dalam hal berkomunikasi dengan server db untuk melacak item database yang tidak sinkron dengan repositori kontrol sumber. Ini polling setiap beberapa milidetik dan jika Anda menambahkan beberapa pengembang semua bekerja melawan database yang sama menggunakan SSC, Anda dapat membayangkan bahwa dba kami tidak terlalu senang. Untungnya, Anda dapat dengan mudah mengurangi frekuensi polling ke sesuatu yang lebih dapat diterima, meskipun dengan mengorbankan pemberitahuan visual responsif saat objek telah diubah.
- Menggunakan fitur pemfilteran objek, Anda tidak dapat dengan mudah mengetahui dari melihat objek di SSMS objek mana yang disertakan dalam filter Anda. Jadi Anda tidak tahu pasti apakah suatu objek berada di bawah kendali sumber, tidak seperti di Visual Studio, di mana ikon digunakan untuk menunjukkan objek yang dikendalikan sumber.
- GUI pemfilteran objek sangat kikuk. Karena fakta bahwa kami bekerja di lingkungan database lama, saat ini tidak ada pemisahan yang jelas antara objek yang dimiliki tim kami dan yang dimiliki oleh tim lain, jadi untuk mencegah kami melakukan/menyebarkan perubahan tim lain secara tidak sengaja , kami telah menyiapkan skema pemfilteran untuk secara eksplisit menyertakan setiap objek spesifik yang kami miliki. Seperti yang dapat Anda bayangkan, ini menjadi sangat rumit, dan karena GUI untuk mengedit filter diatur untuk memasukkan satu objek pada satu waktu, itu bisa menjadi sangat menyakitkan, terutama mencoba mengatur lingkungan Anda untuk pertama kalinya (saya akhirnya menulis aplikasi untuk melakukan ini). Ke depannya, kami membuat skema baru untuk aplikasi kami untuk memfasilitasi pemfilteran objek dengan lebih baik (selain menjadi praktik yang lebih baik).
- Menggunakan model database bersama, pengembang diizinkan untuk melakukan perubahan tertunda apa pun ke database yang dikontrol sumber, bahkan jika perubahan itu bukan milik mereka. SSC memberi Anda peringatan jika Anda mencoba memeriksa banyak perubahan bahwa perubahan ini mungkin bukan milik Anda, tetapi selain itu Anda sendiri. Saya benar-benar menemukan ini sebagai salah satu "keanehan" SSC yang paling berbahaya.
- SQL Compare saat ini tidak dapat membagikan filter objek yang dibuat oleh SSC, jadi Anda harus membuat filter yang cocok secara manual di SQL Compare, jadi ada bahaya bahwa filter ini tidak sinkron. Saya baru saja memotong dan menempelkan filter dari file filter SSC yang mendasarinya ke dalam filter proyek Bandingkan SQL untuk menghindari berurusan dengan GUI pemfilteran objek yang kikuk. Saya percaya bahwa versi SQL Bandingkan berikutnya akan memungkinkannya untuk berbagi filter dengan SSC, jadi setidaknya masalah ini hanya masalah jangka pendek. (CATATAN:Masalah ini telah diselesaikan di versi terbaru SQL Bandingkan. Bandingkan SQL sekarang dapat menggunakan filter objek yang dibuat oleh SSC.)
- SQL Compare juga tidak dapat dibandingkan dengan repositori database SSC saat diluncurkan secara langsung. Itu harus diluncurkan dari dalam SSMS. Saya percaya bahwa versi SQL Bandingkan berikutnya akan menyediakan fungsionalitas ini, jadi sekali lagi ini adalah masalah jangka pendek lainnya. (CATATAN:Masalah ini telah diselesaikan di versi terbaru SQL Bandingkan.)
- Terkadang SQL Bandingkan tidak dapat membuat skrip yang tepat untuk mendapatkan database target dari satu keadaan ke keadaan lain, biasanya dalam kasus di mana Anda memperbarui skema tabel yang ada yang tidak kosong, jadi saat ini Anda harus tulis skrip manual dan kelola prosesnya sendiri. Untungnya, ini akan diatasi melalui "skrip migrasi" dalam rilis SSC berikutnya, dan dari melihat versi rilis awal produk, tampaknya penerapan fitur baru ini telah dipikirkan dan dirancang dengan baik. (CATATAN:Fungsionalitas skrip migrasi telah dirilis secara resmi. Namun, saat ini tidak mendukung percabangan. Jika Anda ingin menggunakan skrip migrasi, Anda perlu menjalankan sql dibandingkan dengan cabang kode pengembangan asli... Anda memeriksa perubahan Anda... yang cukup kikuk dan telah memaksa saya untuk memodifikasi proses pembuatan saya dengan cara yang kurang ideal untuk mengatasi keterbatasan ini. Semoga ini akan diatasi dalam rilis mendatang.)
Secara keseluruhan, saya cukup senang dengan produk dan dengan respons Redgate terhadap umpan balik pengguna dan arah yang diambil produk. Produk ini sangat mudah digunakan dan dirancang dengan baik, dan saya merasa bahwa dalam satu atau dua rilis berikutnya produk tersebut mungkin akan memberi kita sebagian besar, jika tidak semua, dari apa yang kita butuhkan.
