Haruskah pengembang diizinkan untuk menggunakan LocalDB vs contoh "pengembangan"?

Sama seperti inti dari pertanyaan yang telah diposting di sini sebelumnya di sekitar " Haruskah pengembang dapat meminta basis data produksi? " Saya ingin menyampaikan pendapat Anda tentang topik lain yang sangat menjengkelkan!

Banyak perusahaan mencegah pengembang menginstal SQL Server Express dan sejenisnya pada mesin pengembangan, alih-alih mempromosikan penggunaan SQL Server pengembangan terpusat.

Secara khusus ini dilakukan untuk memastikan:

• Konsistensi tingkat tambalan antara server pengembangan dan produksi
  
• Kemampuan untuk membuktikan dan memvalidasi tambalan di atas
  
• Keamanan data; hanya data di server pengembangan yang digunakan untuk pengembangan
  
• Dapat dipulihkan; data dapat dipulihkan dan masih didukung
  
• Perbedaan collation yang dapat menyebabkan masalah ketika dipindahkan ke produksi

Bagi saya semua argumen ini khususnya tidak valid, mungkin dengan pengecualian dari patching; tetapi jika database pada mesin lokal murni digunakan untuk kegiatan pengembangan, dan bukan pengujian, maka penambalan akan terbukti ketika aplikasi berkembang melalui Test / UAT dll ke Produksi.

Collation tampaknya bukan alasan yang valid, seolah-olah ini adalah masalah untuk database, itu harus ditetapkan ketika itu dibuat pula. Hanya SharePoint dan SCCM yang memiliki masalah tentang ini sejauh yang saya tahu;)

Sekarang, anggap itu HANYA untuk pengembangan, dan basis data tidak akan "dipindahkan" ke produksi dan satu-satunya gerakan adalah:

• Skrip yang membuat basis data yang dihasilkan untuk penyebaran ke produksi
• Cadangan dari sistem pihak ketiga "produksi" dipulihkan dan dipotong jika perlu untuk validasi dan pengembangan

Adakah yang bisa melihat masalah? Apakah saya melewatkan sesuatu?

Saya kira salah satu kekhawatiran terbesar adalah kemampuan untuk contoh db lokal keluar dari tanggal, tapi itu masalah manajemen perangkat lunak, bukan DBA satu IMO.

Iya. Semua pengembang harus memiliki turunan lokal SQL Server DAN turunan SQL server bersama. Mereka ada untuk tujuan yang berbeda. Keduanya dibutuhkan.

Mungkin lingkungan Anda saat ini terlihat seperti ini?

Di atas, beberapa pengembang membuat perubahan dan menempatkannya ke dalam basis data SQL Pengembang bersama. Ini buruk. Microsoft MVP Troy Hunt mendokumentasikan beberapa titik nyeri dari pendekatan kuno ini, di sini . Yang utama adalah ...

1. Ketidakmampuan untuk mengontrol sumber secara tepat. BESAR!
2. Ketidakmampuan untuk menyempurnakan kinerja tanpa hak tingkat server.
3. Ketidakmampuan untuk bereksperimen tanpa memengaruhi orang lain.

Pola ini menyebabkan konflik pengembang. Salah satu gejala konflik adalah penyebaran basis data. Banyak basis data dibuat ketika pengembang mencari ruang yang aman dan terisolasi untuk melakukan pekerjaan mereka. Ada beberapa alasan organisasi berpegang teguh pada pola ini. Yang pertama adalah bahwa mereka belum berinvestasi dalam sistem kontrol sumber yang tepat . Lain adalah bahwa mereka hanya mewarisi pola desain ini dan tidak dapat diganggu untuk mengubahnya. Microsoft telah terus bergerak menjauh dari pola ini dan menjadi sesuatu yang lebih seperti ini ...

Dalam diagram di atas, setiap pengembang menggunakan Visual Studio untuk menulis dan menyimpan perubahan database-nya menjadi contoh lokal SQL Server. Perubahan lokal tersebut kemudian disinkronkan ke sistem kontrol sumber yang sesuai. Di sini setiap pengembang dapat merancang dan bereksperimen di lingkungan di mana perubahannya tidak akan memengaruhi orang lain hingga check-in. Dan pada saat itu konflik akan diselesaikan.

Database lokal yang digunakan di atas bisa edisi LocalDB, Express, atau Developer. Simple-Talk melakukan pekerjaan yang hebat dengan menimbang pro dan kontra dari masing-masing di sini . Ada alasan mengapa Microsoft telah menulis begitu banyak pilihan untuk database pengembangan lokal: LocalDB, Express, Developer .. kita harus menggunakannya!

Jika Anda perlu memilih, sulit untuk tidak membantah bahwa setiap pengembang memiliki versi lokal SQL Server Edisi pengembang diinstal. Ini sepenuhnya gratis dan memiliki paritas fitur dengan edisi Enterprise. Ini akan memungkinkan seluruh tim Anda menjelajah dan mendesain dalam seluruh tumpukan Microsoft BI (SQL Server, SSIS, SSRS, dan SSAS) dengan cara yang aman.

Kita masih bisa menyimpan database komunal, tetapi seharusnya tidak untuk pengembangan, itu harus untuk pengujian. Ini adalah server tempat pengaturan tingkat sistem disinkronkan dengan produksi. Perangkat keras, OS, tambalan, dll.

Bagi saya semua argumen ini sangat tidak valid

Baik. Tetapi mereka tidak untuk kita semua. Mengapa?

Konsistensi tingkat tambalan antara server pengembangan dan produksi

tambalan akan terbukti ketika aplikasi berkembang melalui Tes

Penambalan dapat memperbaiki masalah stabilitas dan korupsi data yang jika tidak akan mengganggu pengembang. Itu harus dilakukan pada mesin pengembangan terlepas.

Keamanan data; hanya data di server pengembangan yang digunakan untuk pengembangan

Berguna untuk memisahkan "apa yang seharusnya" dari "apa yang ada". Pengembang berakhir dengan data sensitif (tidak harus PII, tetapi juga tidak gratis) pada database mereka. Itu terjadi.

Dapat dipulihkan; data dapat dipulihkan dan masih didukung

Sangat penting.

Perbedaan collation yang dapat menyebabkan masalah ketika dipindahkan ke produksi

Hanya SharePoint dan SCCM yang memiliki masalah dalam hal ini

Apa pun yang menggunakan tabel temp akan memiliki masalah ini. Ini sangat umum. Anda tidak pernah menyadarinya karena kebanyakan orang menggunakan standar pemeriksaan di tempat pertama.

dengan asumsi itu HANYA untuk pengembangan, dan basis data tidak akan "dipindahkan" ke produksi

Mengapa kita menganggap itu? Banyak hal berubah dari pengembangan menjadi produksi. Bagaimana lagi Anda mendapatkan produksi yang dihuni untuk pertama kalinya? Skrip murni? Belum tentu ketika aplikasi telah dalam pra-produksi untuk beberapa waktu.

Saya kira salah satu kekhawatiran terbesar adalah kemampuan untuk contoh db lokal keluar dari tanggal, tapi itu masalah manajemen perangkat lunak, bukan DBA satu IMO.

Anda hanya perlu mengeluarkan pernyataan tentang apa yang Anda lakukan dan tidak mendukung dan mengapa.

LocalDB adalah bagian inti dari SSDT sekarang dan tidak dapat dihindari. Namun itu tidak dapat diakses dari jarak jauh dan tidak memiliki komponen penjadwalan (Express memiliki masalah serupa). Oleh karena itu umumnya tidak didukung oleh DBA dalam hal pencadangan, pemeliharaan, dan pemeriksaan integritas.

Tetapi konsolidasi ke server pengembangan terpusat masih masuk akal. Dan sekarang Edisi Pengembang gratis, bahkan lebih mudah untuk membenarkan memiliki lebih banyak.

Secara konseptual, Anda berada di jalur yang benar. Untuk organisasi yang memiliki proses pengembangan yang matang / Siklus Hidup Pengembangan Perangkat Lunak (SDLC) yang mencakup kontrol kode sumber, integrasi berkelanjutan (CI), pengujian otomatis, dan grup TI yang tahu cara mengelola berbagai lingkungan dan workstation agar tetap selaras mengenai tingkat perangkat lunak dan tambalan, dan pengembang berdisiplin yang a) mengikuti proses, b) bekerja bersama, dan c) bekerja dengan TI, kemudian memiliki 50 (atau banyak) pengembangan DB dapat bekerja:

• Ya, perangkat lunak dan tambalan yang konsisten dapat dipertahankan pada sejumlah stasiun kerja.
• Ya, "masalah" apa pun dapat muncul dalam pengujian otomatis dan / atau lingkungan QA / UAT.
• Banyak DB dev tidak mudah untuk dicadangkan, tetapi juga tidak mustahil. Jika menggunakan Roaming Profiles, maka file data yang ada di setiap folder "Pengaturan Lokal" Pengguna Windows mungkin lebih mudah untuk dicadangkan. Atau paling tidak dapat dibuat skrip oleh IT untuk mengambil file dari semua workstation dev, mirip dengan bagaimana mereka akan memastikan bahwa semua sudah ditambal dengan benar.

TETAPI, seperti kebanyakan hal lainnya, itu benar-benar turun ke konteks situasi.

Satu manfaat dari memiliki DB pengembangan yang terpisah adalah bahwa berbagai proyek dapat dikerjakan secara bersamaan tanpa saling mempengaruhi. (Tentu saja, ini mungkin satu-satunya manfaat.)

NAMUN, ada berbagai masalah untuk dipertimbangkan:

• Berapa ukuran tim, dan berapa banyak orang yang mengerjakan proyek tertentu? Semakin banyak orang yang Anda kerjakan dalam suatu proyek, semakin Anda membutuhkan server pengembangan bersama / terpusat sehingga semua orang mendapatkan semua perubahan.

• Dari segi pertimbangan, SQL Server Express LocalDB memang memiliki satu nuansa / batasan / batasan yang sangat menjengkelkan:

  Susunan contoh untuk LocalDB diatur ke SQL_Latin1_General_CP1_CI_AS dan tidak dapat diubah. Basis data level-level, level kolom, dan level ekspresi didukung secara normal. Database yang terkandung mengikuti aturan metadata dan tempdb collations yang didefinisikan oleh Contained Database Collations .

  Instance-level Collation mempengaruhi tidak hanya tempdb(yaitu resolusi objek-nama db-scoped, dan collation default untuk tabel sementara tetapi tidak variabel tabel), tetapi juga nama variabel lokal nama kursor / nama parameter, dan gotonama label. Oleh karena itu, jika server Produksi Anda memiliki Collation tingkat-tingkat dari sesuatu selain SQL_Latin1_General_CP1_CI_AS, maka LocalDB bukanlah pilihan yang baik.

• Apakah Anda menggunakan fitur Edisi Perusahaan? Jika itu hanya masalah melakukan Rebuild Indeks ONLINE, maka itu mungkin tidak masalah. Tetapi jika Anda menggunakan sesuatu seperti Table Partitioning, maka LocalDB bukan pilihan yang baik.

• Mungkin masalah terbesar adalah keseluruhan peningkatan ruang lingkup masalah potensial yang timbul dari perbedaan lingkungan (tingkat OS, tingkat perangkat lunak-tambalan, konfigurasi contoh, konfigurasi DB, dll) yang dapat menyebabkan bug. Meskipun kami telah menerima (dalam arti umum) bahwa pengujian otomatis / QA / UAT akan menemukan masalah ini, itu tidak dijamin ! Mengingat bahwa manusia melakukan kesalahan dan bahwa manusia perlu membuat semua tes yang akan memeriksa semua jalur kode dan semua variasi data (jenis, ukuran, dll.), Sangat mungkin bahwa sejumlah skenario tidak akandiuji dan bahwa bug dapat melewatinya dan tidak diketahui sampai pelanggan menemukannya di Produksi. Ini tetap terjadi, tetapi kemungkinan meningkat ketika menggunakan LocalDB sehingga setiap pengembang dapat memiliki DB pribadi mereka sendiri.

Apa yang sebenarnya terjadi adalah: apa alasan kuat untuk menggunakannya di lingkungan tim? Di berbagai pekerjaan, saya selalu bekerja dalam kelompok di mana ada Pengembang Aplikasi dan Basis Data, dan sementara Pengembang Aplikasi kadang-kadang membuat prosedur tersimpan hanya untuk menyelesaikannya lebih cepat (tidak cukup dari kami DBE), DBE melakukan sebagian besar Pemrograman DB, termasuk memeriksa (yaitu memperbaiki) kode apa pun yang ditulis oleh Pengembang Aplikasi. Menggunakan LocalDB akan membuatnya jauh lebih sulit untuk bekerja dalam grup. Dan ketika menggunakan SQL Server Express (atau bahkan Edisi Pengembang) untuk memiliki contoh pribadi pada setiap stasiun kerja dev yang dapat diakses dari jarak jauh - membuatnya lebih mudah untuk berkolaborasi - tidak pernah benar-benar ada kebutuhan untuk memiliki tingkat isolasi karena jarang terjadi perubahan DB untuk satu proyek berdampak negatif terhadap proyek lain.

Tentu saja, kita yang merupakan Database Engineers (DBEs) memang memiliki instalasi lokal Edisi Express dan / atau Edisi Pengembang. Tetapi, itu adalah untuk melakukan pengujian yang membutuhkan lebih banyak kontrol atas konfigurasi tingkat keamanan / instance, dll daripada yang bisa diizinkan pada server bersama. Dan saya menggunakan instance lokal sesekali, tetapi tidak terlalu sering. Tetapi untuk proyek pribadi saya, saya suka LocalDB dan cukup sering menggunakannya.