Bagikan melalui

Perbedaan Konfigurasi Umum Antara Pengembangan dan Produksi (C#)

  • Artikel

oleh Scott Mitchell

Unduh PDF

Dalam tutorial sebelumnya kami menyebarkan situs web kami dengan menyalin semua file yang bersangkutan dari lingkungan pengembangan ke lingkungan produksi. Namun, tidak jarang ada perbedaan konfigurasi antara lingkungan, yang perlu bahwa setiap lingkungan memiliki file Web.config yang unik. Tutorial ini memeriksa perbedaan konfigurasi umum dan melihat strategi untuk mempertahankan informasi konfigurasi terpisah.

Pengantar

Dua tutorial terakhir berjalan melalui penyebaran aplikasi web sederhana. Tutorial Menyebarkan Situs Anda Menggunakan Klien FTP menunjukkan cara menggunakan klien FTP yang berdiri sendiri untuk menyalin file yang diperlukan dari lingkungan pengembangan hingga produksi. Tutorial sebelumnya, Menyebarkan Situs Anda Menggunakan Visual Studio, melihat penyebaran menggunakan alat Salin Situs Web Visual Studio dan opsi Terbitkan. Dalam kedua tutorial, setiap file di lingkungan produksi adalah salinan file pada lingkungan pengembangan. Namun, tidak jarang file konfigurasi di lingkungan produksi berbeda dari yang ada di lingkungan pengembangan. Konfigurasi aplikasi web disimpan dalam Web.config file dan biasanya menyertakan informasi tentang sumber daya eksternal, seperti database, web, dan server email. Ini juga mengeja perilaku aplikasi dalam situasi tertentu, seperti tindakan yang harus diambil ketika pengecualian yang tidak tertangani terjadi.

Saat menyebarkan aplikasi web, penting bahwa informasi konfigurasi yang benar berakhir di lingkungan produksi. Dalam kebanyakan kasus Web.config , file di lingkungan pengembangan tidak dapat disalin ke lingkungan produksi apa adanya. Sebagai gantinya, versi Web.config yang disesuaikan perlu diunggah ke produksi. Tutorial ini secara singkat meninjau beberapa perbedaan konfigurasi yang lebih umum; ini juga meringkas beberapa teknik untuk mempertahankan informasi konfigurasi yang berbeda antara lingkungan.

Perbedaan Konfigurasi Umum Antara Lingkungan Pengembangan dan Produksi

File Web.config ini mencakup berbagai informasi konfigurasi untuk aplikasi ASP.NET. Beberapa informasi konfigurasi ini sama terlepas dari lingkungannya. Misalnya, pengaturan autentikasi dan aturan otorisasi URL yang dieja dalam Web.config elemen dan <authorization> file <authentication> biasanya sama terlepas dari lingkungannya. Tetapi informasi konfigurasi lainnya - seperti informasi tentang sumber daya eksternal - biasanya berbeda tergantung pada lingkungan.

String koneksi database adalah contoh utama informasi konfigurasi yang berbeda berdasarkan lingkungan. Ketika aplikasi web berkomunikasi dengan server database, aplikasi tersebut harus terlebih dahulu membuat koneksi, dan itu dicapai melalui string koneksi. Meskipun dimungkinkan untuk membuat kode keras database string koneksi langsung di halaman web atau kode yang terhubung ke database, yang terbaik adalah menempatkan elemennya<connectionStrings>Web.configsehingga informasi string koneksi berada di satu lokasi terpusat. Seringkali database yang berbeda digunakan selama pengembangan daripada yang digunakan dalam produksi; akibatnya, informasi string koneksi harus unik untuk setiap lingkungan.

Catatan

Tutorial di masa mendatang mengeksplorasi penyebaran aplikasi berbasis data, di mana kita akan menyelami secara spesifik bagaimana string koneksi database disimpan dalam file konfigurasi.

Perilaku yang dimaksudkan dari lingkungan pengembangan dan produksi berbeda secara substansial. Aplikasi web di lingkungan pengembangan sedang dibuat, diuji, dan di-debug oleh sekelompok kecil pengembang. Di lingkungan produksi aplikasi yang sama sedang dikunjungi oleh banyak pengguna simultan yang berbeda. ASP.NET menyertakan sejumlah fitur yang membantu pengembang dalam menguji dan men-debug aplikasi, tetapi fitur-fitur ini harus dinonaktifkan karena alasan performa dan keamanan ketika berada di lingkungan produksi. Mari kita lihat beberapa pengaturan konfigurasi tersebut.

Pengaturan konfigurasi yang memengaruhi performa

Ketika halaman ASP.NET dikunjungi untuk pertama kalinya (atau pertama kalinya setelah berubah), markup deklaratifnya harus dikonversi menjadi kelas dan kelas ini harus dikompilasi. Jika aplikasi web menggunakan kompilasi otomatis, kelas code-behind halaman juga perlu dikompilasi. Anda dapat mengonfigurasi berbagai opsi kompilasi melalui Web.config elemen file<compilation>.

Atribut debug adalah salah satu atribut terpenting dalam <compilation> elemen . debug Jika atribut diatur ke "true" maka rakitan yang dikompilasi menyertakan simbol debug, yang diperlukan saat men-debug aplikasi di Visual Studio. Tetapi simbol debug meningkatkan ukuran perakitan dan memberlakukan persyaratan memori tambahan saat menjalankan kode. Selain itu, ketika debug atribut diatur ke "true" konten apa pun yang dikembalikan oleh WebResource.axd tidak di-cache, yang berarti bahwa setiap kali pengguna mengunjungi halaman, mereka harus mengunduh ulang konten statis yang dikembalikan oleh WebResource.axd.

Catatan

WebResource.axd adalah Handler HTTP bawaan yang diperkenalkan di ASP.NET 2.0 yang digunakan kontrol server untuk mengambil sumber daya yang disematkan, seperti file skrip, gambar, file CSS, dan konten lainnya. Untuk informasi selengkapnya tentang cara WebResource.axd kerja dan cara menggunakannya untuk mengakses sumber daya yang disematkan dari kontrol server kustom Anda, lihat Mengakses Sumber Daya Tersemat Melalui URL Menggunakan WebResource.axd.

Atribut <compilation> elemen debug biasanya diatur ke "true" di lingkungan pengembangan. Bahkan, atribut ini harus diatur ke "true" untuk men-debug aplikasi web; jika Anda mencoba men-debug aplikasi ASP.NET dari Visual Studio dan debug atribut diatur ke "false", Visual Studio akan menampilkan pesan yang menjelaskan bahwa aplikasi tidak dapat di-debug hingga debug atribut diatur ke "true" dan akan menawarkan untuk membuat perubahan ini untuk Anda.

Anda tidak boleh mengatur debug atribut ke "true" di lingkungan produksi karena dampaknya pada performa. Untuk diskusi yang lebih menyeluruh tentang topik ini, lihat posting blog Scott Guthrie, Jangan Jalankan Produksi ASP.NET Aplikasi Dengan debug="true" Diaktifkan.

Kesalahan dan Pelacakan Kustom

Ketika pengecualian yang tidak tertangani terjadi dalam aplikasi ASP.NET, pengecualian tersebut bergelembung hingga runtime di mana salah satu dari tiga hal terjadi:

  • Pesan kesalahan runtime generik ditampilkan. Halaman ini memberi tahu pengguna bahwa ada kesalahan runtime, tetapi tidak memberikan detail apa pun tentang kesalahan tersebut.
  • Pesan detail pengecualian ditampilkan, yang mencakup informasi tentang pengecualian yang baru saja dilemparkan.
  • Halaman kesalahan kustom ditampilkan, yang merupakan halaman ASP.NET yang Anda buat yang menampilkan pesan apa pun yang Anda inginkan.

Apa yang terjadi dalam wajah pengecualian yang tidak tertangani tergantung pada bagian Web.config file<customErrors>.

Saat mengembangkan dan menguji aplikasi, ini membantu melihat detail pengecualian apa pun di browser. Namun, menunjukkan detail pengecualian dalam aplikasi pada produksi adalah potensi risiko keamanan. Selain itu, itu tidak berlama-lama dan membuat situs web Anda terlihat tidak profesional. Idealnya, jika terjadi pengecualian yang tidak tertangani, aplikasi web di lingkungan pengembangan akan menunjukkan detail pengecualian sementara aplikasi yang sama dalam produksi akan menampilkan halaman kesalahan kustom.

Catatan

Pengaturan bagian default <customErrors> memperlihatkan pesan detail pengecualian hanya ketika halaman sedang dikunjungi melalui localhost, dan memperlihatkan halaman kesalahan runtime generik sebaliknya. Ini tidak ideal, tetapi meyakinkan untuk mengetahui bahwa perilaku default tidak mengungkapkan detail pengecualian kepada pengunjung non-lokal. Tutorial di masa mendatang memeriksa bagian <customErrors> secara lebih rinci dan menunjukkan cara memiliki halaman kesalahan kustom yang ditunjukkan ketika kesalahan terjadi dalam produksi.

Fitur ASP.NET lain yang berguna selama pengembangan adalah pelacakan. Pelacakan, jika diaktifkan, merekam informasi tentang setiap permintaan masuk dan menyediakan halaman web khusus, Trace.axd, untuk melihat detail permintaan terbaru. Anda dapat mengaktifkan dan mengonfigurasi pelacakan melalui <trace> elemen di Web.config.

Jika Anda mengaktifkan pelacakan, pastikan pelacakan dinonaktifkan dalam produksi. Karena informasi pelacakan mencakup cookie, data sesi, dan informasi lain yang berpotensi sensitif, penting untuk menonaktifkan pelacakan dalam produksi. Kabar baiknya adalah bahwa, secara default, pelacakan dinonaktifkan dan Trace.axd file hanya dapat diakses melalui localhost. Jika Anda mengubah pengaturan default ini dalam pengembangan, pastikan pengaturan tersebut dinonaktifkan dalam produksi.

Teknik untuk Mempertahankan Informasi Konfigurasi Terpisah

Memiliki pengaturan konfigurasi yang berbeda dalam lingkungan pengembangan dan produksi mempersulit proses penyebaran. Dalam dua tutorial sebelumnya, proses penyebaran melibatkan penyalinan semua file yang diperlukan dari pengembangan ke produksi, tetapi pendekatan itu hanya berfungsi jika informasi konfigurasi sama di kedua lingkungan. Ada berbagai teknik untuk menyebarkan aplikasi dengan berbagai informasi konfigurasi. Mari kita katalog beberapa opsi ini untuk aplikasi web yang dihosting.

Menyebarkan File Konfigurasi Lingkungan Produksi secara manual

Pendekatan paling sederhana adalah mempertahankan dua versi Web.config file: satu untuk lingkungan pengembangan dan satu untuk lingkungan produksi. Menyebarkan situs ke produksi memerlukan penyalinan semua file ke server produksi di lingkungan pengembangan kecuali untuk Web.config file. Sebagai gantinya, file khusus Web.config lingkungan produksi akan disalin ke produksi.

Pendekatan ini tidak terlalu canggih, tetapi mudah diterapkan karena informasi konfigurasi jarang berubah. Ini berfungsi paling baik untuk aplikasi dengan tim pengembangan kecil yang dihosting di satu server web dan yang informasi konfigurasinya jarang berubah. Ini paling dapat disewa ketika menyebarkan file aplikasi secara manual menggunakan klien FTP yang berdiri sendiri. Saat menggunakan alat Salin Situs Web Visual Studio atau opsi Terbitkan, Anda harus terlebih dahulu menukar file khusus penyebaran dengan file khusus Web.config produksi sebelum menyebarkan, lalu menukarnya kembali setelah penyebaran selesai.

Mengubah Konfigurasi Selama Proses Build atau Penyebaran

Diskusi sejauh ini telah mengasumsikan proses pembangunan dan penyebaran ad-hoc. Banyak proyek perangkat lunak yang lebih besar memiliki proses yang lebih formal yang memanfaatkan alat sumber terbuka, ditanam di rumah, atau pihak ketiga. Untuk proyek tersebut, Anda mungkin dapat menyesuaikan proses build atau penyebaran untuk memodifikasi informasi konfigurasi dengan tepat sebelum didorong ke produksi. Jika Anda membangun aplikasi web menggunakan MSBuild, NAnt, atau beberapa alat build lainnya, Anda mungkin dapat menambahkan langkah build untuk memodifikasi Web.config file untuk menyertakan pengaturan khusus produksi. Atau alur kerja penyebaran Anda dapat terhubung secara terprogram ke server kontrol sumber dan mengambil file yang sesuai Web.config .

Pendekatan aktual untuk mendapatkan informasi konfigurasi yang sesuai untuk produksi sangat bervariasi berdasarkan alat dan alur kerja Anda. Dengan demikian, kami tidak akan mempelajari topik ini lebih lanjut. Jika Anda menggunakan alat build populer seperti MSBuild atau NAnt, Anda dapat menemukan artikel penyebaran dan tutorial khusus untuk alat-alat ini melalui pencarian web.

Mengelola Perbedaan Konfigurasi melalui Add-In Proyek Penyebaran Web

Pada tahun 2006, Microsoft merilis Add-In Proyek Pengembangan Web untuk Visual Studio 2005. Add-In untuk Visual Studio 2008 dirilis pada tahun 2008. Add-In ini memungkinkan pengembang ASP.NET membuat Proyek Penyebaran Web terpisah bersama proyek aplikasi web mereka yang, ketika dibangun, secara eksplisit mengkompilasi aplikasi web dan menyalin file untuk disebarkan ke direktori output lokal. Proyek Aplikasi Web menggunakan MSBuild di belakang layar.

Secara default, file lingkungan Web.config pengembangan disalin ke direktori output, tetapi Anda dapat menyiapkan Proyek Penyebaran Web untuk menyesuaikan

informasi konfigurasi yang akan disalin ke direktori ini dengan cara berikut:

  • Melalui Web.config penggantian bagian file, di mana Anda menentukan bagian untuk mengganti dan file XML yang berisi teks pengganti.
  • Dengan menyediakan jalur ke file sumber konfigurasi eksternal. Dengan opsi ini dipilih, Proyek Penyebaran Web menyalin file tertentu Web.config ke direktori output (bukan file yang Web.config digunakan di lingkungan pengembangan).
  • Dengan menambahkan aturan kustom ke file MSBuild yang digunakan oleh Proyek Penyebaran Web.

Untuk menyebarkan aplikasi web, bangun Proyek Penyebaran Web lalu salin file dari folder output proyek ke lingkungan produksi.

Untuk mempelajari selengkapnya tentang menggunakan Proyek Penyebaran Web, lihat artikel Proyek Penyebaran Web ini dari Majalah MSDN edisi April 2007, atau lihat tautan di bagian Bacaan Lebih Lanjut di akhir tutorial ini.

Catatan

Anda tidak dapat menggunakan Proyek Penyebaran Web dengan Pengembang Web Visual karena Proyek Penyebaran Web diimplementasikan sebagai Add-In Visual Studio dan Visual Studio Express Editions (termasuk Visual Web Developer) tidak mendukung Add-In.

Ringkasan

Sumber daya eksternal dan perilaku aplikasi web dalam pengembangan biasanya berbeda dari ketika aplikasi yang sama dalam produksi. Misalnya, string koneksi database, opsi kompilasi, dan perilaku ketika pengecualian yang tidak tertangani terjadi biasanya berbeda antar lingkungan. Proses penyebaran harus mengakomodasi perbedaan ini. Seperti yang kita bahas dalam tutorial ini, pendekatan paling sederhana adalah menyalin file konfigurasi alternatif secara manual ke lingkungan produksi. Solusi yang lebih elegan dimungkinkan saat menggunakan Proyek Penyebaran Web Add-In atau dengan proses build atau penyebaran yang lebih formal yang dapat mengakomodasi penyesuaian tersebut.

Selamat Pemrograman!

Bacaan lebih lanjut

Untuk informasi selengkapnya tentang topik yang dibahas dalam tutorial ini, lihat sumber daya berikut:

SebelumnyaBerikutnya