ASP.NET uygulamalarınızı canlı sunuculara nasıl dağıtırsınız?

Bir ASP.NET web uygulaması projesini ( ASP.NET web sitesini DEĞİL ) üretime dağıtmak için kullandığınız farklı teknikler / araçlar arıyorum.

Sürekli Entegrasyon Derleme sunucunuzun ikilileri bir yerde bıraktığı ve ilk kullanıcı isteğinin bu ikililere ulaştığı zaman arasında gerçekleşen iş akışıyla özellikle ilgileniyorum.

1. Bazı özel araçlar mı yoksa sadece XCOPY mi kullanıyorsunuz? Uygulama nasıl paketlenir (ZIP, MSI, ...)?

2. Bir uygulama ilk kez konuşlandırıldığında Uygulama Havuzunu ve Sanal Dizini nasıl kurarsınız (bunları manuel olarak mı yoksa bazı araçlarla mı oluşturuyorsunuz)?

3. Statik bir kaynak değiştiğinde (CSS, JS veya görüntü dosyası) tüm uygulamayı mı yoksa yalnızca değiştirilen kaynağı mı yeniden dağıtırsınız? Bir derleme / ASPX sayfası değiştiğinde nasıl olur?

4. Belirli bir uygulama için dağıtılan tüm sürümleri takip ediyor musunuz ve bir şeyler ters giderse, uygulamayı önceki bilinen çalışma durumuna geri yükleme prosedürleriniz var mı?

Önceki listeyi tamamlamaktan çekinmeyin.

Ve işte ASP.NET uygulamalarımızı dağıtmak için kullandığımız şey:

1. Çözüme bir Web Dağıtım Projesi ekliyoruz ve ASP.NET web uygulamasını oluşturmak için kuruyoruz
2. Çözüme bir Kurulum Projesi ( Web Kurulum Projesi DEĞİL) ekliyoruz ve Web Dağıtım Projesinin çıktısını alacak şekilde ayarlıyoruz
3. Özel bir yükleme eylemi ekliyoruz ve OnInstall olayında, System.DirectoryServices.DirectoryEntry kullanarak IIS'de bir Uygulama Havuzu ve Sanal Dizin oluşturan özel bir derleme .NET derlemesi çalıştırıyoruz (Bu görev yalnızca bir uygulama ilk dağıtıldığında gerçekleştirilir) . IIS'de birden fazla Web Sitesini, Sanal Dizinler için Kimlik Doğrulamayı ve Uygulama Havuzları için kimlik ayarlamayı destekliyoruz.
4. Kurulum Projesi'ni oluşturmak için TFS'ye özel bir görev ekliyoruz (TFS, Kurulum Projelerini desteklemiyor, bu nedenle MSI'yı oluşturmak için devenv.exe'yi kullanmak zorunda kaldık)
5. MSI canlı sunucuya yüklenir (MSI'nın önceki bir sürümü varsa, önce kaldırılır)

Tüm kodumuz, Kurulum Fabrikası kullanılarak MSI'larda dağıtılır. Bir şeyin değişmesi gerekiyorsa, tüm çözümü yeniden dağıtırız. Bu, bir css dosyası için aşırılık gibi görünse de, tüm ortamları kesinlikle senkronize tutar ve üretimde tam olarak ne olduğunu biliyoruz (tüm test ve uat ortamlarına aynı şekilde dağıtıyoruz).

Canlı sunuculara sürekli dağıtım yapıyoruz, bu nedenle yükleyici projeleri kullanmıyoruz; daha çok CI gibi bir şeye sahibiz:

• Onaylanan kaynaktan (deponun "HEAD" kısmından değil) "canlı" derleme sunucusu derlemeleri
• (yedek aldıktan sonra ;-p)
• robocopy bir hazırlama sunucusunda yayınlar ("canlı", ancak F5 kümesinde değil)
• Hazırlama sunucusunda, her şeyi olabildiğince yakından taklit etmek için genellikle "ana bilgisayar" korsanlarıyla yapılan son doğrulama
• robocopy / L, bir sonraki "itmede" değişikliklerin listesini dağıtmak için otomatik olarak kullanılır
• programlanmış bir sürecin parçası olarak, küme döngülenir ve robocopy aracılığıyla kümedeki düğümlere dağıtılır (kümenin dışındayken)

robocopy, otomatik olarak yalnızca değişikliklerin uygulanmasını sağlar.

Uygulama Havuzu vb. Ben istiyorum seviyorum (bu otomatik edilecek bu soruya bakın ), ama en andan o kılavuzudur. Yine de bunu gerçekten değiştirmek istiyorum.

(kendi veri merkezimize ve sunucu çiftliğimizin "yerinde" olmasına muhtemelen yardımcı olur, bu nedenle birçok engeli aşmak zorunda kalmayız)

İnternet sitesi

Dağıtıcı: http://www.codeproject.com/KB/install/deployer.aspx

Web sitesini yerel bir klasöre yayınlıyorum, sıkıştırıyorum ve ardından FTP üzerinden yüklüyorum. Sunucu üzerindeki dağıtıcı daha sonra zip dosyasını çıkarır, yapılandırma değerlerini (Web.Config ve diğer dosyalarda) değiştirir ve işte bu kadar.

Elbette ilk çalıştırma için sunucuya bağlanmanız ve IIS WebSite, veritabanını kurmanız gerekir, ancak bundan sonra güncellemeleri yayınlamak çocuk oyuncağı.

Veri tabanı

Veritabanlarını senkronize tutmak için http://www.red-gate.com/products/sql-development/sql-compare/ kullanıyorum

Sunucu bir grup yönlendiricinin arkasındaysa ve doğrudan bağlanamıyorsanız (SQL Karşılaştırma'nın gereğidir), VPN oluşturmak için https://secure.logmein.com/products/hamachi2/ kullanın.

Çoğunlukla ASP.NET uygulamalarını Linux sunucularına dağıtıyorum ve en küçük değişiklik için bile her şeyi yeniden dağıtıyorum. İşte benim standart iş akışım:

• Bir kaynak kodu deposu kullanıyorum (Subversion gibi)
• Sunucuda, aşağıdakileri yapan bir bash betiğim var:
  • En son kodu kontrol eder
  • Derleme yapar (DLL'leri oluşturur)
  • Dosyaları esaslara göre filtreler (örneğin kod dosyalarını kaldırır)
  • Veritabanını yedekler
  • Dosyaları geçerli tarihle adlandırılan bir dizindeki web sunucusuna dağıtır
  • Dağıtıma yeni bir şema dahil edilirse veritabanını günceller
  • Yeni kurulumu varsayılan kurulum yapar, böylece bir sonraki isabetle sunulacaktır.

Kontrol, Subversion'ın komut satırı sürümü ile yapılır ve bina xbuild ile yapılır (msbuild, Mono projesinden benzer şekilde çalışır). Sihrin çoğu ReleaseIt'de yapılır.

Dev sunucumda esasen sürekli entegrasyona sahibim ancak üretim tarafında aslında sunucuya SSH veriyorum ve betiği çalıştırarak dağıtımı manuel olarak başlatıyorum. Benim betiğime akıllıca 'dağıtma' adı verildi, bu yüzden bash komut isteminde yazdığım şey bu. Ben çok yaratıcıyım Değil.

Üretimde, iki kez 'deploy' yazmalıyım: bir kez teslim almak, derlemek ve tarihli bir dizine dağıtmak için ve bir kez bu dizini varsayılan örnek yapmak için. Dizinler tarihli olduğundan, ilgili dizinin içinden 'deploy' yazarak önceki herhangi bir dağıtıma geri dönebilirim.

İlk dağıtım birkaç dakika sürer ve önceki bir sürüme geçiş birkaç saniye sürer.

Benim için güzel bir çözüm oldu ve yalnızca üç komut satırı yardımcı programına (svn, xbuild ve releaseit), DB istemcisine, SSH ve Bash'e güveniyor.

Bir ara CodePlex'te ReleaseIt kopyasını güncellemem gerekiyor:

http://releaseit.codeplex.com/

ASP.NET için basit XCopy. Sıkıştırın, sunucuya sftp, doğru yere çıkartın. İlk dağıtım için IIS'nin manuel kurulumu

Sorularınızı cevaplamak:

1. XCopy
2. Manuel olarak
3. Statik kaynaklar için, yalnızca değiştirilen kaynağı dağıtıyoruz.
   DLL'ler için değiştirilen DLL ve ASPX sayfalarını dağıtıyoruz.
4. Evet ve evet.

Güzel ve basit tutmak bizi şimdiye kadar pek çok baş ağrısından kurtardı.

Bazı özel araçlar mı yoksa sadece XCOPY mi kullanıyorsunuz? Uygulama nasıl paketlenir (ZIP, MSI, ...)?

BuildMaster için bir geliştirici olarak, doğal olarak kullandığım şey bu. Tüm uygulamalar, dahili olarak ZIP dosyaları olarak depolanan araç içinde yapay nesneler olarak oluşturulur ve paketlenir.

Bir uygulama ilk kez konuşlandırıldığında Uygulama Havuzunu ve Sanal Dizini nasıl kurarsınız (bunları manuel olarak mı yoksa bazı araçlarla mı oluşturuyorsunuz)?

Manuel olarak - araç içinde, uygulama test ortamlarında ilerlerken gelecekteki ortamlarda gerçekleştirilmesi gereken kesin adımları hatırlatan bir değişiklik kontrolü oluşturuyoruz. Bu aynı zamanda basit bir PowerShell betiği ile otomatik hale getirilebilir, ancak yeni uygulamaları çok sık eklemiyoruz, bu nedenle siteyi manuel olarak oluşturmak için gereken 1 dakikayı harcamak kadar kolay.

Statik bir kaynak değiştiğinde (CSS, JS veya görüntü dosyası) tüm uygulamayı mı yoksa yalnızca değiştirilen kaynağı mı yeniden dağıtırsınız? Bir derleme / ASPX sayfası değiştiğinde nasıl olur?

Varsayılan olarak, yapıları dağıtma süreci, yalnızca değiştirilen dosyalar hedef sunucuya aktarılacak şekilde ayarlanır - bu, CSS dosyalarından, JavaScript dosyalarından, ASPX sayfalarından ve bağlantılı derlemelerden her şeyi içerir.

Belirli bir uygulama için dağıtılan tüm sürümleri takip ediyor musunuz ve bir şeyler ters giderse, uygulamayı önceki bilinen çalışma durumuna geri yükleme prosedürleriniz var mı?

Evet, BuildMaster tüm bunları bizim için halleder. Geri yükleme, çoğunlukla eski bir yapı yükseltmesini yeniden çalıştırmak kadar basittir, ancak bazen veritabanı değişikliklerinin manuel olarak geri yüklenmesi gerekir ve veri kaybı meydana gelebilir. Temel geri alma süreci burada ayrıntılı olarak açıklanmıştır: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

web kurulumu / yükleme projeleri - bir şeyler ters giderse kolayca kaldırabilmeniz için

Unfold , .net uygulamaları için yazdığım capistrano benzeri bir dağıtım çözümüdür. Tüm projelerimizde kullandığımız şeydir ve çok esnek bir çözümdür. Rob Conery tarafından bu blog gönderisinde açıklandığı gibi .net uygulamaları için tipik sorunların çoğunu çözer.

• iyi bir "varsayılan" davranışa sahiptir, yani sizin için birçok standart şey yapar: kodu kaynak kontrolünden alma, oluşturma, uygulama havuzunu oluşturma, IIS'yi kurma vb.
• kaynak denetimindekilere dayalı sürümler
• sahip olduğu görev kanca varsayılan davranış kolayca uzatılabilir veya değiştirilebilir, böylece
• sahip olduğu geri alma
• hepsi powershell , yani herhangi bir harici bağımlılık yok
• uzak makinelere erişmek için powershell remoting kullanır

İşte bir giriş ve diğer bazı blog yazıları.

Yani yukarıdaki soruları cevaplamak için:

• Uygulama nasıl paketlenir (ZIP, MSI, ...)?

  Git (veya başka bir scm), uygulamayı hedef makineye almanın varsayılan yoludur. Alternatif olarak, yerel bir derleme gerçekleştirebilir ve sonucu Powereshell remoting bağlantısı üzerinden kopyalayabilirsiniz.

• Bir uygulama ilk kez konuşlandırıldığında Uygulama Havuzunu ve Sanal Dizini nasıl kurarsınız (bunları manuel olarak mı yoksa bazı araçlarla mı oluşturuyorsunuz)?

  Unfold, Powershell'in Web Yönetim Modülünü kullanarak uygulama havuzunu ve web sitesi uygulamasını yapılandırır. Bize (ve size) uygulama havuzunun veya web sitesinin herhangi bir yönünü değiştirmenize izin verir.

• Statik bir kaynak değiştiğinde (CSS, JS veya görüntü dosyası) tüm uygulamayı mı yoksa yalnızca değiştirilen kaynağı mı yeniden dağıtırsınız? Bir derleme / ASPX sayfası değiştiğinde nasıl olur?

  Evet bunu yapar, herhangi bir dağıtım diğerlerinin yanına kurulur. Bu şekilde bir şeyler ters gittiğinde kolayca geri alabiliriz. Ayrıca, konuşlandırılmış bir sürümü bir kaynak kontrol revizyonuna kadar kolayca geriye doğru takip etmemizi sağlar.

• Belirli bir uygulama için dağıtılan tüm sürümleri takip ediyor musunuz?

  Evet, aç, eski versiyonları etrafta tutar. Tüm sürümler değil, birkaç sürüm. Geri almayı neredeyse önemsiz hale getiriyor.

Geçtiğimiz yıl yayın sürecimizi iyileştiriyoruz ve şimdi onu indirdik. Tüm otomatik derlemelerimizi ve sürümlerimizi yönetmek için Jenkins kullanıyorum, ancak TeamCity veya CruiseControl'ü kullanabileceğinizden eminim.

Dolayısıyla, check-in üzerine, "normal" yapımız şunları yapar:

• Jenkins, kodun en son sürümünü almak için bir SVN güncellemesi yapar
• NuGet paketi geri yüklemesi, kendi yerel NuGet depomuzda çalıştırılarak yapılır
• Uygulama, MsBuild kullanılarak derlenmiştir. Bunu kurmak bir maceradır, çünkü doğru MsBuild'i ve ardından derleme kutunuza ASP.NET ve MVC dll'leri yüklemeniz gerekir. (Bir yan not olarak, <MvcBuildViews>true</MvcBuildViews>görünümleri derlemek için .csproj dosyalarıma girdiğimde, msbuild rastgele çöküyordu, bu yüzden onu devre dışı bırakmak zorunda kaldım)
• Kod derlendikten sonra birim testleri çalıştırılır (bunun için nunit kullanıyorum, ancak istediğiniz her şeyi kullanabilirsiniz)
• Tüm birim testleri başarılı olursa, IIS uygulama havuzunu durdurur, uygulamayı yerel olarak dağıtırım (gerekli dosyaları kopyalamak için yalnızca birkaç temel XCOPY komutu) ve ardından IIS'yi yeniden başlatırım (IIS kilitleme dosyalarıyla ilgili sorunlar yaşadım ve bu çözüldü o)
• Her ortam için ayrı web.config dosyalarım var; dev, uat, prod. (Web dönüştürme öğelerini çok az başarıyla kullanmayı denedim). Dolayısıyla, doğru web.config dosyası da
• Daha sonra bir dizi UI testi yürütmek için PhantomJS kullanıyorum. Ayrıca farklı çözünürlüklerde (mobil, masaüstü) bir dizi ekran görüntüsü alır ve her ekran görüntüsünü bazı bilgilerle (sayfa başlığı, çözünürlük) damgalar. Jenkins, bu ekran görüntülerini işlemek için harika bir desteğe sahip ve bunlar, yapının bir parçası olarak kaydedilir.
• Entegrasyon kullanıcı arayüzü testleri geçtikten sonra yapı başarılı olur

Birisi "UAT'ye Dağıt" ı tıklarsa:

• Son derleme başarılıysa, Jenkins başka bir SVN güncellemesi yapar
• Uygulama bir RELEASE konfigürasyonu kullanılarak derlendi
• Bir "www" dizini oluşturulur ve uygulama buna kopyalanır
• Daha sonra yapı kutusu ve UAT arasında dosya sistemini senkronize etmek için winscp kullanıyorum
• UAT sunucusuna bir HTTP isteği gönderiyorum ve 200'ü geri aldığımdan emin oluyorum
• Bu revizyon SVN'de UAT-datetime olarak etiketlendi
• Buraya kadar geldiysek, inşa başarılıdır!

"Üretime Dağıt" ı tıkladığımızda:

• Kullanıcı önceden oluşturulmuş bir UAT Etiketi seçer
• Etiket şu şekilde "değiştirildi":
• Kod, Üretim sunucusu ile derlenir ve senkronize edilir
• Üretim sunucusuna HTTP isteği
• Bu revizyon SVN'de Prod-datetime olarak etiketlendi
• Sürüm sıkıştırılır ve saklanır

Üretime kadar tüm yapının tamamı yaklaşık 30 saniye sürüyor ve bundan çok çok memnunum.

Bu çözümün avantajları:

• Hızlı
• Birim testleri mantık hatalarını yakalamalıdır
• Bir UI hatası üretime girdiğinde, ekran görüntüleri umarız hangi revizyonun buna neden olduğunu gösterecektir.
• UAT ve Prod senkronize tutulur
• Jenkins, tüm commit mesajlarıyla size UAT ve Prod için harika bir sürüm geçmişi gösterir
• UAT ve Prod sürümlerinin tümü otomatik olarak etiketlenir
• Yayınların ne zaman gerçekleştiğini ve bunları kimin yaptığını görebilirsiniz

Bu çözümün ana dezavantajları:

• Üretim sürümüne her yayınladığınızda, UAT sürümüne sürüm yapmanız gerekir. Bu, verdiğimiz bilinçli bir karardı çünkü UAT'nin her zaman Prod ile güncel olmasını sağlamak istiyorduk. Yine de bu bir acı.
• Etrafta dolaşan epeyce yapılandırma dosyası var. Hepsini Jenkins'te almaya çalıştım, ancak sürecin bir parçası olarak gereken birkaç destek toplu iş dosyası var. (Bunlar da kontrol edilir).
• DB yükseltme ve düşürme komut dosyaları uygulamanın bir parçasıdır ve uygulama başlangıcında çalıştırılır. Çoğunlukla işe yarıyor, ama bu bir acı.

Diğer olası iyileştirmeleri duymak isterim!

Bu cevabın geldiği 2009 yılında, aynı zamanda Release Media çıktısı da veren Sürekli Entegrasyon yapılarımız için CruiseControl.net'i kullandık.

Buradan , yük dengeleme havuzunun dışında kalan bir üretim sunucusuyla karşılaştırmak için Smart Sync yazılımını kullandık ve değişiklikleri yukarı taşıdık.

Son olarak, sürümü doğruladıktan sonra, kodu canlı sunucularla senkronize etmek için öncelikle RoboCopy'yi kullanan ve IIS'yi durduran / başlatan bir DOS komut dosyası çalıştırdık.

Çalıştığım son şirkette, yalnızca son yüklemeden sonraki değişiklikleri yüklemek için bir rSync toplu iş dosyası kullanarak konuşlandırırdık. RSync'in güzelliği, belirli dosyaları veya dosya adı kalıplarını dışlamak için dışlama listeleri ekleyebilmenizdir. Dolayısıyla, örneğin tüm .cs dosyalarımızı, çözümlerimizi ve proje dosyalarımızı hariç tutmak gerçekten kolaydır.

Sürüm kontrolü için TortoiseSVN kullanıyorduk ve bu nedenle aşağıdakileri gerçekleştirmek için birkaç SVN komutu yazabilmek güzeldi:

• Öncelikle, kullanıcının en son revizyona sahip olduğunu kontrol edin. Değilse, güncellemelerini hemen orada ve ardından çalıştırmalarını isteyin.
• Sunucudan "synclog.txt" adlı, SVN kullanıcısının kim olduğunu, yüklediği revizyon numarasını ve yüklemenin tarih ve saatini ayrıntılarıyla anlatan bir metin dosyası indirin. Geçerli yükleme için yeni bir satır ekleyin ve ardından değiştirilen dosyalarla birlikte sunucuya geri gönderin. Bu, bir yüklemenin sorunlara neden olması ihtimaline karşı sitenin hangi sürümünün geri alınacağını bulmayı son derece kolaylaştırır.

Buna ek olarak, yalnızca canlı sunucudaki dosya farklılıklarını kontrol eden ikinci bir toplu iş dosyası vardır. Bu, bir kişinin yüklediği ancak değişikliklerini SVN'ye kaydetmediği yaygın sorunu vurgulayabilir. Yukarıda bahsedilen senkronizasyon günlüğü ile birleştirildiğinde, olası suçlunun kim olduğunu bulabilir ve onlardan işlerini yapmalarını isteyebiliriz.

Ve son olarak, rSync, yükleme sırasında değiştirilen dosyaların yedeğini almanıza izin verir. Onları bir yedekleme klasörüne taşımıştık. Dolayısıyla, aniden bazı dosyaların üzerine yazılmaması gerektiğini fark ettiyseniz, o klasördeki her dosyanın son yedek sürümünü bulabilirsiniz.

O zamandan beri çözüm biraz hantal görünse de, yükleme yönteminin çok daha az zarif veya kolay olduğu ortamlarda çalışırken (örneğin, uzak masaüstü, tüm siteyi kopyalayıp yapıştırın) onu çok daha fazla takdir etmeye başladım. .

Sadece mevcut uygulama dosyalarının üzerine YAZMAYI, bunun yerine her sürüm için bir dizin oluşturmanızı ve IIS uygulamasını yeni yola yeniden işaretlemenizi tavsiye ederim. Bunun birkaç faydası vardır:

• Gerekirse hızlı geri dönüş
• Kilitlenme sorunlarını önlemek için IIS'yi veya uygulama havuzunu durdurmaya gerek yok
• Eski dosyaların sorunlara neden olma riski yok
• Az ya da çok sıfır kesinti süresi (genellikle yeni uygulama alanı başlangıçlarında sadece bir duraklama)

Karşılaştığımız tek sorun, uygulama havuzunu yeniden başlatmazsanız ve otomatik uygulama alan adı anahtarına güveniyorsanız kaynakların önbelleğe alınmasıdır.