Bagaimana Anda menyebarkan aplikasi ASP.NET Anda ke server langsung?

Saya mencari berbagai teknik / alat yang Anda gunakan untuk menyebarkan proyek aplikasi web ASP.NET ( BUKAN situs web ASP.NET) untuk produksi?

Saya sangat tertarik dengan alur kerja yang terjadi antara waktu server Continuous Integration Build Anda menjatuhkan binari di beberapa lokasi dan saat permintaan pengguna pertama mengenai biner ini.

1. Apakah Anda menggunakan beberapa alat khusus atau hanya XCOPY? Bagaimana aplikasi dikemas (ZIP, MSI, ...)?

2. Ketika aplikasi digunakan untuk pertama kali, bagaimana Anda mengatur App Pool dan Direktori Virtual (apakah Anda membuatnya secara manual atau dengan alat tertentu)?

3. Ketika sumber daya statis berubah (CSS, JS, atau file gambar), apakah Anda menerapkan ulang seluruh aplikasi atau hanya sumber daya yang dimodifikasi? Bagaimana jika halaman assembly / ASPX berubah?

4. Apakah Anda melacak semua versi yang diterapkan untuk aplikasi tertentu dan jika terjadi kesalahan, apakah Anda memiliki prosedur untuk memulihkan aplikasi ke status kerja yang diketahui sebelumnya?

Silakan melengkapi daftar sebelumnya.

Dan inilah yang kami gunakan untuk menyebarkan aplikasi ASP.NET kami:

1. Kami menambahkan Proyek Penyebaran Web ke solusi dan menyiapkannya untuk membangun aplikasi web ASP.NET
2. Kami menambahkan Proyek Penyiapan ( BUKAN Proyek Penyiapan Web) ke solusi dan menyetelnya untuk mengambil keluaran dari Proyek Penerapan Web
3. Kami menambahkan tindakan penginstalan kustom dan dalam acara OnInstall kami menjalankan rakitan build .NET kustom yang membuat App Pool dan Direktori Virtual di IIS menggunakan System.DirectoryServices.DirectoryEntry (Tugas ini dilakukan hanya saat pertama kali aplikasi disebarkan) . Kami mendukung beberapa Situs Web di IIS, Otentikasi untuk Direktori Virtual dan identitas pengaturan untuk App Pools.
4. Kami menambahkan tugas kustom di TFS untuk membangun Proyek Penataan (TFS tidak mendukung Proyek Penataan jadi kami harus menggunakan devenv.exe untuk membangun MSI)
5. MSI diinstal di server langsung (jika ada versi MSI sebelumnya, ini dicopot terlebih dahulu)

Kami memiliki semua kode kami yang diterapkan di MSI menggunakan Setup Factory. Jika sesuatu harus berubah, kami menerapkan ulang seluruh solusi. Ini terdengar seperti berlebihan untuk file css, tetapi ini benar-benar menjaga semua lingkungan tetap sinkron, dan kami tahu persis apa yang ada dalam produksi (kami menerapkan ke semua lingkungan pengujian dan uat dengan cara yang sama).

Kami melakukan penerapan bergulir ke server langsung, jadi kami tidak menggunakan proyek pemasang; kami memiliki sesuatu yang lebih seperti CI:

• build server "live" dari sumber yang disetujui (bukan "HEAD" dari repo)
• (setelah mengambil cadangan ;-p)
• robocopy menerbitkan ke server penahapan ("langsung", tetapi tidak di cluster F5)
• validasi akhir dilakukan pada server penahapan, sering kali dengan peretasan "host" untuk meniru semuanya sedekat mungkin
• robocopy / L digunakan secara otomatis untuk mendistribusikan daftar perubahan dalam "push" berikutnya, untuk mengingatkan kesalahan apa pun
• sebagai bagian dari proses terjadwal, cluster didaur ulang, diterapkan ke node di cluster melalui robocopy (saat mereka keluar dari cluster)

robocopy secara otomatis memastikan bahwa hanya perubahan yang diterapkan.

Re the App Pool dll; Saya akan senang ini akan otomatis ( lihat pertanyaan ini ), tetapi pada saat itu manual. Saya benar-benar ingin mengubahnya.

(mungkin membantu jika kita memiliki pusat data dan server-farm "di situs" kita sendiri, jadi kita tidak harus melewati banyak rintangan)

Situs web

Penyebar: http://www.codeproject.com/KB/install/deployer.aspx

Saya mempublikasikan situs web ke folder lokal, men-zip-nya, lalu mengunggahnya melalui FTP. Deployer di server kemudian mengekstrak zip, mengganti nilai konfigurasi (di Web.Config dan file lain), dan hanya itu.

Tentu saja untuk menjalankan pertama Anda perlu terhubung ke server dan menyiapkan IIS WebSite, database, tetapi setelah itu pembaruan penerbitan sangat mudah.

Database

Untuk menjaga agar database tetap sinkron, saya menggunakan http://www.red-gate.com/products/sql-development/sql-compare/

Jika server berada di belakang sekelompok router dan Anda tidak dapat terhubung secara langsung (yang merupakan persyaratan Perbandingan SQL), gunakan https://secure.logmein.com/products/hamachi2/ untuk membuat VPN.

Saya menyebarkan sebagian besar aplikasi ASP.NET ke server Linux dan menerapkan ulang semuanya bahkan untuk perubahan terkecil. Berikut adalah alur kerja standar saya:

• Saya menggunakan repositori kode sumber (seperti Subversion)
• Di server, saya memiliki skrip bash yang melakukan hal berikut:
  • Lihat kode terbaru
  • Apakah membangun (membuat DLL)
  • Memfilter file ke hal-hal penting (menghapus file kode misalnya)
  • Mencadangkan database
  • Menerapkan file ke server web dalam direktori yang diberi nama tanggal saat ini
  • Memperbarui database jika skema baru disertakan dalam penerapan
  • Menjadikan penginstalan baru sebagai penginstalan default sehingga akan disajikan dengan klik berikutnya

Checkout dilakukan dengan versi baris perintah Subversion dan pembangunan dilakukan dengan xbuild (msbuild bekerja sama dari proyek Mono). Sebagian besar keajaiban dilakukan di ReleaseIt.

Di server dev saya, saya pada dasarnya memiliki integrasi berkelanjutan tetapi di sisi produksi saya sebenarnya SSH ke server dan memulai penerapan secara manual dengan menjalankan skrip. Skrip saya dengan cerdik disebut 'deploy' jadi itulah yang saya ketikkan pada prompt bash. Saya sangat kreatif Tidak.

Dalam produksi, saya harus mengetik 'deploy' dua kali: sekali untuk check-out, membangun, dan menerapkan ke direktori bertanggal dan sekali untuk menjadikan direktori itu sebagai instance default. Karena direktori sudah diberi tanggal, saya dapat kembali ke penerapan sebelumnya hanya dengan mengetik 'gunakan' dari dalam direktori yang relevan.

Penerapan awal membutuhkan beberapa menit dan pengembalian ke versi sebelumnya membutuhkan beberapa detik.

Ini merupakan solusi yang bagus bagi saya dan hanya mengandalkan tiga utilitas baris perintah (svn, xbuild, dan releaseit), klien DB, SSH, dan Bash.

Saya benar-benar perlu memperbarui salinan ReleaseIt di CodePlex kapan-kapan:

http://releaseit.codeplex.com/

XCopy sederhana untuk ASP.NET. Zip itu, sftp ke server, ekstrak ke lokasi yang benar. Untuk penerapan pertama, penyiapan IIS secara manual

Menjawab pertanyaan Anda:

1. XCopy
2. Secara manual
3. Untuk sumber daya statis, kami hanya menerapkan sumber daya yang diubah.
   Untuk DLL kami menyebarkan halaman DLL dan ASPX yang diubah.
4. Ya dan ya

Menjaga agar tetap bagus dan sederhana sejauh ini telah menyelamatkan kita dari banyak sakit kepala.

Apakah Anda menggunakan beberapa alat khusus atau hanya XCOPY? Bagaimana aplikasi dikemas (ZIP, MSI, ...)?

Sebagai pengembang untuk BuildMaster , inilah yang saya gunakan secara alami. Semua aplikasi dibuat dan dikemas dalam alat sebagai artefak, yang disimpan secara internal sebagai file ZIP.

Ketika aplikasi digunakan untuk pertama kali, bagaimana Anda mengatur App Pool dan Direktori Virtual (apakah Anda membuatnya secara manual atau dengan alat tertentu)?

Secara manual - kami membuat kontrol perubahan dalam alat yang mengingatkan kami langkah-langkah yang tepat untuk dilakukan di lingkungan masa depan saat aplikasi bergerak melalui lingkungan pengujiannya. Ini juga dapat diotomatiskan dengan skrip PowerShell sederhana, tetapi kami tidak terlalu sering menambahkan aplikasi baru sehingga Anda dapat menghabiskan waktu 1 menit untuk membuat situs secara manual semudah itu.

Ketika sumber daya statis berubah (CSS, JS, atau file gambar), apakah Anda menerapkan ulang seluruh aplikasi atau hanya sumber daya yang dimodifikasi? Bagaimana jika halaman assembly / ASPX berubah?

Secara default, proses penerapan artefak diatur sedemikian rupa sehingga hanya file yang diubah yang ditransfer ke server target - ini mencakup semuanya dari file CSS, file JavaScript, halaman ASPX, dan rakitan tertaut.

Apakah Anda melacak semua versi yang diterapkan untuk aplikasi tertentu dan jika terjadi kesalahan, apakah Anda memiliki prosedur untuk memulihkan aplikasi ke status kerja yang diketahui sebelumnya?

Ya, BuildMaster menangani semua ini untuk kita. Pemulihan sebagian besar sesederhana menjalankan ulang promosi build lama, tetapi terkadang perubahan database perlu dipulihkan secara manual, dan kehilangan data dapat terjadi. Proses rollback dasar dirinci di sini: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

proyek penyiapan / pemasangan web - sehingga Anda dapat dengan mudah mencopot pemasangannya jika terjadi kesalahan

Unfold adalah solusi penerapan mirip capistrano yang saya tulis untuk aplikasi .net. Ini adalah apa yang kami gunakan pada semua proyek kami dan merupakan solusi yang sangat fleksibel. Ini memecahkan sebagian besar masalah khas untuk aplikasi .net seperti yang dijelaskan dalam posting blog ini oleh Rob Conery.

• ia hadir dengan perilaku "default" yang baik, dalam arti ia melakukan banyak hal standar untuk Anda: mendapatkan kode dari kendali sumber, membangun, membuat kumpulan aplikasi, menyiapkan IIS, dll.
• rilis berdasarkan apa yang ada di kontrol sumber
• itu memiliki kait tugas , sehingga perilaku default dapat dengan mudah diperpanjang atau diubah
• itu memiliki rollback
• itu semua PowerShell , jadi tidak ada ketergantungan eksternal
• ia menggunakan PowerShell remote untuk mengakses mesin jarak jauh

Berikut adalah pengantar dan beberapa entri blog lainnya.

Jadi untuk menjawab pertanyaan diatas:

• Bagaimana aplikasi dikemas (ZIP, MSI, ...)?

  Git (atau scm lain) adalah cara default untuk mendapatkan aplikasi di mesin target. Atau Anda dapat melakukan build lokal dan menyalin hasilnya melalui koneksi remote Powereshell

• Ketika aplikasi digunakan untuk pertama kali, bagaimana Anda mengatur App Pool dan Direktori Virtual (apakah Anda membuatnya secara manual atau dengan alat tertentu)?

  Unfold mengonfigurasi kumpulan aplikasi dan aplikasi situs web menggunakan Modul Administrasi Web Powershell. Ini memungkinkan kami (dan Anda) untuk memodifikasi aspek apa pun dari kumpulan aplikasi atau situs web

• Ketika sumber daya statis berubah (CSS, JS, atau file gambar), apakah Anda menerapkan ulang seluruh aplikasi atau hanya sumber daya yang dimodifikasi? Bagaimana jika halaman assembly / ASPX berubah?

  Ya terungkap apakah ini, penyebaran apa pun dipasang di sebelah yang lain. Dengan cara itu kita dapat dengan mudah melakukan rollback ketika ada yang tidak beres. Ini juga memungkinkan kami untuk dengan mudah melacak kembali versi yang diterapkan ke revisi kontrol sumber.

• Apakah Anda melacak semua versi yang diterapkan untuk aplikasi tertentu?

  Ya, terungkap terus versi lama. Tidak semua versi, tetapi sejumlah versi. Itu membuat pengguliran menjadi hampir sepele.

Kami telah meningkatkan proses rilis kami selama setahun terakhir dan sekarang kami berhasil melakukannya. Saya menggunakan Jenkins untuk mengelola semua build dan rilis otomatis kami, tetapi saya yakin Anda dapat menggunakan TeamCity atau CruiseControl.

Jadi setelah check in, build "normal" kami melakukan hal berikut:

• Jenkins melakukan update SVN untuk mengambil kode versi terbaru
• Pemulihan paket NuGet dilakukan dengan menjalankan repositori NuGet lokal kita sendiri
• Aplikasi ini dikompilasi menggunakan MsBuild. Menyiapkan ini adalah sebuah petualangan, karena Anda perlu menginstal MsBuild yang benar dan kemudian ASP.NET dan MVC dll di kotak build Anda. (Sebagai catatan tambahan, ketika saya <MvcBuildViews>true</MvcBuildViews>memasukkan file .csproj saya untuk mengkompilasi tampilan, msbuild secara acak macet, jadi saya harus menonaktifkannya)
• Setelah kode dikompilasi, pengujian unit dijalankan (saya menggunakan nunit untuk ini, tetapi Anda dapat menggunakan apa pun yang Anda inginkan)
• Jika semua tes unit lulus, saya menghentikan kumpulan aplikasi IIS, menerapkan aplikasi secara lokal (hanya beberapa perintah XCOPY dasar untuk menyalin file yang diperlukan) dan kemudian memulai ulang IIS (Saya memiliki masalah dengan file penguncian IIS, dan ini diselesaikan Itu)
• Saya memiliki file web.config terpisah untuk setiap lingkungan; dev, uat, prod. (Saya mencoba menggunakan hal-hal transformasi web dengan sedikit keberhasilan). Jadi file web.config yang tepat juga disalin
• Saya kemudian menggunakan PhantomJS untuk menjalankan banyak tes UI. Ini juga mengambil banyak tangkapan layar dengan resolusi berbeda (seluler, desktop) dan memberi cap pada setiap tangkapan layar dengan beberapa informasi (judul halaman, resolusi). Jenkins memiliki dukungan yang bagus untuk menangani screenshot ini dan mereka disimpan sebagai bagian dari build
• Setelah pengujian UI integrasi lulus, build berhasil

Jika seseorang mengklik "Deploy to UAT":

• Jika build terakhir berhasil, Jenkins melakukan update SVN lagi
• Aplikasi dikompilasi menggunakan konfigurasi RELEASE
• Direktori "www" dibuat dan aplikasi disalin ke dalamnya
• Saya kemudian menggunakan winscp untuk menyinkronkan sistem file antara kotak build dan UAT
• Saya mengirim permintaan HTTP ke server UAT dan memastikan saya mendapatkan kembali 200
• Revisi ini diberi tag di SVN sebagai UAT-datetime
• Jika kita sudah sampai sejauh ini, build berhasil!

Saat kami mengklik "Terapkan ke Prod":

• Pengguna memilih Tag UAT yang telah dibuat sebelumnya
• Tag "dialihkan" ke
• Kode dikompilasi dan disinkronkan dengan server Prod
• Permintaan http ke server Prod
• Revisi ini diberi tag di SVN sebagai Prod-datetime
• Rilis di-zip dan disimpan

Semua pembuatan penuh hingga produksi membutuhkan waktu sekitar 30 detik yang sangat saya sukai.

Keuntungan dari solusi ini:

• Itu cepat
• Tes unit harus menangkap kesalahan logika
• Saat bug UI masuk ke produksi, tangkapan layar diharapkan akan menunjukkan # revisi apa yang menyebabkannya
• UAT dan Prod tetap sinkron
• Jenkins menunjukkan kepada Anda riwayat rilis yang bagus untuk UAT dan Prod dengan semua pesan commit
• Rilis UAT dan Prod semuanya ditandai secara otomatis
• Anda dapat melihat kapan rilis terjadi dan siapa yang melakukannya

Kerugian utama dari solusi ini adalah:

• Setiap kali Anda melakukan rilis ke Prod, Anda perlu melakukan rilis ke UAT. Ini adalah keputusan sadar yang kami buat karena kami ingin selalu memastikan bahwa UAT selalu up to date dengan Prod. Tetap saja, itu menyakitkan.
• Ada beberapa file konfigurasi yang beredar. Saya telah mencoba untuk memiliki semuanya di Jenkins, tetapi ada beberapa file batch dukungan yang diperlukan sebagai bagian dari prosesnya. (Ini juga diperiksa).
• Skrip upgrade dan downgrade DB adalah bagian dari aplikasi dan dijalankan saat aplikasi dimulai. Ini berhasil (sebagian besar), tetapi itu menyakitkan.

Saya ingin mendengar kemungkinan peningkatan lainnya!

Kembali pada tahun 2009, di mana jawaban ini berasal, kami menggunakan CruiseControl.net untuk build Continuous Integration kami, yang juga mengeluarkan Release Media.

Dari sana kami menggunakan perangkat lunak Sinkronisasi Smart untuk membandingkan dengan server produksi yang berada di luar kumpulan seimbang beban, dan memindahkan perubahan ke atas.

Akhirnya, setelah memvalidasi rilis, kami menjalankan skrip DOS yang utamanya menggunakan RoboCopy untuk menyinkronkan kode ke server langsung, menghentikan / memulai IIS saat dijalankan.

Di perusahaan terakhir tempat saya bekerja, kami biasa menerapkan menggunakan file batch rSync untuk hanya mengupload perubahan sejak upload terakhir. Keindahan dari rSync adalah Anda dapat menambahkan daftar pengecualian untuk mengecualikan file atau pola nama file tertentu. Jadi mengecualikan semua file .cs, solusi, dan file proyek kami sangat mudah, misalnya.

Kami menggunakan TortoiseSVN untuk kontrol versi, dan sangat menyenangkan bisa menulis dalam beberapa perintah SVN untuk mencapai hal berikut:

• Pertama, periksa apakah pengguna memiliki revisi terbaru. Jika tidak, minta mereka untuk memperbarui atau menjalankan pembaruan saat itu juga.
• Unduh file teks dari server bernama "synclog.txt" yang merinci siapa pengguna SVN, nomor revisi apa yang mereka unggah dan tanggal serta waktu mengunggah. Tambahkan baris baru untuk unggahan saat ini dan kemudian kirimkan kembali ke server bersama dengan file yang diubah. Ini sangat memudahkan untuk mengetahui versi situs mana yang akan dikembalikan jika unggahan menyebabkan masalah.

Selain itu, ada file batch kedua yang hanya memeriksa perbedaan file di server langsung. Ini dapat menyoroti masalah umum di mana seseorang akan mengupload tetapi tidak melakukan perubahan mereka ke SVN. Dikombinasikan dengan log sinkronisasi yang disebutkan di atas, kami dapat mengetahui siapa kemungkinan pelakunya dan meminta mereka untuk melakukan pekerjaan mereka.

Dan terakhir, rSync memungkinkan Anda mengambil cadangan file yang diganti selama pengunggahan. Kami telah memindahkannya ke folder cadangan. Jadi jika Anda tiba-tiba menyadari bahwa beberapa file seharusnya tidak ditimpa, Anda dapat menemukan versi cadangan terakhir dari setiap file di folder itu.

Sementara solusinya terasa sedikit kikuk pada saat itu, saya lebih menghargainya ketika bekerja di lingkungan di mana metode unggah jauh lebih tidak elegan atau mudah (desktop jarak jauh, salin dan tempel seluruh situs, misalnya) .

Saya akan merekomendasikan TIDAK hanya menimpa file aplikasi yang ada tetapi sebagai gantinya membuat direktori per versi dan menunjuk kembali aplikasi IIS ke jalur baru. Ini memiliki beberapa manfaat:

• Cepat kembali jika perlu
• Tidak perlu menghentikan IIS atau kumpulan aplikasi untuk menghindari masalah penguncian
• Tidak ada risiko file lama menyebabkan masalah
• Kurang lebih nol waktu henti (biasanya hanya jeda di appdomain yang baru dimulai)

Satu-satunya masalah yang kami hadapi adalah sumber daya sedang di-cache jika Anda tidak memulai ulang pool aplikasi dan mengandalkan sakelar appdomain otomatis.