Bagaimana Anda membangun database dari kontrol sumber?

Ada beberapa diskusi di wiki komunitas SO tentang apakah objek database harus dikontrol versi. Namun, saya belum melihat banyak diskusi tentang praktik terbaik untuk membuat proses otomatisasi build untuk objek database.

Ini telah menjadi poin diskusi yang kontroversial bagi tim saya - terutama karena developer dan DBA sering kali memiliki tujuan, pendekatan, dan kekhawatiran yang berbeda saat mengevaluasi manfaat dan risiko pendekatan otomatisasi untuk penerapan database.

Saya ingin mendengar beberapa ide dari komunitas SO tentang praktik apa yang telah efektif di dunia nyata.

Saya menyadari bahwa agak subjektif praktik mana yang benar-benar terbaik, tetapi menurut saya dialog yang baik tentang pekerjaan apa yang dapat bermanfaat bagi banyak orang.

Berikut adalah beberapa pertanyaan teaser saya tentang area yang menjadi perhatian dalam topik ini. Ini tidak dimaksudkan sebagai daftar yang pasti - melainkan sebagai titik awal bagi orang untuk membantu memahami apa yang saya cari.

1. Haruskah lingkungan pengujian dan produksi dibangun dari kendali sumber?
   
   • Haruskah keduanya dibuat menggunakan otomatisasi - atau haruskah produksi dengan cara menyalin objek dari lingkungan pengujian yang stabil dan diselesaikan?
   • Bagaimana Anda menangani perbedaan potensial antara lingkungan pengujian dan produksi dalam skrip penerapan?
   • Bagaimana Anda menguji bahwa skrip penerapan akan bekerja secara efektif terhadap produksi seperti yang mereka lakukan dalam pengujian?
2. Jenis objek apa yang harus dikontrol versi?
   • Hanya kode (prosedur, paket, pemicu, java, dll)?
   • Indeks?
   • Kendala?
   • Definisi Tabel?
   • Tabel Ubah Skrip? (mis. skrip ALTER)
   • Segala sesuatu?
3. Jenis objek apa yang tidak boleh dikontrol versi?
   • Urutan?
   • Hibah?
   • Akun Pengguna?
4. Bagaimana seharusnya objek database diatur dalam repositori SCM Anda?
   • Bagaimana Anda menangani hal-hal satu kali seperti skrip konversi atau skrip ALTER?
   • Bagaimana Anda menangani objek yang dihentikan dari database?
   • Siapa yang harus bertanggung jawab untuk mempromosikan objek dari pengembangan ke tingkat pengujian?
   • Bagaimana Anda mengoordinasikan perubahan dari beberapa pengembang?
   • Bagaimana Anda menangani percabangan untuk objek database yang digunakan oleh banyak sistem?
5. Pengecualian apa, jika ada, yang dapat dibuat secara wajar untuk proses ini?
   • Masalah keamanan?
   • Data dengan masalah de-identifikasi?
   • Skrip yang tidak dapat sepenuhnya otomatis?
6. Bagaimana Anda bisa membuat prosesnya tangguh dan dapat dilaksanakan?
   • Untuk kesalahan pengembang?
   • Untuk masalah lingkungan yang tidak terduga?
   • Untuk pemulihan bencana?
7. Bagaimana Anda meyakinkan para pengambil keputusan bahwa manfaat DB-SCM benar-benar membenarkan biayanya?
   • Bukti anekdot?
   • Riset industri?
   • Rekomendasi praktik terbaik industri?
   • Banding kepada otoritas yang diakui?
   • Analisis Biaya / Manfaat?
8. Siapa yang harus "memiliki" objek database dalam model ini?
   • Pengembang?
   • DBA?
   • Analis Data?
   • Lebih dari satu?

Berikut beberapa jawaban atas pertanyaan Anda:

1. Haruskah lingkungan pengujian dan produksi dibangun dari kendali sumber? IYA
   • Haruskah keduanya dibuat menggunakan otomatisasi - atau haruskah produksi dengan cara menyalin objek dari lingkungan pengujian yang stabil dan diselesaikan?
   • Otomatisasi untuk keduanya. JANGAN menyalin data antar lingkungan
   • Bagaimana Anda menangani perbedaan potensial antara lingkungan pengujian dan produksi dalam skrip penerapan?
   • Gunakan template, sehingga sebenarnya Anda akan menghasilkan sekumpulan skrip yang berbeda untuk setiap lingkungan (mis. Referensi ke sistem eksternal, database yang ditautkan, dll.)
   • Bagaimana Anda menguji bahwa skrip penerapan akan bekerja secara efektif terhadap produksi seperti yang mereka lakukan dalam pengujian?
   • Anda mengujinya di lingkungan pra-produksi: uji penerapan pada salinan persis lingkungan produksi (database dan kemungkinan sistem lain)
2. Jenis objek apa yang harus dikontrol versi?
   • Hanya kode (prosedur, paket, pemicu, java, dll)?
   • Indeks?
   • Kendala?
   • Definisi Tabel?
   • Tabel Ubah Skrip? (mis. skrip ALTER)
   • Segala sesuatu?
   • Semuanya, dan:
     • Jangan lupa data statis (daftar pencarian, dll.), Jadi Anda tidak perlu menyalin data APA PUN antar lingkungan
     • Simpan hanya versi terbaru dari skrip database (versi dikontrol, tentu saja), dan
     • Simpan skrip ALTER: 1 skrip BESAR (atau direktori skrip dengan nama like 001_AlterXXX.sql, sehingga menjalankannya dalam urutan alami akan meningkatkan dari versi A ke B)
3. Jenis objek apa yang tidak boleh dikontrol versi?
   • Urutan?
   • Hibah?
   • Akun Pengguna?
   • lihat 2. Jika pengguna / peran Anda (atau nama pengguna teknis) berbeda di antara lingkungan, Anda masih dapat membuat skrip menggunakan templat (lihat 1.)
4. Bagaimana seharusnya objek database diatur dalam repositori SCM Anda?
   • Bagaimana Anda menangani hal-hal satu kali seperti skrip konversi atau skrip ALTER?
   • lihat 2.
   • Bagaimana Anda menangani objek yang dihentikan dari database?
   • dihapus dari DB, dihapus dari batang / ujung kendali sumber
   • Siapa yang harus bertanggung jawab untuk mempromosikan objek dari pengembangan ke tingkat pengujian?
   • dev / test / jadwal rilis
   • Bagaimana Anda mengoordinasikan perubahan dari beberapa pengembang?
   • coba JANGAN membuat database terpisah untuk setiap pengembang. Anda menggunakan kontrol sumber, bukan? dalam hal ini pengembang mengubah database dan memeriksa skrip. agar sepenuhnya aman, buat ulang database dari skrip selama nightly build
   • Bagaimana Anda menangani percabangan untuk objek database yang digunakan oleh banyak sistem?
   • yang sulit: cobalah untuk menghindari dengan segala cara.
5. Pengecualian apa, jika ada, yang dapat dibuat secara wajar untuk proses ini?
   • Masalah keamanan?
   • jangan simpan password untuk test / prod. Anda dapat mengizinkannya untuk dev, terutama jika Anda memiliki rekonstruksi DB harian / malam otomatis
   • Data dengan masalah de-identifikasi?
   • Skrip yang tidak dapat sepenuhnya otomatis?
   • mendokumentasikan dan menyimpan dengan info rilis / skrip ALTER
6. Bagaimana Anda bisa membuat prosesnya tangguh dan dapat dilaksanakan?
   • Untuk kesalahan pengembang?
   • diuji dengan build harian dari awal, dan bandingkan hasilnya dengan peningkatan bertahap (dari versi A ke B menggunakan ALTER). bandingkan skema yang dihasilkan dan data statis
   • Untuk masalah lingkungan yang tidak terduga?
   • gunakan kontrol versi dan backup
   • bandingkan skema database PROD dengan apa yang Anda pikirkan, terutama sebelum penerapan. SuperDuperCool DBA mungkin telah memperbaiki bug yang tidak pernah ada di sistem tiket Anda :)
   • Untuk pemulihan bencana?
7. Bagaimana Anda meyakinkan para pengambil keputusan bahwa manfaat DB-SCM benar-benar membenarkan biayanya?
   • Bukti anekdot?
   • Riset industri?
   • Rekomendasi praktik terbaik industri?
   • Banding kepada otoritas yang diakui?
   • Analisis Biaya / Manfaat?
   • jika pengembang dan DBA setuju, Anda tidak perlu meyakinkan siapa pun, saya pikir (Kecuali jika Anda membutuhkan uang untuk membeli perangkat lunak seperti dbGhost untuk MSSQL)
8. Siapa yang harus "memiliki" objek database dalam model ini?
   • Pengembang?
   • DBA?
   • Analis Data?
   • Lebih dari satu?
   • Biasanya DBA menyetujui model (sebelum check-in atau setelah sebagai bagian dari tinjauan kode). Mereka pasti memiliki objek terkait kinerja. Namun secara umum tim memilikinya [dan majikan, tentu saja :)]

Saya memperlakukan SQL sebagai kode sumber bila memungkinkan

Jika saya dapat menulisnya dalam standar SQL yang sesuai maka biasanya masuk dalam file dalam kendali sumber saya. File tersebut akan mendefinisikan sebanyak mungkin seperti SPs, pernyataan CREATE Tabel.

Saya juga menyertakan data dummy untuk pengujian di kontrol sumber:

1. proj / sql / setup_db.sql
2. proj / sql / dummy_data.sql
3. proj / sql / mssql_specific.sql
4. proj / sql / mysql_specific.sql

Dan kemudian saya mengabstraksi semua kueri SQL saya sehingga saya dapat membangun seluruh proyek untuk MySQL, Oracle, MSSQL atau yang lainnya.

Otomatisasi build dan uji menggunakan skrip build ini karena sama pentingnya dengan sumber aplikasi dan menguji semuanya mulai dari integritas hingga pemicu, prosedur, dan logging.

Kami menggunakan integrasi berkelanjutan melalui TeamCity. Pada setiap check in ke kontrol sumber, database dan semua data pengujian dibangun kembali dari awal, lalu kode, kemudian pengujian unit dijalankan terhadap kode. Jika Anda menggunakan alat pembuat kode seperti CodeSmith, alat itu juga dapat ditempatkan ke dalam proses pembangunan Anda untuk menghasilkan lapisan akses data Anda yang segar dengan setiap bangunan, memastikan bahwa semua lapisan Anda "cocok" dan tidak menghasilkan kesalahan karena parameter SP tidak cocok atau kolom hilang.

Setiap build memiliki koleksi skrip SQL sendiri yang disimpan di direktori $ project \ SQL \ di kontrol sumber, diberi prefiks numerik dan dijalankan secara berurutan. Dengan begitu, kami mempraktikkan prosedur penerapan kami di setiap build.

Bergantung pada tabel pencarian, sebagian besar nilai pencarian kita juga disimpan dalam skrip dan dijalankan untuk memastikan data konfigurasi sesuai dengan yang kita harapkan, misalnya, "reason_codes" atau "country_codes". Dengan cara ini kita dapat membuat perubahan data pencarian di dev, mengujinya, lalu "mempromosikan" melalui QA dan produksi, alih-alih menggunakan alat untuk mengubah nilai pencarian dalam produksi, yang dapat berbahaya untuk waktu kerja.

Kami juga membuat satu set skrip "rollback" yang membatalkan perubahan database kami, jika build ke produksi berjalan kacau. Anda dapat menguji skrip rollback dengan menjalankannya, lalu menjalankan kembali pengujian unit untuk versi build satu di bawah Anda, setelah skrip penerapannya berjalan.

+1 untuk Liquibase : LiquiBase adalah open source (LGPL), pustaka independen basis data untuk melacak, mengelola, dan menerapkan perubahan basis data. Itu dibangun di atas premis sederhana: Semua perubahan database (struktur dan data) disimpan secara deskriptif berbasis XML dan diperiksa ke dalam kontrol sumber. Poin bagusnya, bahwa perubahan DML disimpan secara semantik, bukan hanya diff, sehingga Anda dapat melacak tujuan perubahan.

Itu dapat dikombinasikan dengan kontrol versi GIT untuk interaksi yang lebih baik. Saya akan mengkonfigurasi lingkungan dev-prod kami untuk mencobanya.

Anda juga dapat menggunakan Maven, sistem build Ant untuk membuat kode produksi dari skrip.

Kekurangannya adalah LiquiBase tidak terintegrasi ke dalam IDE SQL yang tersebar luas dan Anda harus melakukan operasi dasar sendiri.

Selain itu, Anda dapat menggunakan DBUnit untuk pengujian DB - alat ini memungkinkan skrip pembuatan data digunakan untuk menguji env produksi Anda dengan pembersihan setelahnya.

MENURUT OPINI SAYA:

1. Simpan DML dalam file sehingga Anda dapat membuat versinya.
2. Otomatiskan proses pembuatan skema dari kontrol sumber.
3. Untuk tujuan pengujian, pengembang dapat menggunakan DB lokal yang dibuat dari kontrol sumber melalui sistem build + memuat pengujian Data dengan skrip, atau skrip DBUnit (dari Kontrol Sumber).
4. LiquiBase memungkinkan Anda menyediakan "run sequence" dari skrip untuk menghormati dependensi.
5. Harus ada tim DBA yang memeriksa master brunch dengan SEMUA perubahan sebelum penggunaan produksi. Maksud saya, mereka memeriksa trunk / branch dari DBA lain sebelum melakukan ke trunk MASTER. Sehingga master selalu konsisten dan produksi siap.

Kami menghadapi semua masalah yang disebutkan dengan perubahan kode, penggabungan, penulisan ulang dalam database produksi penagihan kami. Topik ini sangat bagus untuk menemukan semua hal itu.

Dengan mengajukan "pertanyaan penggoda", Anda tampaknya lebih tertarik pada diskusi daripada pendapat seseorang tentang jawaban akhir. Milis aktif (> 2500 anggota) agileDatabases telah menjawab banyak pertanyaan ini dan, menurut pengalaman saya, merupakan forum yang canggih dan sipil untuk diskusi semacam ini.

Saya pada dasarnya setuju dengan setiap jawaban yang diberikan oleh van . Untuk lebih banyak wawasan, baseline saya untuk manajemen database adalah seri K. Scott Allen (harus dibaca, IMHO. Dan sepertinya pendapat Jeff juga).

• Objek database selalu dapat dibangun kembali dari awal dengan meluncurkan sebuah file SQL tunggal (yang dapat sendiri memanggil file SQL lainnya): Create.sql. Ini dapat mencakup penyisipan data statis (daftar ...).
• Skrip SQL diberi parameter sehingga tidak ada informasi yang bergantung pada lingkungan dan / atau sensitif disimpan dalam file biasa.
• Saya menggunakan file batch kustom untuk peluncuran Create.sql: Create.cmd. Tujuannya terutama untuk memeriksa prasyarat (alat, variabel lingkungan ...) dan mengirim parameter ke skrip SQL. Itu juga dapat memuat data statis secara massal dari file CSV untuk masalah kinerja.
• Biasanya, kredensial pengguna sistem akan diteruskan sebagai parameter ke Create.cmdfile.

IMHO, pemuatan data dinamis harus membutuhkan langkah lain, tergantung pada lingkungan Anda. Pengembang ingin memuat database mereka dengan pengujian, sampah atau tanpa data sama sekali, sementara di sisi lain, manajer produksi ingin memuat data produksi. Saya akan mempertimbangkan untuk menyimpan data pengujian dalam kontrol sumber juga (untuk memudahkan pengujian unit, misalnya).

Setelah versi pertama database dimasukkan ke dalam produksi, Anda tidak hanya perlu membuat skrip (terutama untuk pengembang), tetapi juga meningkatkan skrip (berdasarkan prinsip yang sama):

• Harus ada cara untuk mengambil versi dari database (saya menggunakan prosedur tersimpan, tetapi tabel juga bisa).
• Sebelum merilis versi baru, saya membuat Upgrade.sqlfile (yang dapat memanggil yang lain) yang memungkinkan peningkatan versi N-1 ke versi N (N adalah versi yang dirilis). Saya menyimpan skrip ini di bawah folder bernama N-1.
• Aku punya file batch yang melakukan upgrade: Upgrade.cmd. Itu dapat mengambil versi saat ini (CV) dari database melalui pernyataan SELECT sederhana, meluncurkan Upgrade.sqlskrip yang disimpan di bawah CVfolder, dan mengulang sampai tidak ada folder yang ditemukan. Dengan cara ini, Anda dapat meningkatkan secara otomatis dari, katakanlah, N-3 ke N.

Masalahnya adalah:

• Sulit untuk membandingkan skema database secara otomatis, tergantung pada vendor database. Ini dapat menyebabkan skrip peningkatan yang tidak lengkap.
• Setiap perubahan pada lingkungan produksi (biasanya oleh DBA untuk penyetelan kinerja) harus menemukan jalannya ke kontrol sumber juga. Untuk memastikan ini, biasanya mungkin untuk mencatat setiap modifikasi ke database melalui pemicu. Log ini disetel ulang setelah setiap peningkatan.
• Idealnya, perubahan yang dimulai DBA harus menjadi bagian dari proses rilis / peningkatan jika memungkinkan.

Mengenai objek database seperti apa yang ingin Anda miliki di bawah kendali sumber? Ya, saya akan mengatakan sebanyak mungkin, tetapi tidak lebih ;-) Jika Anda ingin membuat pengguna dengan kata sandi, berikan mereka kata sandi default (login / login, praktis untuk tujuan pengujian unit), dan ubah kata sandi menjadi operasi manual . Ini sering terjadi dengan Oracle di mana skema juga pengguna ...

Kami memiliki proyek Silverlight kami dengan database MSSQL dalam kontrol versi Git. Cara termudah adalah untuk memastikan Anda punya slimmed bawah basis data (konten bijaksana), dan melakukan lengkap sampah dari fe Visual Studio. Kemudian Anda dapat melakukan 'sqlcmd' dari skrip build Anda untuk membuat ulang database pada setiap mesin dev.

Untuk penerapan, hal ini tidak mungkin karena database terlalu besar: itulah alasan utama untuk memilikinya di database sejak awal.

Saya sangat percaya bahwa DB harus menjadi bagian dari kontrol sumber dan sebagian besar dari proses pembangunan. Jika dalam kontrol sumber maka saya memiliki kode pengaman yang sama saat menulis prosedur tersimpan di SQL seperti yang saya lakukan saat menulis kelas di C #. Saya melakukan ini dengan memasukkan direktori skrip DB di bawah pohon sumber saya. Direktori skrip ini tidak selalu memiliki satu file untuk satu objek dalam database. Itu akan menyebalkan! Saya mengembangkan di db saya hanya seperti yang saya lakukan di proyek kode saya. Kemudian ketika saya siap untuk check-in, saya melakukan perbedaan antara versi terakhir database saya dan yang saat ini saya kerjakan. Saya menggunakan Bandingkan SQL untuk ini dan itu menghasilkan skrip dari semua perubahan. Skrip ini kemudian disimpan ke direktori db_update saya dengan konvensi penamaan khusus 1234_TasksCompletedInThisIteration di mana nomor tersebut adalah nomor berikutnya dalam kumpulan skrip yang sudah ada, dan namanya menjelaskan apa yang sedang dilakukan dalam check in ini. Saya melakukan ini karena sebagai bagian dari proses pembangunan saya, saya mulai dengan database baru yang kemudian dibangun secara terprogram menggunakan skrip di direktori ini. Saya menulis tugas NAnt khusus yang mengulangi setiap skrip yang mengeksekusi isinya pada db kosong. Jelas jika saya membutuhkan beberapa data untuk masuk ke db maka saya juga memiliki skrip penyisipan data. Ini memiliki banyak manfaat juga. Satu, semua barang saya berversi. Kedua, setiap build adalah build baru yang berarti tidak akan ada hal licik yang masuk ke proses pengembangan saya (seperti data kotor yang menyebabkan keanehan dalam sistem). Ketiga, ketika orang baru ditambahkan ke tim pengembang, mereka hanya perlu mendapatkan yang terbaru dan pengembang lokal mereka dibuat untuk mereka dengan cepat. Empat, saya dapat menjalankan kasus uji (saya tidak menyebutnya sebagai "uji unit"!) Pada basis data saya karena status basis data disetel ulang dengan setiap build (artinya saya dapat menguji repositori saya tanpa khawatir menambahkan data uji ke db).

Ini bukan untuk semua orang.

Ini bukan untuk setiap proyek. Saya biasanya mengerjakan proyek lapangan hijau yang memberi saya kemudahan ini!

Daripada berdebat tentang menara putih, berikut adalah solusi yang telah bekerja dengan sangat baik untuk saya pada masalah dunia nyata.

Membangun database dari awal dapat diringkas seperti mengelola skrip sql.

DBdeploy adalah alat yang akan memeriksa status database saat ini - misalnya skrip apa yang sebelumnya telah dijalankan terhadapnya, skrip apa yang tersedia untuk dijalankan dan oleh karena itu skrip apa yang diperlukan untuk dijalankan.

Ini kemudian akan menyusun semua skrip yang dibutuhkan bersama-sama dan menjalankannya. Kemudian merekam skrip mana yang telah dijalankan.

Ini bukan alat tercantik atau yang paling rumit - tetapi dengan pengelolaan yang cermat, alat ini dapat bekerja dengan sangat baik. Ini open source dan mudah dikembangkan. Setelah menjalankan skrip ditangani dengan baik, menambahkan beberapa komponen tambahan seperti skrip shell yang memeriksa skrip terbaru dan menjalankan dbdeploy terhadap instance tertentu dapat dengan mudah dicapai.

Lihat pengantar yang bagus di sini:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Anda mungkin menemukan bahwa Liquibase menangani banyak hal yang Anda cari.

Setiap pengembang harus memiliki database lokalnya sendiri, dan menggunakan kontrol kode sumber untuk memublikasikan ke tim. Solusi saya ada di sini: http://dbsourcetools.codeplex.com/ Selamat bersenang-senang, - Nathan