Làm thế nào để bạn triển khai ứng dụng .NET Web của bạn? (Khuyến nghị, xin vui lòng!)

Gần đây chúng tôi đã nâng cấp trang web ASP.NET của chúng tôi lên một ứng dụng web và chúng tôi bị sốc bởi bước nhảy đột ngột gặp khó khăn khi triển khai nó. Xem xét mức độ phổ biến của một nhiệm vụ này, tôi đã tự hỏi những người dùng phần mềm / phần mềm nào sử dụng để triển khai một dự án phát triển nhanh, được lưu trữ từ xa (ví dụ: một trang web)?

Có phải là một cách tốt hơn là chỉ "Xuất bản" trong Visual Studio và sau đó phải FTP thủ công các tệp đã thay đổi? Không ít nhất vì trang web bị sập khi chúng tôi tải lên .DLL của chúng tôi.

Có rất nhiều trường hợp ngoại lệ tập tin khó hiểu mà tôi phải tự động hóa quá trình càng nhiều càng tốt, để ngăn chặn việc tải lên ngẫu nhiên.

Với giải pháp cũ của chúng tôi (trên WebSite của chúng tôi), chúng tôi đã sử dụng Dispatch cho ASP , hoàn toàn làm rung chuyển và thực hiện toàn bộ quá trình chỉ bằng một cú nhấp chuột. Thật không may, nó không tuyệt vời cho DLL (như đã đề cập trước đó).

Vậy làm thế nào để nhóm của bạn làm điều đó?

Cảm ơn vì lời khuyên nào.

Tái bút - Tôi đã đọc rằng Visual Studio 2010 có nghĩa vụ phải giải quyết những thiếu sót này trong VS2005 / 08, nhưng cho đến lúc đó ...

Tôi thực sự khuyên bạn nên sử dụng Tích hợp liên tục.

Chúng tôi sử dụng kết hợp TeamCity cho CI, Rake và Albacore để tự động hóa bản dựng.

TeamCity sẽ kiểm tra mã ra khỏi kho lưu trữ mã nguồn của bạn, sau đó, sử dụng Rake, xây dựng ứng dụng, thực hiện kiểm tra đơn vị và thậm chí chạy các tập lệnh cơ sở dữ liệu của bạn nếu bạn muốn. Sau khi xây dựng thành công, bạn có thể đóng gói mã nguồn của mình trong tệp zip hoặc sao chép mã đó đến đích bạn chọn.

Chúng tôi sử dụng Git, mặc dù TeamCity hoạt động với tất cả các hệ thống kiểm soát nguồn.

Sử dụng TeamCity và Rake sẽ tương tự như sử dụng CruiseControl và NANT, mà không cần chỉnh sửa tệp XML. Tất nhiên, bạn có thể sử dụng TeamCity với NANT nếu bạn thích.

Một mẫu ngắn được lấy từ rakefile.rb thực hiện việc xây dựng. IMHO, dễ đọc và gỡ lỗi hơn tệp 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 là bộ các tác vụ Rake được xây dựng đặc biệt để triển khai ứng dụng .NET.

Trên Linux, tôi đã sử dụng vải (fabfile.org) và capistrano (capify.org) là các công cụ tự động hóa để hỗ trợ các lệnh SSH và SCP từ xa. Nếu bạn đã cài đặt Cygwin trên máy chủ windows của mình, bạn sẽ có thể sử dụng lại chúng làm công cụ triển khai.

"Xuất bản" một ứng dụng web trong Visual Studio có thể được chạy từ dòng lệnh như msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". Thư mục đích là một ứng dụng web có thể triển khai.

Các câu trả lời khác bao gồm câu hỏi lớn hơn của bạn là tốt. Tôi cũng nói thêm rằng bạn nên xem xét một số dự án ứng dụng web nguồn mở và sao chép quy trình xây dựng mà bạn thích nhất.

Tôi đồng ý với Scott rằng điều này có thể rất phức tạp và dễ bị bỏ qua. Chiến lược triển khai là rất cụ thể ứng dụng là tốt. Nếu ứng dụng của bạn hoàn toàn độc lập trong một thư mục, nó có thể dễ dàng hơn ứng dụng tham chiếu GAC. Đến lượt nó có thể vẫn dễ dàng hơn một máy chủ cần duy trì nhiều phiên bản của một ứng dụng tham chiếu nhiều phiên bản lắp ráp GAC. Chúng tôi không muốn bắt đầu nói về các tệp chính sách ở đây :).

Đã nói tất cả rằng việc kết hợp Công cụ triển khai Web của Microsoft với Định tuyến yêu cầu ứng dụng là một lựa chọn tốt. Trong IIS7, có thể tạo các gói cài đặt bằng công cụ. Cũng có thể trỏ công cụ vào một ứng dụng web và sao lưu toàn bộ ứng dụng vào một thư mục lưu trữ ứng dụng. Sau đó, bạn có thể triển khai từ thư mục lưu trữ này lên IIS6 hoặc máy chủ web IIS7 (IIS5 không được hỗ trợ). Tôi sẽ sử dụng định tuyến yêu cầu ứng dụng như Scott đề xuất để tách trực tiếp khỏi các trang web thử nghiệm. Khi bạn đã xác minh trang web mới được xuất bản là tốt, bạn có thể đặt ARR để định tuyến đến phiên bản mới.

PyroBatchFTP hoạt động tuyệt vời cho việc này. Nó sẽ chỉ đẩy các thay đổi và bạn có thể viết kịch bản để bạn có thể đẩy bằng cách nhấp đúp vào tệp bó.

Tại Vaasnet, chúng tôi đã thiết lập giải pháp mơ ước cho chính mình, nhưng nó khá liên quan đến việc thiết lập nhưng đáng để sử dụng một số hoặc tất cả các yếu tố này nếu bạn có thể. Đây là những gì:

• SVN trên tất cả các máy dev của chúng tôi
• SVN trên máy chủ xây dựng / triển khai của chúng tôi
• Cruisecontrol.net theo dõi các thay đổi đối với SVN và sẽ xây dựng và tạo các tệp cần thiết cho một thư mục dàn
• sử dụng PyroBatchFTP, chúng tôi đẩy đến một trang dàn dựng (được kích hoạt bởi Cruisecontrol để nó tự động xảy ra)
• sử dụng IIS7 và Định tuyến yêu cầu ứng dụng (ARR) và Viết lại URL, chúng tôi có thiết lập dàn / sản xuất sau:
  • ARR lên phía trước sẽ hướng lưu lượng truy cập đến một trong hai trường hợp 01 hoặc 02, tùy thuộc vào cái nào là 'trực tiếp' và cái nào là 'dàn dựng'
  • tài khoản FTP luôn bị ràng buộc để 'dàn dựng'
  • Tôi có một trang web quản trị nhỏ khác sẽ trao đổi dàn dựng và sống với một cú nhấp chuột duy nhất. Phải mất tất cả 1 giây để chuyển đổi với thời gian chết bằng 0 và chúng tôi có thể chuyển đổi trở lại nếu chúng tôi nhận ra rằng có điều gì đó không ổn với bản phát hành đó (mặc dù rất hiếm khi chúng tôi có thể kiểm tra nó dễ dàng trước khi phát hành trực tuyến).

Vì vậy, kết quả ròng cho phép chúng tôi đăng ký vào SVN và để nó tự động xây dựng và đẩy vào sản xuất mà không có bất kỳ tương tác thủ công nào. Sau khi chúng tôi kiểm tra URL phân tầng của mình và xác định rằng nó đã sẵn sàng để phát hành, chúng tôi đăng nhập vào một trang web đơn giản và chỉ với 1 cú nhấp chuột, nó đã hoạt động.

Đối với một cách khác chưa được đề xuất, tôi giới thiệu bạn đến ' Dự án thiết lập web và hướng dẫn

Điều này về cơ bản tạo ra một trình cài đặt MSI cho ứng dụng .NET của bạn. Ví dụ này là cho VS2005, nhưng tôi có VS2010 và loại dự án vẫn còn đó. Điều này có thể cung cấp cho bạn rất nhiều tùy chỉnh nếu bạn cần, hoặc chỉ cài đặt cơ bản nếu bạn không.

Cá nhân tôi làm việc ở đâu, chúng tôi chỉ thực hiện triển khai theo kiểu xcopy, nhưng cuối cùng tôi chỉ muốn giao một gói cho nhóm máy chủ, cho họ quyền kiểm soát khi nào và cách triển khai. (Tôi nghĩ rằng điều này cũng có thể giúp triển khai hàng loạt dễ dàng hơn bằng cách sử dụng chính sách như chính sách nhóm, nhưng tôi không quá quen thuộc với điều đó)

Có rất nhiều cách để chăm sóc con mèo này, thực sự phụ thuộc vào số lượng truy cập bạn có thể có trên máy chủ của mình. Phương pháp muộn yêu thích cá nhân của tôi là thiết lập một tập lệnh xây dựng trong dự án (thường sử dụng MSBUILD) để đóng gói tất cả các tệp triển khai, sau đó sử dụng SVN để kết nối chúng vào sản xuất. Và để phiên bản các tập tin sản xuất.

Cơ sở dữ liệu, đặt cược tốt nhất là sử dụng một số loại khung di chuyển. Một lần nữa, một loạt những người chạy về và không có câu trả lời rõ ràng thực sự.

Cá nhân tôi chỉ sử dụng một tập lệnh vbs mà tôi đã tự viết để sao chép các thư mục của các kiểu tệp cụ thể vào máy chủ dev (tức là bỏ các tệp cs, v.v.).

Khi tôi làm việc tại một công ty lớn, đây là những gì chúng tôi đã làm với việc triển khai .net của chúng tôi.

Tất cả các mã nguồn và thủ tục lưu trữ của chúng tôi được lưu trữ trong SVN. Mỗi đêm, một công việc cơ sở dữ liệu chạy và kéo các procs lưu trữ sản xuất và đưa chúng vào một thư mục trên SVN để luôn có một phiên bản mới nhất trong điều khiển nguồn.

Vào ngày triển khai cho một dự án, chúng tôi sẽ sử dụng tập lệnh nAnt để lấy các dự án từ SVN, thực hiện xây dựng tùy chỉnh các dự án và kéo bất kỳ sự phụ thuộc nào mà các dự án này cần. Khi tập lệnh nAnt được chạy, nó được đóng gói thành tệp zip tự giải nén. Các procs được lưu trữ có liên quan đến việc triển khai này đã được kiểm tra trong kiểm soát nguồn và một bảng tham chiếu excel đã được cập nhật với các tập lệnh để chạy và theo thứ tự.

Khi deploymenet tắt, tệp zip tự giải nén được chuyển đến máy chủ nơi nó được khởi chạy. Tất cả các tệp được trích xuất vào các thư mục chính xác và DBA đã chạy các procs được lưu trữ trên cơ sở dữ liệu prodcutions.

Trong một triển khai điển hình sử dụng hệ thống này, chúng tôi đã chuyển từ triển khai năm đến sáu giờ xuống dưới một giờ hoặc ít hơn.

Chúc may mắn và hy vọng điều này sẽ giúp một số người trong việc tìm ra cách triển khai ứng dụng của bạn.

Có phải là một cách tốt hơn là chỉ "Xuất bản" trong Visual Studio và sau đó phải FTP thủ công các tệp đã thay đổi?

Dao cạo của Occam thường là phương pháp ưa thích: càng đơn giản, càng tốt. FTP rất dễ dàng với ít hoặc không có biến chứng. Một số người sử dụng XCOPY, Filezilla hoặc WSFTP, những người khác có thể sử dụng Công cụ triển khai web MS (mà tôi chưa quen), nhưng tất cả, có một cách tốt hơn để triển khai các ứng dụng web ASP.NET (và khác ứng dụng nói chung). IMO, nếu việc triển khai được xem xét từ khi bắt đầu phát triển, việc triển khai có thể được tích hợp với ứng dụng web giúp triển khai tương đối dễ dàng và suôn sẻ trong tương lai.

Là một nhà phát triển .NET, người đã làm việc tại một số công ty phát triển các ứng dụng web ASP.NET có quy mô, độ phức tạp và số lượng người dùng (từ vài trăm người dùng đến hàng chục nghìn), IMO 'triển khai' thường là chủ đề "trôi chảy" nhất. Một số tổ chức đưa nó đi quá xa về mặt quan liêu trong khi những tổ chức khác không giải quyết bất kỳ vấn đề nào với việc triển khai. Theo kinh nghiệm của tôi, các vấn đề với việc triển khai có xu hướng rơi vào 1 hoặc nhiều hơn 3 loại về những khó khăn / thất bại:

1. Triển khai bị bỏ qua / quên sâu trong giai đoạn thiết kế: Hầu hết các ứng dụng web có xu hướng kết hợp máy chủ web và cơ sở dữ liệu. Ngoài mã ứng dụng, có thể một số thủ tục được lưu trữ và bảng cơ sở dữ liệu, việc triển khai không cần nhiều suy nghĩ. ASP.NET không chỉ có khả năng hỗ trợ triển khai, nhưng hầu hết các nhà phát triển thường bị phân tâm về việc làm cho ứng dụng thực sự chạy và thực hiện nhiệm vụ của nó trong khi để lại cách triển khai như một vấn đề riêng biệt.

2. Triển khai rất phức tạp trên nhiều hệ thống và mọi người đang chơi: Sự phức tạp là một con chó cái. Từ MSMQ, các thủ tục và trình kích hoạt được lưu trữ T-SQL, Dịch vụ báo cáo, nhắn tin SOAP / XML, xác thực AD, SSAS / SSIS, v.v., số lượng công nghệ đang chơi tăng số lượng người tham gia. Tệ nhất là tất cả các thành phần khác nhau này thường được quản lý bởi các thực thể khác nhau trong một tổ chức. Trừ khi tất cả mọi người đồng bộ với nhau, việc triển khai có thể tăng độ phức tạp nhanh chóng dẫn đến nhiều điểm thất bại.

3. Lười biếng, thờ ơ hoặc thiếu giao tiếp và / hoặc quản lý: Từ ít đến không có tài liệu đến thiếu giao tiếp và giao thức phối hợp, thật dễ dàng để thực hiện một quy trình tương đối đơn giản. Triển khai nên là một thủ tục đơn giản với nhiều kiểm tra được thực hiện trong khi ghi lại những gì đã làm, nhưng thường thì không bao giờ như vậy. Hầu hết mọi người chỉ muốn trang web chết tiệt này hoạt động. Theo kinh nghiệm của tôi, mọi người (không phải lập trình viên) không thực sự quan tâm cho đến khi một cái gì đó thực sự xuất hiện . Trách nhiệm hiếm khi rơi vào chỉ một người để thực sự làm việc triển khai như không ai thực sự muốn trở thành lý do cho sự thất bại nên trách nhiệm giải trình được thường phân tán.

Có rất nhiều trường hợp ngoại lệ tập tin khó hiểu mà tôi phải tự động hóa quá trình càng nhiều càng tốt, để ngăn chặn việc tải lên ngẫu nhiên. Vậy làm thế nào để nhóm của bạn làm điều đó?

Tôi không biết bất kỳ nhà cung cấp nào có mặt để tự động hóa triển khai mặc dù tôi sẽ không ngạc nhiên nếu có một vài nhà cung cấp. Bạn có thể có thể kịch bản một giải pháp thông qua VBScript / WMI hoặc tập lệnh bó một giải pháp, nhưng thực tế là bạn cần điều chỉnh một giải pháp cùng nhau cho các trang web ASP.NET phức tạp hơn. Các trang web đơn giản bao gồm các trang, kết nối cơ sở dữ liệu và không có gì khác, bạn không cần phải làm gần như vậy để mở rộng các nỗ lực triển khai của mình phù hợp với sự phức tạp của chính ứng dụng.

Cho đến nay, tại triển khai công việc hiện tại của tôi vẫn được thực hiện qua FTP và di chuyển một loạt các tệp. Nó xấu xí, dễ làm hỏng và không có ý nghĩa về một lịch sử chính xác. Cấp cho bạn có thể kết hợp thông qua nhật ký FTP, không ai thực sự bận tâm để làm như vậy. Các ứng dụng của chúng tôi khá đơn giản mà không cần nhiều đến FTP. Làm thế nào nhóm của tôi triển khai các ứng dụng web của chúng tôi thực sự rất ít sử dụng cho bạn. Thay vào đó, tôi muốn sử dụng cơ hội này để đề xuất các thực tiễn tốt hơn .

• Giả sử không có gì. Tài khoản người dùng, đặc quyền R / W / X, ACL, tường lửa, thời gian (khi nào triển khai và thời gian bạn phải làm) và nếu có thể, hãy thử triển khai đến tất cả các môi trường trước "ngày ra mắt" cuối cùng.
• Trước khi phát triển thực sự bắt đầu, yếu tố triển khai vào phát triển. Nếu đó là một trang web đơn giản, vì vậy hãy là nó. Nếu có nhiều bộ phận chuyển động, hãy đặt tất cả vào đó và thực sự xây dựng một kế hoạch mà tất cả các thành phần (mã, cơ sở dữ liệu, báo cáo, hàng đợi, v.v.) đều nằm trên cùng một kế hoạch.
• Phối hợp với các cộng đồng khác và giao tiếp hiệu quả và hiệu quả.
• Tài liệu càng nhiều thông tin thích hợp nếu có thể.
• Môi trường: một máy chủ web so với trang trại web; 32 bit so với 64 bit; tìm cách theo dõi nhật ký / lỗi / xoay, v.v.
• Tìm (hoặc xây dựng) các công cụ có thể hỗ trợ triển khai.
• Nếu có thể để triển khai lập trình, chọn một mô hình và gắn bó với nó. Ví dụ: nếu bạn muốn sử dụng máy chủ cơ sở dữ liệu làm phương tiện chính để thực hiện trạng thái của ứng dụng, triển khai, truy cập và như vậy, hãy nướng nó vào ứng dụng và gắn bó với nó. Nếu bạn thích đọc các tệp XML (như web.config), chỉ cần sử dụng mô hình nhất quán để triển khai ứng dụng. Một ví dụ khác: một số tổ chức rời web.config dưới dạng tệp tĩnh trong mỗi môi trường không được triển khai sang các môi trường khác. Web.config chương trình khác theo cách mà nó có thể được triển khai trên các môi trường mà không gặp lỗi.

Tôi nhận ra rằng bài đăng này có thể là quá mức cho câu hỏi ban đầu được hỏi. Thật không may, việc triển khai không phải là một điều đơn giản vì các ứng dụng có thể khác nhau về độ phức tạp. Tôi cá rằng hầu hết các tổ chức triển khai các ứng dụng ASP.NET phức tạp theo thời gian đã phát triển một số chiến lược nhất định mà công việc (ít nhất là) đáng tin cậy.