Jak wdrażasz swoją aplikację sieciową .NET? (Zalecenia, proszę!)

Niedawno zaktualizowaliśmy naszą witrynę ASP.NET do aplikacji sieci Web i jesteśmy zaskoczeni nagłym skokiem trudności podczas jej wdrażania. Biorąc pod uwagę, jak często musi to być zadanie, zastanawiałem się, jakich wtyczek / oprogramowania używają ludzie do wdrażania szybko rozwijającego się, zdalnie przechowywanego projektu (np. Strony internetowej)?

Musi istnieć lepszy sposób niż tylko „publikowanie” w Visual Studio, a następnie konieczność ręcznego przesyłania FTP zmienionych plików? Nie tylko dlatego, że strona przestaje działać, gdy przesyłamy nasze pliki .DLL.

Jest tak wiele wyjątkowych plików, że wolałbym maksymalnie zautomatyzować ten proces, aby zapobiec przypadkowemu przesłaniu.

W naszym starym rozwiązaniu (na naszej stronie internetowej) użyliśmy Dispatch for ASP, który całkowicie zadziałał i sprawił, że cały proces jednym kliknięciem. Niestety nie jest to świetne dla bibliotek DLL (jak wspomniano wcześniej).

Jak więc robi to Twój zespół?

Dziękuję za wszelkie porady.

PS - Czytałem, że Visual Studio 2010 ma zaradzić tym niedociągnięciom w VS2005 / 08, ale do tego czasu ...

Zdecydowanie polecam używanie ciągłej integracji.

Używamy kombinacji TeamCity dla CI, Rake i Albacore do automatyzacji kompilacji.

TeamCity sprawdzi kod z repozytorium kodu źródłowego, a następnie przy użyciu Rake zbuduje aplikację, wykona testy jednostkowe, a nawet uruchomi skrypty bazy danych, jeśli chcesz. Po udanej kompilacji możesz spakować kod źródłowy w pliku zip lub skopiować go do wybranego miejsca docelowego.

Używamy Git, chociaż TeamCity działa ze wszystkimi systemami kontroli źródła.

Korzystanie z TeamCity i Rake'a byłoby podobne do korzystania z CruiseControl i NANT, bez edycji pliku XML. Oczywiście możesz używać TeamCity z NANT, jeśli wolisz.

Krótka próbka pobrana z pliku rakefile.rb, który wykonuje kompilację. IMHO, łatwiejszy do odczytania i debugowania niż plik XML.

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 to zestaw zadań prowizji opracowanych specjalnie do wdrażania aplikacji .NET.

W systemie Linux używałem fabric (fabfile.org) i capistrano (capify.org), które są narzędziami automatyzacji do pomocy w zdalnych poleceniach SSH i SCP. Jeśli masz Cygwin zainstalowany na swoich hostach Windows, powinieneś być w stanie użyć ich ponownie jako narzędzi do wdrażania.

„Publikowanie” aplikacji sieci Web w programie Visual Studio można uruchomić z wiersza polecenia jako msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". Katalog docelowy to wdrażalna aplikacja internetowa.

Inne odpowiedzi dotyczące twojego większego pytania są dobre. Dodam również, że powinieneś przyjrzeć się kilku projektom aplikacji internetowych typu open source i skopiować proces kompilacji, który najbardziej ci się podoba.

Zgadzam się ze Scottem, że może to być bardzo skomplikowane i łatwe do przeoczenia. Strategia wdrażania jest również bardzo specyficzna dla aplikacji. Jeśli aplikacja jest całkowicie samodzielna w jednym folderze, może być łatwiejsza niż aplikacja, która odwołuje się do GAC. Co z kolei może być łatwiejsze niż serwer, który musi utrzymywać wiele wersji aplikacji, która odwołuje się do wielu wersji zestawów GAC. Nie chcemy tutaj rozmawiać o plikach zasad :).

Powiedziawszy jednak, że połączenie narzędzia Microsoft Web Deployment Tool z routingiem żądań aplikacji to jedna dobra opcja. W IIS7 można tworzyć pakiety instalacyjne za pomocą tego narzędzia. Możliwe jest również skierowanie narzędzia do aplikacji internetowej i utworzenie kopii zapasowej całej aplikacji w folderze archiwum aplikacji. Następnie można wdrożyć z tego folderu archiwum na serwerze sieci Web IIS6 lub IIS7 (IIS5 nie jest obsługiwany). Używałbym routingu żądań aplikacji, jak sugerował Scott, aby oddzielić transmisje na żywo od testowych stron internetowych. Po sprawdzeniu, czy nowo opublikowana witryna jest dobra, możesz ustawić ARR tak, aby kierowała się do nowej wersji.

PyroBatchFTP świetnie się do tego nadaje . Popchnie tylko zmiany i możesz je napisać w skrypcie, abyś mógł pchnąć podwójnym kliknięciem pliku wsadowego.

W Vaasnet przygotowaliśmy dla siebie wymarzone rozwiązanie, ale konfiguracja jest dość zaangażowana, ale jeśli możesz, warto użyć niektórych lub wszystkich tych elementów. Oto co to jest:

• SVN na wszystkich naszych maszynach programistycznych
• SVN na naszym serwerze kompilacji / wdrażania
• Cruisecontrol.net obserwuje zmiany w SVN i tworzy i umieszcza tylko niezbędne pliki w folderze przemieszczania
• Korzystając z PyroBatchFTP, pchamy na stronę testową (uruchamianą przez Cruisecontrol, więc dzieje się to automatycznie)
• przy użyciu IIS7 i routingu żądań aplikacji (ARR) i przepisywania adresów URL mamy następującą konfigurację etapową / produkcyjną:
  • ARR z góry przekieruje ruch do instancji 01 lub 02, w zależności od tego, która z nich jest „na żywo”, a która „inscenizacja”
  • konto FTP jest zawsze powiązane z „inscenizacją”
  • Mam inną mini-stronę administracyjną, która za jednym kliknięciem zamieni inscenizację. Przełączanie trwa zero sekund i możemy przełączyć się ponownie, jeśli zdamy sobie sprawę, że coś było nie tak z tym wydaniem (chociaż jest to rzadkie, ponieważ możemy to łatwo przetestować przed uruchomieniem).

Tak więc wynik netto pozwala nam na sprawdzenie SVN i automatyczne zbudowanie go i przejście do produkcji bez jakiejkolwiek ręcznej interakcji. Po przetestowaniu naszego tymczasowego adresu URL i stwierdzeniu, że jest gotowy do uruchomienia, logujemy się do prostej witryny i za pomocą jednego kliknięcia można go uruchomić.

Aby uzyskać inny sposób, który nie został zasugerowany, odsyłam do projektów GU i Web Setup

To w zasadzie tworzy instalator MSI dla aplikacji .NET. Ten przykład dotyczy VS2005, ale mam VS2010 i typ projektu nadal tam jest. Może to dać wiele możliwości dostosowania, jeśli jest to potrzebne, lub tylko podstawową instalację, jeśli nie jest to konieczne.

Osobiście tam, gdzie pracuję, po prostu wykonujemy wdrożenie w stylu xcopy, ale ostatecznie chciałbym po prostu przekazać pakiet grupie serwerów, dając im kontrolę nad tym, kiedy i jak jest wdrażany. (Myślę, że może to również ułatwić masowe wdrażanie przy użyciu czegoś takiego jak zasady grupy, ale nie jestem zbyt dobrze zaznajomiony z tym)

Jest wiele sposobów na skórowanie tego kota, tak naprawdę zależy od tego, ile masz dostępu do swojego serwera. Moją osobistą ulubioną metodą ostatnio jest skonfigurowanie skryptu kompilacji w projekcie (zwykle przy użyciu MSBUILD), który pakuje wszystkie pliki wdrażania, a następnie użycie SVN do połączenia ich z produkcją. I do wersji plików produkcyjnych.

Jeśli chodzi o bazę danych, najlepszym rozwiązaniem jest użycie jakiegoś frameworka migracji. Ponownie, grupa tych, którzy biegają i nie ma naprawdę jasnej odpowiedzi.

Osobiście używam po prostu skryptu VBS, który sam napisałem, aby skopiować foldery określonych typów plików na serwer deweloperski (tzn. Pominąć pliki CS itp.).

Kiedy pracowałem w dużej firmie .com, zrobiliśmy to z naszymi wdrożeniami .net.

Cały nasz kod źródłowy i procedury składowane były przechowywane w SVN. Każdej nocy uruchamiane jest zadanie bazy danych, a następnie pobierane są przechowywane procesy produkcyjne i wsuwane do katalogu na SVN, tak aby zawsze była najbardziej aktualna wersja w kontroli źródła.

W dniu wdrożenia projektu użylibyśmy skryptu nAnt, aby pobrać projekty z SVN, wykonać niestandardową kompilację projektów i wyciągnąć wszelkie zależności potrzebne tym projektom. Po uruchomieniu skryptu nAnt spakowano go do samorozpakowującego się pliku zip. Zapisane procy, które były powiązane z tym wdrożeniem, zostały sprawdzone w kontroli źródła, a arkusz kalkulacyjny programu Excel został zaktualizowany o skrypty, które mają być uruchamiane i w jakiej kolejności.

Kiedy uruchomił się deploymenet, samorozpakowujący się plik zip został przesłany na serwer, na którym został uruchomiony. Wszystkie pliki zostały wyodrębnione do właściwych katalogów, a DBA uruchomiło przechowywane procy w bazie danych prodcution.

W typowym wdrożeniu przy użyciu tego systemu przeszliśmy z wdrożenia w pięć do sześciu godzin do mniej niż godziny.

Powodzenia i mam nadzieję, że pomoże to niektórym w opracowaniu sposobu wdrożenia aplikacji.

Musi istnieć lepszy sposób niż tylko „publikowanie” w Visual Studio, a następnie konieczność ręcznego przesyłania FTP zmienionych plików?

Brzytwa Ockhama jest zazwyczaj preferowanym podejściem: im prościej, tym lepiej. FTP jest łatwy i nie wymaga żadnych komplikacji. Niektóre osoby używają XCOPY, Filezilla lub WSFTP, inne mogą korzystać z narzędzia MS Web Deployment Tool (którego jeszcze nie znam), ale ogólnie rzecz biorąc, istnieje lepszy sposób wdrażania aplikacji internetowych ASP.NET (i innych aplikacje ogólnie). IMO, jeśli wdrażanie jest brane pod uwagę od samego początku rozwoju, wdrożenie można zintegrować z aplikacją internetową, co zapewnia względnie bezbolesne i płynne wdrożenie w przyszłości.

Jako programista .NET, który pracował w kilku firmach tworzących aplikacje internetowe ASP.NET o różnych rozmiarach, złożoności i liczbie użytkowników (od kilkuset użytkowników do dziesiątek tysięcy), „wdrożenie” IMO jest często najbardziej „płynnym” tematem. Niektóre organizacje idą za daleko pod względem biurokracji, podczas gdy inne nie rozwiązują żadnych problemów z wdrożeniem. Z mojego doświadczenia wynika, że ​​problemy z wdrażaniem należą do co najmniej jednej z 3 kategorii pod względem trudności / awarii:

1. Wdrażanie jest dogłębnie ignorowane / zapomniane na etapie projektowania: większość aplikacji internetowych zwykle zawiera serwer WWW i bazę danych. Oprócz kodu aplikacji, być może niektórych procedur przechowywanych i tabel bazy danych, wdrożenie nie wymaga wiele przemyślenia. ASP.NET jest więcej niż w stanie pomóc we wdrożeniu, ale najczęściej programiści są rozproszeni, jeśli chodzi o uruchomienie rzeczywistej aplikacji i wykonanie jej zadania, pozostawiając sposób wdrażania jako osobny problem.

2. Wdrożenie jest skomplikowane w wielu systemach i ludziach: Złożoność to dziwka. Od MSMQ, procedur przechowywanych T-SQL i wyzwalaczy, Reporting Services, przesyłania komunikatów SOAP / XML, uwierzytelniania AD, SSAS / SSIS itp. Itd. Liczba stosowanych technologii zwiększa liczbę zaangażowanych osób. Co najgorsze, wszystkie te różne składniki są zazwyczaj zarządzane przez różne podmioty w organizacji. O ile wszyscy nie są ze sobą zsynchronizowani, wdrożenia mogą szybko wzrosnąć, co prowadzi do wielu punktów awarii.

3. Lenistwo, apatia lub brak komunikacji i / lub zarządzania: Od małej dokumentacji do braku dokumentacji po brak skoordynowanej komunikacji i protokołu, łatwo jest popsuć stosunkowo prosty proces. Wdrożenie powinno być prostą procedurą z licznymi kontrolami przez cały czas dokumentującymi co zostało zrobione, ale często tak nie jest. Większość ludzi chce, żeby ta cholerna strona działała. Z mojego doświadczenia wynika , że ludzie (nie-programiści) tak naprawdę nie dbają, dopóki coś nie stanie się naprawdę fubarowe. Odpowiedzialność rzadko spoczywa na jednej osobie, która faktycznie wykonuje wdrożenie, ponieważ nikt tak naprawdę nie chce być przyczyną niepowodzenia, więc odpowiedzialność jest zwykle rozproszona.

Jest tak wiele wyjątkowych plików, że wolałbym maksymalnie zautomatyzować ten proces, aby zapobiec przypadkowemu przesłaniu. Jak więc robi to Twój zespół?

Nie znam żadnych dostawców, którzy mogliby zautomatyzować wdrażanie, chociaż nie byłbym zaskoczony, gdyby było kilku. Prawdopodobnie możesz napisać rozwiązanie za pomocą VBScript / WMI lub wykonać skrypt wsadowy, ale w rzeczywistości musisz dostosować rozwiązanie do bardziej złożonych witryn ASP.NET. Proste witryny składające się ze stron, połączeń z bazą danych i nic więcej, nie musisz robić prawie tyle, więc skaluj wysiłki związane z wdrażaniem zgodnie ze złożonością samej aplikacji.

Do tej pory w mojej obecnej pracy nadal wdrażanie odbywa się za pośrednictwem FTP i przenoszenia wielu plików. Jest brzydki, łatwy do zepsucia i nie ma poczucia dokładnej historii. To prawda, że ​​możesz przeczesywać dzienniki FTP, nikt tak naprawdę nie zawraca sobie tym głowy. Nasze aplikacje są dość proste, bez potrzeby korzystania z FTP. Sposób, w jaki mój zespół wdraża nasze aplikacje internetowe, jest dla ciebie bardzo mało przydatny. Zamiast tego wolałbym skorzystać z okazji, by zaproponować lepsze praktyki.

• Nie zakładaj niczego. Konta użytkowników, uprawnienia R / W / X, listy ACL, zapory ogniowe, czas (kiedy należy wdrożyć i ile czasu trzeba to zrobić) oraz, jeśli to możliwe, przetestować wdrożenie we wszystkich środowiskach przed ostateczną „datą uruchomienia”.
• Zanim faktycznie zacznie się programowanie, uwzględnij wdrożenie w programowaniu. Jeśli to prosta strona, niech tak będzie. Jeśli jest wiele ruchomych części, weź to wszystko pod uwagę i faktycznie zbuduj plan, do którego wszystkie komponenty (kod, baza danych, raporty, kolejki itp.) Są w tym samym planie.
• Koordynuj z innymi parytetami i komunikuj się skutecznie i wydajnie.
• Dokumentuj jak najwięcej istotnych informacji, jeśli to możliwe.
• Środowisko: jeden serwer internetowy a farma internetowa; 32-bit vs. 64-bit; znajdź sposób monitorowania dzienników / błędów / rotacji itp.
• Znajdź (lub skompiluj) narzędzia, które mogą pomóc we wdrożeniu.
• Jeśli to możliwe dla programowalnego wdrożenia, wybierz paradygmat i trzymaj się go. Na przykład, jeśli chcesz użyć serwera bazy danych jako podstawowego sposobu przeprowadzania stanu aplikacji, wdrażania, dostępu itp., Upiecz ją w aplikacji i trzymaj się jej. Jeśli wolisz czytać pliki XML (jak web.config) za wszelką cenę, po prostu trzymaj się spójnego paradygmatu wdrażania aplikacji. Inny przykład: niektóre organizacje pozostawiają plik web.config jako plik statyczny w każdym środowisku, którego nie należy wdrażać w innych środowiskach. Program web.config innego użytkownika w taki sposób, że można go wdrożyć w różnych środowiskach bez błędów.

Zdaję sobie sprawę, że ten post może być przesadą w stosunku do pierwotnie zadanego pytania. Niestety wdrożenie nie jest proste, ponieważ aplikacje mogą mieć różną złożoność. Założę się, że większość organizacji wdrażających złożone aplikacje ASP.NET z czasem opracowało pewne strategie, które działają (przynajmniej) niezawodnie.