.NET Web Uygulamanızı nasıl dağıtırsınız? (Öneriler, lütfen!)

Kısa süre önce ASP.NET Web Sitemizi bir Web Uygulamasına yükselttik ve dağıtım yaparken ani zorluklarla karşılaştık. Bunun ne kadar yaygın bir görev olması gerektiği göz önüne alındığında, insanların hızla gelişen, uzaktan depolanan bir projeyi (yani bir web sitesi) dağıtmak için hangi eklentileri / yazılımları kullandığını merak ediyordum?

Visual Studio'da "Yayınlama" ve daha sonra değişen dosyaları el ile FTP zorunda daha iyi bir yolu olmalı ? En azından .DLL'leri yüklerken site çöktüğü için.

Kazara yüklemeleri önlemek için işlemi olabildiğince otomatik hale getirmem gerektiğini düşündüğüm çok fazla dosya istisnası var.

Eski çözümümüzle (Web Sitemizde) , tüm süreci tek bir tıklamayla sallayan ASP'yi gönderdik. Ne yazık ki (daha önce de belirtildiği gibi) DLL'ler için harika değil.

Peki gelmez senin takım bunu?

Herhangi bir tavsiye için teşekkürler.

Not - Visual Studio 2010'un bu eksiklikleri VS2005 / 08'de çözmesi gerektiğini okudum, ancak o zamana kadar ...

Sürekli Entegrasyon kullanmanızı şiddetle tavsiye ederim.

Yapıyı otomatikleştirmek için CI, Rake ve Albacore için TeamCity kombinasyonunu kullanıyoruz .

TeamCity kodu kaynak kodu deponuzdan kontrol edecek, daha sonra Rake'i kullanarak uygulamayı oluşturacak, birim testleri yürütecek ve hatta isterseniz veritabanı komut dosyalarınızı çalıştıracaktır. Başarılı bir derlemeden sonra kaynak kodunuzu bir zip dosyasına paketleyebilir veya istediğiniz bir hedefe kopyalayabilirsiniz.

TeamCity tüm kaynak kontrol sistemleriyle çalışmasına rağmen Git'i kullanıyoruz.

TeamCity ve Rake kullanmak, XML dosya düzenlemesi olmadan CruiseControl ve NANT kullanmaya benzer. Elbette isterseniz TeamCity'yi NANT ile kullanabilirsiniz.

Yapıyı gerçekleştiren bir rakefile.rb dosyasından alınan kısa bir örnek. IMHO, XML dosyasından daha kolay okunur ve hata ayıklanır.

require 'albacore'
require 'rexml/document'
require 'find'

VERSION_NO = "1.0"

OUTPUT_PATH = "output"
WEBOUTPUT_PATH = "output/web"
ADMINOUTPUT_PATH = "output/admin"

CONFIG = "Release"

WEB_PATH = "app/Company.Website.Web"
ADMIN_PATH = "app/Company.Website.Admin"
PACKAGE_PATH = "build/package"
DB_SCRIPT_PATH = "Company.Website.DB"
SOLUTION = "Company.Website.sln"

ARTIFACTS_PATH = "d:/build/artifacts/"

DEPLOY_WEB_PATH = "d:/deploy/company/website/"
DEPLOY_ADMIN_PATH = "d:/deploy/company/admin/"

task :default => ['setuptest','assemblyinfo','config','msbuild','createdb','sqlcmd','deploy']


task :setuptest do |setup|
  if ENV['BuildNumber'].nil? then ENV['BuildNumber'] = "000" end

  VERSION_NO = VERSION_NO + '.' + ENV['BuildNumber']
  puts 'Version Number : ' + VERSION_NO

  ZIPFILE_WEB = 'Company.Website.Web.' + VERSION_NO
  ZIPFILE_ADMIN = 'Company.Website.Admin.' + VERSION_NO  

  DB_SERVER = "WEB2"
  DB_DATABASE = "Website"  
  CREATEDB_SCRIPT = "app/Company.Website.DB/00CreateDatabaseTEST.sql"
end

  assemblyinfotask do |asm|
    asm.version = VERSION_NO
    asm.company_name = "Company Name"
    asm.copyright = "Copyright 2010"
    asm.output_file = "CommonAssemblyInfo.cs"
  end

  task :config do
    FileUtils.cp 'NHibernate.test.config', 'NHibernate.config'
  end

  msbuildtask do |msb|
    msb.properties = { :configuration => :Debug }
    msb.targets [:Clean, :Build]
    msb.solution = "Company.Website.sln"
  end

  sqlcmdtask :createdb do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = "master"
    sql.scripts << CREATEDB_SCRIPT
  end

  sqlcmdtask do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = DB_DATABASE
    sql.scripts << "app/Company.Website.DB/01CreateTables.sql"
    sql.scripts << "app/Company.Website.DB/02InsertReferenceData.sql"
  end

  task :deployprep do

    FileUtils.remove_dir 'app/Company.Website.Web/obj'
    FileUtils.remove_dir 'app/Company.Website.Admin/obj'

  end

  ziptask :zipweb do |zip|
    puts "creating zip package in " + ZIPFILE_WEB
    zip.directories_to_zip = ["app/Company.Website.Web"]
    zip.output_file = ZIPFILE_WEB  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end

  ziptask :zipadmin do |zip|
      puts "creating zip package in " + ZIPFILE_ADMIN
    zip.directories_to_zip = ["app/Company.Website.Admin"]
    zip.output_file = ZIPFILE_ADMIN  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end  

Albacore, .NET uygulamasını dağıtmak için özel olarak oluşturulmuş Komisyon görevleri grubudur.

Linux'ta, uzak SSH ve SCP komutlarına yardımcı olmak için otomasyon araçları olan fabric (fabfile.org) ve capistrano (capify.org) kullandım. Windows ana makinelerinizde Cygwin yüklüyse, bunları dağıtım araçları olarak yeniden kullanabilmeniz gerekir.

Bir web uygulamasını Visual Studio'da "yayınlamak" komut satırından olarak çalıştırılabilir msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". Hedef dizin konuşlandırılabilir bir web uygulamasıdır.

Büyük sorunuzu kapsayan diğer cevaplar iyidir. Ayrıca birkaç açık kaynaklı web uygulaması projesine bakmanız ve en çok istediğiniz oluşturma işlemini kopyalamanız gerektiğini de ekleyeceğim.

Scott'a bunun çok karmaşık olabileceğini ve kolayca gözden kaçabileceğini kabul ediyorum. Dağıtım stratejisi de uygulamaya özeldir. Uygulamanız tamamen tek bir klasörde bulunuyorsa, GAC'ye başvuran bir uygulamadan daha kolay olabilir. Bu da GAC ​​derlemelerinin birden çok sürümünü referans alan bir uygulamanın birden çok sürümünü tutması gereken bir sunucudan daha kolay olabilir. Burada politika dosyaları hakkında konuşmaya başlamak istemiyoruz :).

Microsoft Web Dağıtım Aracı'nı Uygulama İsteği Yönlendirme ile birleştirmenin tüm bunları söylemiş olmak iyi bir seçenektir. IIS7'de aracı kullanarak yükleme paketleri oluşturmak mümkündür. Aracı bir web uygulamasına yönlendirmek ve tüm uygulamayı bir uygulama arşiv klasörüne yedeklemek de mümkündür. Daha sonra bu arşiv klasöründen IIS6 veya IIS7 web sunucusuna dağıtabilirsiniz (IIS5 desteklenmez). Scott'ın test web sitelerinden canlı olarak ayrılmasını önerdiği gibi uygulama isteği yönlendirmesini kullanırdım. Yeni yayınlanan web sitesinin iyi olduğunu doğruladıktan sonra ARR'yi yeni sürüme yönlendirecek şekilde ayarlayabilirsiniz.

PyroBatchFTP bunun için harika çalışıyor. Sadece değişiklikleri itecek ve bir toplu iş dosyasını çift tıklatarak basabilmeniz için komut dosyası oluşturabilirsiniz.

At Vaasnet biz kurulum kendimiz için rüya çözüm ettik, ama bu oldukça eğer yapabilirsen bir kısmını veya bu öğelerin tümünü kullanan yerleşim ama değerinde karıştırmak. İşte bu:

• Tüm dev makinelerimizde SVN
• Derleme / dağıtım sunucumuzdaki SVN
• Cruisecontrol.net, SVN'deki değişiklikleri izler ve yalnızca gerekli dosyaları bir hazırlama klasörüne oluşturur ve hazırlar
• PyroBatchFTP kullanarak bir aşamalandırma sitesine geçiyoruz (Cruisecontrol tarafından tetiklenir, böylece otomatik olarak gerçekleşir)
• IIS7 ve Uygulama İsteği Yönlendirme (ARR) ve URL Yeniden Yazma özelliklerini kullanarak aşağıdaki aşamalandırma / üretim kurulumuna sahibiz:
  • Ön taraftaki ARR, hangisinin 'canlı' ve hangisinin 'sahneleme' olduğuna bağlı olarak trafiği 01 veya 02 örneğine yönlendirir
  • FTP hesabı her zaman 'sahnelemeye' bağlıdır
  • Sahnelemeyi değiştirecek ve tek bir tıklama ile yaşayacak başka bir mini yönetici sitem var. Sıfır kesinti süresi ile geçiş yapmak 1 saniyenin tamamını alır ve bu sürümle ilgili bir sorun olduğunu fark edersek tekrar geri dönebiliriz (her ne kadar nadirdir, çünkü canlıya geçmeden önce kolayca test edebiliriz).

Böylece net sonuç, SVN'yi kontrol etmemize ve manuel bir etkileşim olmadan otomatik olarak üretilmesini ve üretime aktarmamızı sağlar. Hazırlama URL'imizi test ettikten ve yayınlanmaya hazır olduğunu belirledikten sonra, basit bir siteye giriş yapıyoruz ve 1 tıklama ile yayınlanıyor.

Önerilmeyen başka bir yol için, sizi 'Gu' ve Web Kurulum Projelerine yönlendiriyorum

Bu temelde .NET uygulamanız için bir MSI yükleyici oluşturur. Bu örnek VS2005 içindir, ancak VS2010'um var ve proje türü hala orada. Bu, ihtiyacınız olduğunda çok fazla özelleştirme veya ihtiyacınız yoksa sadece temel kurulum sağlayabilir.

Şahsen çalıştığım yerde sadece xcopy tarzı bir dağıtım yapıyoruz, ama sonunda sunucu grubuna sadece bir paket teslim etmek istiyorum, ne zaman ve nasıl konuşlandırılacağını onlara kontrol etmek istiyorum. (Bence bu, grup politikası gibi bir şey kullanarak kitlesel konuşlandırmalar yapmayı da kolaylaştırabilir, ancak buna çok aşina değilim)

Bu kediyi kaplamanın birçok yolu var, gerçekten sunucunuza ne kadar erişim sağlayabileceğinize bağlı. Geç kaldığım en sevdiğim yöntem, proje içinde tüm dağıtım dosyalarını paketleyen bir yapı betiği (genellikle MSBUILD kullanarak) oluşturmak ve daha sonra bunları üretime bağlamak için SVN kullanmaktır. Ve üretim dosyalarını versiyonlamak.

Veritabanı açısından en iyi seçenek, bir tür geçiş çerçevesi kullanmaktır. Yine, koşanların bir demet ve gerçek net bir cevap yok.

Şahsen sadece dev sunucuya belirli dosya türlerinin klasörlerini kopyalamak için kendimi yazdım bir vbs komut dosyası kullanın (yani cs dosyaları, vb dışarı bırakın).

Büyük bir .com şirketinde çalıştığımda .net dağıtımlarımızla yaptığımız şey budur.

Tüm kaynak kodumuz ve saklı prosedürlerimiz SVN'de saklandı. Her gece, bir veritabanı işi çalıştırmak ve üretim saklanan procs çekin ve onları kaynak kontrolünde her zaman en güncel sürümü olması için SVN bir dizine kaydırın.

Bir projenin dağıtım gününde, projeleri SVN'den çekmek, projelerin özel bir yapısını yapmak ve bu projelerin ihtiyaç duyduğu bağımlılıkları çekmek için bir nAnt betiği kullanırdık. NAnt betiği çalıştırıldıktan sonra kendi kendine ayıklanan bir zip dosyasına paketlendi. Bu dağıtımla ilişkilendirilen saklanan procs, kaynak denetiminde kontrol edildi ve excel spreed sayfası, çalıştırılacak komut dosyalarıyla ve hangi sırayla güncelleştirildi.

Dağıtımcı kapandığında, kendiliğinden açılan zip dosyası başlatıldığı sunucuya aktarıldı. Tüm dosyalar doğru dizinlere çıkarıldı ve DBA, prodcution veritabanında depolanan procları çalıştırdı.

Bu sistemi kullanan tipik bir dağıtımda, beş ila altı saatlik bir dağıtımdan bir saat veya daha kısa bir süreye geçtik.

İyi şanslar ve umut bu bazı uygulama dağıtmak için bir yol çalışma yardımcı olur.

Visual Studio'da "Yayınlama" ve daha sonra değişen dosyaları el ile FTP zorunda daha iyi bir yolu olmalı?

Occam tıraş makinesi tipik olarak tercih edilen yaklaşımdır: daha basit, daha iyi. FTP, çok az veya hiç komplikasyon olmadan kolaydır. Bazı insanlar XCOPY, Filezilla veya WSFTP kullanır, diğerleri MS Web Dağıtım Aracı'nı (henüz bilmiyorum) kullanabilir, ancak hepsi bir arada, ASP.NET web uygulamalarını (ve diğerlerini dağıtmanın daha iyi bir yolu vardır) genel uygulamalar). IMO, dağıtım geliştirme başlangıcından itibaren dikkate alınırsa, dağıtım , gelecekte nispeten ağrısız ve sorunsuz bir dağıtım sağlayan web uygulamasıyla entegre edilebilir .

Boyut, karmaşıklık ve kullanıcı sayısı (birkaç yüz kullanıcıdan on binlerce) arasında değişen ASP.NET web uygulamaları geliştiren birkaç şirkette çalışan bir .NET geliştiricisi olarak IMO 'dağıtımı' genellikle en "akıcı" konudur. Bazı kuruluşlar bürokrasi açısından çok ileri giderken, diğerleri konuşlandırmayla ilgili herhangi bir sorunu ele almamaktadır. Deneyimlerime göre, dağıtım sorunları, zorluklar / başarısızlıklar açısından 3 kategoriden birine veya daha fazlasına düşme eğilimindedir:

1. Tasarım aşamasında dağıtım yok sayılır / unutulur: Çoğu web uygulaması bir web sunucusu ve bir veritabanı içerir. Uygulama kodunun ötesinde, belki bazı saklı yordamlar ve veritabanı tabloları, dağıtım çok düşünmek gerekmez. ASP.NET dağıtımında yardım edebilen daha fazladır fakat en sık geliştiriciler çalıştıran gerçek uygulamayı alma ve bakımından dikkati dağılır yapıyor bırakarak kendi görev how ayrı bir sorun olarak konuşlandırılması.

2. Dağıtım, birden fazla sistem ve oyundaki insanlar arasında karmaşıktır : Karmaşıklık bir sürtüktür. MSMQ, T-SQL saklı yordamlar ve tetikleyiciler, Raporlama Hizmetleri, SOAP / XML mesajlaşma, AD kimlik doğrulama, SSAS / SSIS, vb. En kötüsü, tüm bu farklı bileşenler genellikle bir kuruluştaki farklı varlıklar tarafından yönetilir. Herkes birbiriyle senkronize olmadıkça, konuşlandırmalar karmaşıklığı hızla artırabilir ve bu da birden fazla hata noktasına yol açabilir.

3. Tembellik, ilgisizlik veya iletişim ve / veya yönetim eksikliği: Çok az veya hiç dokümantasyondan koordineli iletişim ve protokol eksikliğine kadar, nispeten basit bir süreci ortadan kaldırmak kolaydır. Dağıtım, yapılanları belgelendirirken birçok kontrolün yapıldığı basit bir prosedür olmalıdır, ancak çoğu zaman böyle değildir. Çoğu insan sadece lanet olası sitenin yayınlanmasını istiyor. Deneyimlerime göre, insanlar (programcı olmayanlar) bir şey gerçekten fubar olana kadar gerçekten umursamıyorlar . Hiç kimse gerçekten başarısızlığın nedeni olmak istemediğinden, sorumluluk genellikle dağıtımı yapmak için sadece bir kişiye düşer, bu nedenle hesap verebilirlik genellikle dağıtılır.

Kazara yüklemeleri önlemek için işlemi olabildiğince otomatik hale getirmem gerektiğini düşündüğüm çok fazla dosya istisnası var. Peki ekibiniz bunu nasıl yapıyor?

Birkaç olsaydı şaşırmamam da, dağıtımı otomatikleştirmek için eldeki herhangi bir satıcı bilmiyorum. Muhtemelen bir çözümü VBScript / WMI veya toplu komut dosyası bir çözüm ile kodlayabilirsiniz, ancak gerçek şu ki bir çözümü birlikte daha karmaşık ASP.NET siteleri için uyarlamanız gerekir. Sayfalar, veritabanı bağlantısı ve başka hiçbir şeyden oluşan basit siteler, dağıtım çabalarınızı uygulamanın kendisinin karmaşıklığına göre ölçeklendirmenize gerek yoktur.

Şimdiye kadar, şu anki işimde dağıtım hala FTP üzerinden ve bir sürü dosyayı taşıyor. Çirkin, vidalanması kolaydır ve doğru bir tarih duygusu yoktur. FTP günlükleri üzerinden tarama yapabilirsiniz, kimse bunu gerçekten rahatsız. Uygulamalarımız, FTP'nin ötesinde çok fazla ihtiyaç duymadan oldukça basittir. Ekibimin web uygulamalarımızı nasıl dağıttığı sizin için çok azdır veya hiç faydası yoktur. Bunun yerine, bu fırsatı daha iyi uygulamalar önermek için kullanmayı tercih ederim .

• Hiçbir şey varsaymamak. Kullanıcı hesapları, R / W / X ayrıcalıkları, ACL'ler, güvenlik duvarları, zamanlama (ne zaman konuşlandırılacağını ve ne kadar zaman yapmanız gerektiğini ) ve mümkünse, son "başlatma tarihinden" önce tüm ortamlara dağıtımı test edin.
• Kalkınma aslında başlamadan önce, kalkınmaya etki faktörü. Basit bir site ise, öyle olsun. Orada sayısız hareketli parçalar, faktör içinde her şeyi ve aslında Eğer inşa planını hangi tüm bileşenleri (kod, veritabanı, raporlar, kuyruklar, vs.) aynı plan üzerinde tümü.
• Diğer paritelerle koordinasyon sağlayın ve etkili ve verimli iletişim kurun.
• Mümkünse ilgili bilgileri belgeleyin.
• Çevre: bir web sunucusu ile web grubu arasındaki bağlantı; 32 bit ve 64 bit; günlükleri / hataları / döndürmeyi vb. izlemenin bir yolunu bulma
• Dağıtımda yardımcı olabilecek araçları bulun (veya oluşturun).
• Programlanabilir kurulum için mümkünse, bir paradigma seçin ve buna bağlı kalın. Örneğin, bir uygulamanın durumunu, dağıtımını, erişimini ve benzerlerini yürütmek için bir veritabanı sunucusu olarak bir veritabanı sunucusu kullanmak istiyorsanız, onu uygulamaya dönüştürün ve buna bağlı kalın. XML dosyalarını (web.config gibi) elbette okumayı tercih ediyorsanız , uygulamayı dağıtma konusunda tutarlı bir paradigmaya sadık kalmanız yeterlidir . Başka bir örnek: bazı kuruluşlar web.config dosyasını her ortamda diğer ortamlara dağıtılmaması gereken statik bir dosya olarak bırakır . Diğerlerinin web.config programı, ortamlara hatasız olarak dağıtılabilecek şekilde.

Bu gönderinin ilk başta sorulan soru için aşırıya kaçmış olabileceğini anlıyorum. Ne yazık ki, uygulamalar karmaşıklık bakımından farklılık gösterebileceğinden, dağıtım basit bir şey değildir. Karmaşık ASP.NET uygulamalarını dağıtan çoğu kuruluşun zamanla (en azından) güvenilir bir şekilde belirli stratejiler geliştirdiğine bahse girerim .