Bagikan melalui


Strategi untuk Pengembangan dan Penyebaran Database (C#)

oleh Scott Mitchell

Saat menyebarkan aplikasi berbasis data untuk pertama kalinya Anda dapat menyalin database secara membabi buta di lingkungan pengembangan ke lingkungan produksi. Tetapi melakukan salinan buta dalam penyebaran berikutnya akan menimpa data apa pun yang dimasukkan ke dalam database produksi. Sebaliknya, menyebarkan database melibatkan penerapan perubahan yang dilakukan pada database pengembangan sejak penyebaran terakhir ke database produksi. Tutorial ini memeriksa tantangan ini dan menawarkan berbagai strategi untuk membantu menahun dan menerapkan perubahan yang dilakukan pada database sejak penyebaran terakhir.

Pengantar

Seperti yang dibahas dalam tutorial sebelumnya, menyebarkan aplikasi ASP.NET memerlukan penyalinan konten yang berkaitan dari lingkungan pengembangan ke lingkungan produksi. Penyebaran bukanlah peristiwa satu kali, melainkan sesuatu yang terjadi setiap kali versi baru perangkat lunak dirilis atau ketika bug atau masalah keamanan telah diidentifikasi dan ditangani. Saat menyalin ASP.NET halaman, gambar, file JavaScript, dan file tersebut lainnya ke lingkungan produksi, Anda tidak perlu khawatir dengan bagaimana file ini telah diubah sejak penyebaran terakhir. Anda dapat menyalin file secara membabi buta ke produksi, menimpa konten yang ada. Sayangnya, kesederhanaan ini tidak meluas untuk menyebarkan database.

Saat menyebarkan aplikasi berbasis data untuk pertama kalinya Anda dapat menyalin database secara membabi buta di lingkungan pengembangan ke lingkungan produksi. Tetapi melakukan salinan buta dalam penyebaran berikutnya akan menimpa data apa pun yang dimasukkan ke dalam database produksi. Sebaliknya, menyebarkan database melibatkan penerapan perubahan yang dilakukan pada database pengembangan sejak penyebaran terakhir ke database produksi. Tutorial ini memeriksa tantangan ini dan menawarkan berbagai strategi untuk membantu menahun dan menerapkan perubahan yang dilakukan pada database sejak penyebaran terakhir.

Tantangan Penyebaran Database

Sebelum aplikasi berbasis data disebarkan untuk pertama kalinya, hanya ada satu database, yaitu database di lingkungan pengembangan, itulah sebabnya ketika menyebarkan aplikasi berbasis data untuk pertama kalinya Anda dapat menyalin database secara membabi buta di lingkungan pengembangan ke lingkungan produksi. Tetapi setelah aplikasi disebarkan, ada dua salinan database: satu dalam pengembangan dan satu dalam produksi.

Antara penyebaran, database pengembangan dan produksi dapat menjadi tidak sinkron. Meskipun skema database produksi tetap tidak berubah, skema database pengembangan dapat berubah saat fitur baru ditambahkan. Anda dapat menambahkan atau menghapus kolom, tabel, tampilan, atau prosedur tersimpan. Mungkin juga ada data penting yang ditambahkan ke database pengembangan. Banyak aplikasi berbasis data termasuk tabel pencarian yang diisi dengan data khusus aplikasi yang dikodekan secara permanen yang tidak dapat diedit pengguna. Misalnya, situs web lelang mungkin memiliki daftar drop-down dengan pilihan yang menjelaskan kondisi item yang dilelang: Baru, Seperti Baru, Bagus, dan Adil. Daripada mengodekan secara permanen opsi ini langsung dalam daftar drop-down, biasanya lebih baik menempatkannya dalam tabel database. Jika, selama pengembangan, kondisi baru bernama Miskin ditambahkan ke tabel, maka saat menyebarkan aplikasi, rekaman yang sama ini perlu ditambahkan ke tabel pencarian dalam database produksi.

Idealnya, menyebarkan database akan melibatkan penyalinan database dari pengembangan ke produksi. Tetapi perlu diingat bahwa setelah Anda menyebarkan aplikasi dan melanjutkan pengembangan, database produksi sedang diisi dengan data nyata dari pengguna nyata. Oleh karena itu, jika Anda hanya menyalin database dari pengembangan ke produksi pada penyebaran berikutnya, Anda akan menimpa database produksi dan kehilangan data yang ada. Hasil bersihnya adalah bahwa menyebarkan database mendidih untuk menerapkan perubahan yang dilakukan pada database pengembangan sejak penyebaran terakhir.

Karena menyebarkan database melibatkan penerapan perubahan dalam skema dan, mungkin, data sejak penyebaran terakhir, riwayat perubahan harus dipertahankan (atau ditentukan pada waktu penyebaran) sehingga perubahan tersebut dapat diterapkan pada produksi. Ada berbagai teknik untuk mengelola dan menerapkan perubahan pada model data.

Menentukan Garis Besar

Untuk mempertahankan perubahan pada database aplikasi, Anda harus memiliki beberapa status awal, garis besar tempat perubahan diterapkan. Pada satu ekstrem, status awal bisa menjadi database kosong tanpa tabel, tampilan, atau prosedur tersimpan. Garis besar seperti itu menghasilkan log perubahan besar karena harus menyertakan pembuatan semua tabel database, tampilan, dan prosedur tersimpan bersama dengan perubahan apa pun yang dilakukan setelah penyebaran awal. Di ujung lain spektrum, Anda dapat mengatur garis besar sebagai versi database yang awalnya disebarkan ke lingkungan produksi. Pilihan ini menghasilkan log perubahan yang jauh lebih kecil karena hanya menyertakan perubahan yang dilakukan pada database setelah penyebaran pertama. Ini adalah pendekatan yang saya sukai. Dan tentu saja Anda dapat memilih pendekatan yang lebih tengah jalan, mendefinisikan garis besar sebagai beberapa titik antara pembuatan awal database dan kapan database pertama kali disebarkan.

Setelah Anda memilih garis besar, pertimbangkan untuk membuat skrip SQL yang dapat dijalankan untuk membuat ulang versi dasar. Skrip seperti itu memungkinkan untuk membuat ulang versi dasar database dengan cepat. Fungsionalitas ini sangat berguna dalam proyek yang lebih besar, di mana mungkin ada beberapa pengembang yang mengerjakan proyek atau lingkungan tambahan, seperti pengujian atau penahapan, yang masing-masing membutuhkan salinan database mereka sendiri.

Ada berbagai alat yang Anda inginkan untuk menghasilkan skrip SQL dari versi garis besar. Dari SQL Server Management Studio (SSMS) Anda bisa mengklik kanan database, masuk ke submenu Tugas, dan pilih opsi Hasilkan Skrip. Ini meluncurkan Panduan Skrip, yang dapat Anda instruksikan untuk menghasilkan file yang berisi perintah SQL untuk membuat objek database Anda. Opsi lain adalah Panduan Penerbitan Database, yang dapat menghasilkan perintah SQL untuk tidak hanya membuat skema database, tetapi juga data dalam tabel database. Panduan Penerbitan Database diperiksa secara rinci kembali dalam tutorial Menyebarkan Database . Terlepas dari alat apa yang Anda gunakan, pada akhirnya Anda harus memiliki file skrip yang dapat Anda gunakan untuk membuat ulang versi dasar database Anda, jika kebutuhan muncul.

Mendanai Perubahan Database dalam Prose

Cara paling sederhana untuk mempertahankan log perubahan pada model data selama fase pengembangan adalah dengan merekam perubahan prosa. Misalnya, jika selama pengembangan aplikasi yang sudah disebarkan, Anda menambahkan kolom baru ke Employees tabel, menghapus kolom dari Orders tabel, dan menambahkan tabel baru (ProductCategories), Anda akan mempertahankan file teks atau dokumen Microsoft Word dengan riwayat berikut:

Ubah Tanggal Ubah Detail
2009-02-03: Menambahkan kolom DepartmentID (int, NOT NULL) ke Employees tabel. Menambahkan batasan kunci asing dari Departments.DepartmentID ke Employees.DepartmentID.
2009-02-05: Kolom yang dihapus TotalWeight dari Orders tabel. Data sudah diambil dalam rekaman terkait OrderDetails .
2009-02-12: ProductCategories Membuat tabel. Ada tiga kolom: ProductCategoryID (int, , IDENTITY), CategoryNameNOT NULL(nvarchar(50), NOT NULL), dan Active (bit, NOT NULL). Menambahkan batasan kunci primer ke ProductCategoryID, dan nilai default 1 ke Active.

Ada sejumlah kelemahan untuk pendekatan ini. Sebagai permulaan, tidak ada harapan untuk otomatisasi. Setiap kali perubahan ini perlu diterapkan ke database - seperti ketika aplikasi disebarkan - pengembang harus menerapkan setiap perubahan secara manual, satu per satu. Selain itu, jika Anda perlu membangun kembali versi database tertentu dari garis besar menggunakan log perubahan, melakukannya akan membutuhkan lebih banyak waktu seiring bertambahnya ukuran log. Kelemahan lain dari metode ini adalah bahwa kejelasan dan tingkat detail setiap entri log perubahan diserahkan kepada orang yang merekam perubahan. Dalam tim dengan beberapa pengembang, beberapa mungkin membuat entri yang lebih rinci, lebih mudah dibaca, atau lebih tepat daripada yang lain. Selain itu, kesalahan ketik dan kesalahan entri data terkait manusia lainnya dimungkinkan.

Manfaat utama mendkumentasikan perubahan database dalam prosa adalah kesederhanaan. Anda tidak perlu terbiasa dengan sintaks SQL untuk membuat dan mengubah objek database. Sebagai gantinya, Anda dapat merekam perubahan dalam prosa dan mengimplementasikannya melalui antarmuka pengguna grafis SQL Server Management Studio.

Mempertahankan prosa log perubahan Anda adalah, diakui, tidak terlalu canggih dan tidak akan bekerja dengan baik dengan proyek tertentu, seperti yang besar dalam cakupan, memiliki perubahan yang sering pada model data, atau melibatkan beberapa pengembang. Tetapi saya telah melihat pendekatan ini bekerja dengan cukup baik dalam proyek kecil satu orang yang hanya memiliki perubahan sesekali pada model data dan di mana pengembang solo tidak memiliki latar belakang yang kuat dalam sintaks SQL untuk membuat dan mengubah objek database.

Catatan

Meskipun informasi dalam log perubahan adalah, secara teknis, hanya diperlukan sampai waktu penyebaran, saya sarankan menyimpan riwayat perubahan. Tetapi daripada mempertahankan satu file log perubahan yang terus berkembang, pertimbangkan untuk memiliki file log perubahan yang berbeda untuk setiap versi database. Biasanya Anda ingin membuat versi database setiap kali disebarkan. Dengan mempertahankan log perubahan, Anda dapat, mulai dari garis besar, membuat ulang versi database apa pun dengan menjalankan skrip log perubahan mulai dari versi 1 dan melanjutkan hingga Anda mencapai versi yang perlu Anda buat ulang.

Merekam Pernyataan Perubahan SQL

Kelemahan utama mempertahankan log perubahan dalam prosa adalah kurangnya otomatisasi. Idealnya, menerapkan perubahan database pada database produksi pada waktu penyebaran akan semampu mengklik tombol untuk menjalankan skrip daripada harus melakukan daftar instruksi secara manual. Otomatisasi tersebut dimungkinkan dengan mempertahankan log perubahan yang berisi perintah SQL yang digunakan untuk mengubah model data.

Sintaks SQL mencakup sejumlah pernyataan untuk membuat dan memodifikasi berbagai objek database. Misalnya, pernyataan CREATE TABLE, saat dijalankan, membuat tabel baru dengan kolom dan batasan yang ditentukan. Pernyataan ALTER TABLE memodifikasi tabel yang sudah ada, menambahkan, menghapus, atau memodifikasi kolom atau batasannya. Ada juga pernyataan untuk membuat, memodifikasi, dan menghilangkan indeks, tampilan, fungsi yang ditentukan pengguna, prosedur tersimpan, pemicu, dan objek database lainnya.

Kembali ke contoh kami sebelumnya, gambar yang selama pengembangan aplikasi yang sudah disebarkan, Anda menambahkan kolom baru ke Employees tabel, menghapus kolom dari Orders tabel, dan menambahkan tabel baru (ProductCategories). Tindakan tersebut akan menghasilkan file log perubahan dengan perintah SQL berikut:

-- Add the DepartmentID column 

ALTER TABLE [Employees] ADD [DepartmentID] 
int NOT NULL 

-- Add a foreign key constraint between Departments.DepartmentID and Employees.DepartmentID
ALTER TABLE [Employees] ADD 
CONSTRAINT [FK_Departments_DepartmentID]
      FOREIGN 
KEY ([DepartmentID]) 
      REFERENCES 
[Departments] ([DepartmentID]) 

-- Remove TotalWeight column from Orders
ALTER TABLE [Orders] DROP COLUMN 
[TotalWeight] 

-- Create the ProductCategories table

CREATE TABLE [ProductCategories]
(
      [ProductCategoryID] 
int IDENTITY(1,1) NOT NULL,
      [CategoryName] 
nvarchar(50) NOT NULL,
      [Active] 
bit NOT NULL CONSTRAINT [DF_ProductCategories_Active]  DEFAULT 
((1)),
      CONSTRAINT 
[PK_ProductCategories] PRIMARY KEY CLUSTERED ( [ProductCategoryID])
)

Mendorong perubahan ini ke database produksi pada waktu penyebaran adalah operasi satu klik: buka SQL Server Management Studio, sambungkan ke database produksi Anda, buka jendela Kueri Baru, tempel konten log perubahan, dan klik Jalankan untuk menjalankan skrip.

Menggunakan Alat Perbandingan untuk Menyinkronkan Model Data

Mendokumentasikan perubahan database dalam prosa itu mudah, tetapi menerapkan perubahan mengharuskan pengembang untuk membuat setiap perubahan pada database produksi satu per satu; mendokumentasikan perubahan perintah SQL membuat penerapan perubahan tersebut pada database produksi menjadi mudah dan cepat seperti mengklik tombol, tetapi memerlukan pembelajaran dan penguasaan pernyataan dan sintaks SQL untuk membuat dan mengubah objek database. Alat perbandingan database mengambil yang terbaik dari kedua pendekatan dan membuang yang terburuk.

Alat perbandingan database membandingkan skema atau data dua database dan menampilkan laporan ringkasan yang menunjukkan kepada Anda perbedaan database. Kemudian, dengan mengklik tombol, Anda dapat menghasilkan perintah SQL untuk menyinkronkan satu atau beberapa objek database. Singkatnya, Anda dapat menggunakan alat perbandingan database untuk membandingkan database pengembangan dan produksi pada waktu penyebaran, menghasilkan file yang berisi perintah SQL yang, ketika dijalankan, akan menerapkan perubahan pada skema database produksi sehingga mencerminkan skema database pengembangan.

Ada berbagai alat perbandingan database pihak ketiga yang ditawarkan oleh banyak vendor yang berbeda. Salah satu contohnya adalah SQL Compare, oleh Red Gate Software. Mari kita telusuri proses penggunaan SQL Compare untuk membandingkan dan menyinkronkan skema database pengembangan dan produksi.

Catatan

Pada saat penulisan ini, versi SQL Compare saat ini adalah versi 7.1, dengan Edisi Standar seharga $395. Anda dapat mengikuti dengan mengunduh uji coba gratis selama 14 hari.

Saat SQL Compare memulai kotak dialog Proyek Perbandingan terbuka, memperlihatkan proyek Perbandingan SQL yang disimpan. Buat proyek baru. Ini meluncurkan wizard Konfigurasi Proyek, yang meminta informasi tentang database untuk dibandingkan (lihat Gambar 1). Masukkan informasi untuk database lingkungan pengembangan dan produksi.

Membandingkan Database Pengembangan dan Produksi

Gambar 1: Bandingkan Database Pengembangan dan Produksi (Klik untuk melihat gambar ukuran penuh)

Catatan

Jika database lingkungan pengembangan Anda adalah file database SQL Express Edition di App_Data folder situs web Anda, Anda harus mendaftarkan database di server database SQL Server Express untuk memilihnya dari kotak dialog yang diperlihatkan di Gambar 1. Cara termudah untuk mencapainya adalah dengan membuka SQL Server Management Studio (SSMS), menyambungkan ke server database SQL Server Express, dan melampirkan database. Jika Anda tidak memiliki SSMS yang terinstal di komputer Anda, Anda dapat mengunduh dan menginstal SQL Server Management Studio gratis.

Selain memilih database untuk dibandingkan, Anda juga dapat menentukan berbagai pengaturan perbandingan dari tab Opsi. Salah satu opsi yang mungkin ingin Anda aktifkan adalah "Abaikan batasan dan nama indeks." Ingat bahwa dalam tutorial sebelumnya kami menambahkan objek database layanan aplikasi ke database pengembangan dan produksi. Jika Anda menggunakan aspnet_regsql.exe alat ini untuk membuat objek ini pada database produksi, Maka Anda akan menemukan bahwa kunci primer dan nama batasan unik berbeda antara database pengembangan dan produksi. Akibatnya, SQL Compare akan menandai semua tabel layanan aplikasi sebagai berbeda. Anda dapat membiarkan "Abaikan batasan dan nama indeks" tidak dicentang dan menyinkronkan nama batasan, atau menginstruksikan SQL Bandingkan untuk mengabaikan perbedaan ini.

Setelah memilih database untuk dibandingkan (dan meninjau opsi perbandingan), klik tombol Bandingkan Sekarang untuk memulai perbandingan. Selama beberapa detik berikutnya, SQL Compare memeriksa skema dua database dan menghasilkan laporan tentang perbedaannya. Saya sengaja membuat beberapa modifikasi pada database pengembangan untuk menunjukkan bagaimana perbedaan tersebut dicatat dalam antarmuka Perbandingan SQL. Seperti yang ditunjukkan Gambar 2, saya telah menambahkan BirthDate kolom ke Authors tabel, menghapus ISBN kolom dari Books tabel, dan menambahkan tabel baru, Ratings, yang dimaksudkan untuk memungkinkan pengguna mengunjungi situs menilai buku yang ditinjau.

Catatan

Perubahan model data yang dilakukan dalam tutorial ini dilakukan untuk mengilustrasikan menggunakan alat perbandingan database. Anda tidak akan menemukan perubahan ini dalam database dalam tutorial mendatang.

SQL Bandingkan Lists Perbedaan Antara Database Pengembangan dan Produksi

Gambar 2: SQL Bandingkan Lists Perbedaan Antara Database Pengembangan dan Produksi (Klik untuk melihat gambar ukuran penuh)

Perbandingan SQL memecah objek database menjadi grup, dengan cepat menunjukkan objek apa yang ada di kedua database tetapi berbeda, objek mana yang ada dalam satu database tetapi tidak yang lain, dan objek mana yang identik. Seperti yang Anda lihat, ada dua objek yang ada di kedua database tetapi berbeda: Authors tabel, yang memiliki kolom ditambahkan, dan Books tabel, yang memiliki satu dihapus. Ada satu objek yang hanya ada dalam database pengembangan, yaitu tabel yang baru dibuat Ratings . Dan ada 117 objek yang identik di kedua database.

Memilih objek database menampilkan jendela Perbedaan SQL, yang memperlihatkan perbedaan objek ini. Jendela Perbedaan SQL, yang ditampilkan di bagian bawah di Gambar 2, menyoroti bahwa Authors tabel dalam database pengembangan memiliki BirthDate kolom , yang tidak ditemukan dalam Authors tabel pada database produksi.

Setelah meninjau perbedaan dan memilih objek mana yang ingin Anda sinkronkan, langkah selanjutnya adalah menghasilkan perintah SQL yang diperlukan untuk memperbarui skema database produksi agar sesuai dengan database pengembangan. Ini dicapai melalui Wizard Sinkronisasi. Wizard Sinkronisasi mengonfirmasi objek apa yang akan disinkronkan dan meringkas rencana tindakan (lihat Gambar 3). Anda dapat segera menyinkronkan database atau menghasilkan skrip dengan perintah SQL yang dapat dijalankan pada waktu luang Anda.

Gunakan Wizard Sinkronisasi untuk Menyinkronkan Skema Database Anda

Gambar 3: Gunakan Panduan Sinkronisasi untuk Menyinkronkan Skema Database Anda (Klik untuk melihat gambar ukuran penuh)

Alat perbandingan database seperti Red Gate Software s SQL Compare membuat penerapan perubahan pada skema database pengembangan ke database produksi semampu titik dan klik.

Catatan

Perbandingan SQL membandingkan dan menyinkronkan dua skema database. Sayangnya, itu tidak membandingkan dan menyinkronkan data dalam dua tabel database. Perangkat Lunak Red Gate memang menawarkan produk bernama SQL Data Compare yang membandingkan dan menyinkronkan data antara dua database, tetapi ini adalah produk terpisah dari SQL Compare dan biaya $395 lainnya.

Mengambil Aplikasi Offline Selama Penyebaran

Seperti yang telah kita lihat di seluruh tutorial ini, penyebaran adalah proses yang melibatkan beberapa langkah: menyalin halaman ASP.NET, halaman master, file CSS, file JavaScript, gambar, dan konten lain yang diperlukan dari lingkungan pengembangan ke lingkungan produksi; menyalin informasi konfigurasi khusus lingkungan produksi, jika diperlukan; dan menerapkan perubahan pada model data sejak penyebaran terakhir. Bergantung pada jumlah file dan kompleksitas perubahan database Anda, langkah-langkah ini dapat berlangsung dari beberapa detik hingga beberapa menit untuk diselesaikan. Selama jendela ini, aplikasi web dalam fluks dan pengguna yang mengunjungi situs mungkin mengalami kesalahan atau perilaku tak terduga.

Saat menyebarkan situs web, yang terbaik adalah mengambil aplikasi web "offline" sampai penyebaran selesai. Mengambil aplikasi offline (dan membawanya kembali setelah proses penyebaran selesai) sem mudah seperti mengunggah file dan kemudian menghapusnya. Dimulai dengan ASP.NET 2.0, hanya adanya file bernama app_offline.htm dalam direktori akar aplikasi mengambil seluruh situs web "offline." Setiap permintaan ke halaman ASP.NET di situs tersebut secara otomatis direspons app_offline.htm dengan konten file. Setelah file tersebut dihapus, aplikasi kembali online.

Mengambil aplikasi offline selama penyebaran, maka, semampu mengunggah app_offline.htm file ke direktori akar lingkungan produksi sebelum memulai proses penyebaran dan kemudian menghapusnya (atau mengganti nama menjadi sesuatu yang lain) setelah penyebaran selesai. Untuk informasi selengkapnya tentang teknik ini, lihat artikel John Peterson, Mengambil Aplikasi ASP.NET Offline.

Ringkasan

Tantangan utama dalam menyebarkan pusat aplikasi berbasis data sekeliling penyebaran database. Karena ada dua versi database - satu di lingkungan pengembangan dan satu di lingkungan produksi - kedua skema database ini dapat menjadi tidak sinkron karena fitur baru ditambahkan dalam pengembangan. Terlebih lagi, karena database produksi sebagai diisi dengan data nyata dari pengguna nyata, Anda tidak dapat menimpa database produksi dengan database pengembangan yang dimodifikasi seperti yang Anda bisa saat menyebarkan file yang membentuk aplikasi (halaman ASP.NET, file gambar, dan sebagainya). Sebaliknya, menyebarkan database memerlukan penerapan serangkaian perubahan yang tepat yang dilakukan pada database pengembangan pada database produksi sejak penyebaran terakhir.

Tutorial ini melihat tiga teknik untuk mempertahankan dan menerapkan log perubahan database. Pendekatan paling sederhana adalah merekam perubahan prosa. Meskipun taktik ini membuat penerapan perubahan ini pada database produksi menjadi proses manual, itu tidak memerlukan pengetahuan tentang perintah SQL untuk membuat dan mengubah objek database. Pendekatan yang lebih canggih, dan yang jauh lebih mudah dipahami dalam proyek atau proyek yang lebih besar dengan beberapa pengembang, adalah merekam perubahan sebagai serangkaian perintah SQL. Ini sangat menyerbu meluncurkan perubahan ini ke database target. Yang terbaik dari kedua pendekatan dapat dicapai dengan menggunakan alat perbandingan database, seperti Red Gate Software s SQL Compare.

Tutorial ini menyimpulkan fokus kami pada penyebaran aplikasi berbasis data. Serangkaian tutorial berikutnya melihat cara menanggapi kesalahan di lingkungan produksi. Kita akan melihat cara menampilkan halaman kesalahan yang ramah alih-alih Layar Kuning Kematian. Dan kita akan melihat cara mencatat detail kesalahan dan cara memperingatkan Anda ketika kesalahan tersebut terjadi.

Selamat Pemrograman!