Làm thế nào để bạn triển khai các ứng dụng ASP.NET của mình đến các máy chủ trực tiếp?

Tôi đang tìm kiếm các kỹ thuật / công cụ khác nhau mà bạn sử dụng để triển khai một dự án ứng dụng web ASP.NET ( KHÔNG phải trang web ASP.NET) để sản xuất?

Tôi đặc biệt quan tâm đến quy trình làm việc xảy ra trong khoảng thời gian máy chủ Bản dựng tích hợp liên tục của bạn thả các tệp nhị phân tại một số vị trí và thời điểm yêu cầu người dùng đầu tiên truy cập các tệp nhị phân này.

1. Bạn đang sử dụng một số công cụ cụ thể hay chỉ XCOPY? Ứng dụng được đóng gói như thế nào (ZIP, MSI, ...)?

2. Khi một ứng dụng được triển khai lần đầu tiên, bạn làm cách nào để thiết lập Nhóm ứng dụng và Thư mục ảo (bạn tạo chúng theo cách thủ công hoặc bằng một số công cụ)?

3. Khi một tài nguyên tĩnh thay đổi (CSS, JS hoặc tệp hình ảnh), bạn có triển khai lại toàn bộ ứng dụng hay chỉ tài nguyên đã sửa đổi? Còn khi một trang assembly / ASPX thay đổi thì sao?

4. Bạn có theo dõi tất cả các phiên bản đã triển khai cho một ứng dụng nhất định và trong trường hợp xảy ra sự cố, bạn có các thủ tục khôi phục ứng dụng về trạng thái làm việc đã biết trước đó không?

Hãy hoàn thành danh sách trước.

Và đây là những gì chúng tôi sử dụng để triển khai các ứng dụng ASP.NET của mình:

1. Chúng tôi thêm Dự án triển khai web vào giải pháp và thiết lập nó để xây dựng ứng dụng web ASP.NET
2. Chúng tôi thêm một Dự án Thiết lập ( KHÔNG phải Dự án Thiết lập Web) vào giải pháp và đặt nó để lấy đầu ra của Dự án Triển khai Web
3. Chúng tôi thêm hành động cài đặt tùy chỉnh và trong sự kiện OnInstall, chúng tôi chạy lắp ráp .NET bản dựng tùy chỉnh tạo Nhóm ứng dụng và Thư mục ảo trong IIS bằng System.DirectoryServices.DirectoryEntry (Tác vụ này chỉ được thực hiện lần đầu tiên một ứng dụng được triển khai) . Chúng tôi hỗ trợ nhiều Trang web trong IIS, Xác thực Thư mục Ảo và thiết lập danh tính cho Hồ bơi ứng dụng.
4. Chúng tôi thêm một nhiệm vụ tùy chỉnh trong TFS để xây dựng Dự án Thiết lập (TFS không hỗ trợ Dự án Thiết lập, vì vậy chúng tôi phải sử dụng devenv.exe để xây dựng MSI)
5. MSI được cài đặt trên máy chủ trực tiếp (nếu có phiên bản trước của MSI thì lần đầu tiên nó được gỡ cài đặt)

Chúng tôi đã triển khai tất cả mã của mình trong MSI bằng cách sử dụng Setup Factory. Nếu điều gì đó phải thay đổi, chúng tôi triển khai lại toàn bộ giải pháp. Điều này nghe có vẻ như quá mức cần thiết đối với tệp css, nhưng nó hoàn toàn giữ cho tất cả các môi trường được đồng bộ hóa và chúng tôi biết chính xác những gì đang được sản xuất (chúng tôi triển khai cho tất cả các môi trường thử nghiệm và uat theo cùng một cách).

Chúng tôi triển khai luân phiên đến các máy chủ trực tiếp, vì vậy chúng tôi không sử dụng các dự án trình cài đặt; chúng tôi có một cái gì đó giống như CI:

• bản dựng máy chủ "trực tiếp" từ nguồn đã được phê duyệt (không phải "HEAD" của repo)
• (sau khi nó đã được sao lưu ;-p)
• robocopy xuất bản lên máy chủ dàn ("trực tiếp", nhưng không xuất bản trong cụm F5)
• xác thực cuối cùng được thực hiện trên máy chủ dàn, thường có hack "máy chủ" để mô phỏng toàn bộ mọi thứ chặt chẽ nhất có thể
• robocopy / L được sử dụng tự động để phân phối danh sách các thay đổi trong "lần đẩy" tiếp theo, để cảnh báo về bất kỳ kẻ nào
• là một phần của quy trình đã lên lịch, cụm được theo chu kỳ, triển khai đến các nút trong cụm thông qua nội soi tự động (khi chúng ra khỏi cụm)

robocopy tự động đảm bảo rằng chỉ những thay đổi được triển khai.

Re the App Pool, v.v.; Tôi sẽ yêu này để được tự động ( xem câu hỏi này ), nhưng tại thời điểm đó là thủ công. Tôi thực sự muốn thay đổi điều đó.

(nó có thể giúp chúng tôi có trung tâm dữ liệu và máy chủ "tại chỗ" của riêng mình, vì vậy chúng tôi không phải vượt qua nhiều rào cản)

Trang mạng

Người triển khai: http://www.codeproject.com/KB/install/deployer.aspx

Tôi xuất bản trang web vào một thư mục cục bộ, nén nó, sau đó tải nó lên qua FTP. Người triển khai trên máy chủ sau đó trích xuất zip, thay thế các giá trị cấu hình (trong Web.Config và các tệp khác), và thế là xong.

Tất nhiên trong lần chạy đầu tiên, bạn cần kết nối với máy chủ và thiết lập IIS WebSite, cơ sở dữ liệu, nhưng sau đó việc xuất bản các bản cập nhật là một phần nhỏ.

Cơ sở dữ liệu

Để giữ cho cơ sở dữ liệu được đồng bộ hóa, tôi sử dụng http://www.red-gate.com/products/sql-development/sql-compare/

Nếu máy chủ nằm sau nhiều bộ định tuyến và bạn không thể kết nối trực tiếp (đó là yêu cầu của SQL Compare), hãy sử dụng https://secure.logmein.com/products/hamachi2/ để tạo VPN.

Tôi triển khai hầu hết các ứng dụng ASP.NET cho máy chủ Linux và triển khai lại mọi thứ cho dù là thay đổi nhỏ nhất. Đây là quy trình làm việc chuẩn của tôi:

• Tôi sử dụng một kho lưu trữ mã nguồn (như Subversion)
• Trên máy chủ, tôi có một tập lệnh bash thực hiện những việc sau:
  • Kiểm tra mã mới nhất
  • Có xây dựng (tạo DLL)
  • Lọc các tệp xuống các yếu tố cần thiết (loại bỏ các tệp mã chẳng hạn)
  • Sao lưu cơ sở dữ liệu
  • Triển khai các tệp vào máy chủ web trong thư mục có tên ngày hiện tại
  • Cập nhật cơ sở dữ liệu nếu một lược đồ mới được đưa vào triển khai
  • Đặt cài đặt mới làm cài đặt mặc định để nó sẽ được phân phối với lần truy cập tiếp theo

Kiểm tra được thực hiện với phiên bản dòng lệnh của Subversion và việc xây dựng được thực hiện với xbuild (xây dựng công việc tương tự từ dự án Mono). Hầu hết phép thuật được thực hiện trong ReleaseIt.

Trên máy chủ nhà phát triển của tôi, về cơ bản, tôi có tích hợp liên tục nhưng ở phía sản xuất, tôi thực sự SSH vào máy chủ và bắt đầu triển khai theo cách thủ công bằng cách chạy tập lệnh. Tập lệnh của tôi được gọi là 'triển khai' một cách khéo léo nên đó là những gì tôi nhập vào dấu nhắc bash. Tôi rất sáng tạo. Không phải.

Trong quá trình sản xuất, tôi phải gõ 'deploy' hai lần: một lần để đăng xuất, xây dựng và triển khai cho một thư mục ngày tháng và một lần để đặt thư mục đó làm phiên bản mặc định. Vì các thư mục đã được ghi ngày tháng, tôi có thể hoàn nguyên về bất kỳ triển khai nào trước đó chỉ bằng cách gõ 'deploy' từ trong thư mục có liên quan.

Việc triển khai ban đầu mất một vài phút và việc chuyển sang phiên bản trước mất vài giây.

Đó là một giải pháp tốt đối với tôi và chỉ dựa vào ba tiện ích dòng lệnh (svn, xbuild và releaseit), máy khách DB, SSH và Bash.

Đôi khi tôi thực sự cần cập nhật bản sao ReleaseIt trên CodePlex:

http://releaseit.codeplex.com/

XCopy đơn giản cho ASP.NET. Zip nó lên, chuyển đến máy chủ, giải nén vào đúng vị trí. Đối với lần triển khai đầu tiên, thiết lập thủ công IIS

Trả lời câu hỏi của bạn:

1. XCopy
2. Thủ công
3. Đối với tài nguyên tĩnh, chúng tôi chỉ triển khai tài nguyên đã thay đổi.
   Đối với DLL, chúng tôi triển khai các trang DLL và ASPX đã thay đổi.
4. Có, và có.

Giữ cho nó đẹp và đơn giản đã giúp chúng tôi tiết kiệm rất nhiều đau đầu cho đến nay.

Bạn đang sử dụng một số công cụ cụ thể hay chỉ XCOPY? Ứng dụng được đóng gói như thế nào (ZIP, MSI, ...)?

Là một nhà phát triển cho BuildMaster , đây là những gì tôi sử dụng tự nhiên. Tất cả các ứng dụng được xây dựng và đóng gói trong công cụ dưới dạng tạo tác, được lưu trữ nội bộ dưới dạng tệp ZIP.

Khi một ứng dụng được triển khai lần đầu tiên, bạn làm cách nào để thiết lập Nhóm ứng dụng và Thư mục ảo (bạn tạo chúng theo cách thủ công hoặc bằng một số công cụ)?

Theo cách thủ công - chúng tôi tạo kiểm soát thay đổi trong công cụ nhắc nhở chúng tôi các bước chính xác để thực hiện trong các môi trường tương lai khi ứng dụng di chuyển qua các môi trường thử nghiệm của nó. Điều này cũng có thể được tự động hóa bằng một tập lệnh PowerShell đơn giản, nhưng chúng tôi không thêm các ứng dụng mới thường xuyên, do đó, bạn chỉ cần dành 1 phút để tạo trang web theo cách thủ công.

Khi một tài nguyên tĩnh thay đổi (CSS, JS hoặc tệp hình ảnh), bạn có triển khai lại toàn bộ ứng dụng hay chỉ tài nguyên đã sửa đổi? Còn khi một trang assembly / ASPX thay đổi thì sao?

Theo mặc định, quá trình triển khai tạo tác được thiết lập sao cho chỉ các tệp được sửa đổi mới được chuyển đến máy chủ đích - điều này bao gồm mọi thứ từ tệp CSS, tệp JavaScript, trang ASPX và hội đồng được liên kết.

Bạn có theo dõi tất cả các phiên bản đã triển khai cho một ứng dụng nhất định và trong trường hợp xảy ra sự cố, bạn có các thủ tục khôi phục ứng dụng về trạng thái làm việc đã biết trước đó không?

Có, BuildMaster xử lý tất cả những điều này cho chúng tôi. Việc khôi phục chủ yếu đơn giản như thực hiện lại một chương trình khuyến mãi bản dựng cũ, nhưng đôi khi các thay đổi cơ sở dữ liệu cần được khôi phục theo cách thủ công và có thể xảy ra mất dữ liệu. Quy trình khôi phục cơ bản được trình bày chi tiết tại đây: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

thiết lập / cài đặt dự án web - vì vậy bạn có thể dễ dàng gỡ cài đặt nếu có sự cố

Unfold là một giải pháp triển khai giống capistrano mà tôi đã viết cho các ứng dụng .net. Đó là những gì chúng tôi sử dụng trong tất cả các dự án của mình và đó là một giải pháp rất linh hoạt. Nó giải quyết hầu hết các vấn đề điển hình cho các ứng dụng .net như được giải thích trong bài đăng blog này của Rob C office.

• nó đi kèm với một hành vi "mặc định" tốt, theo nghĩa là nó thực hiện rất nhiều thứ tiêu chuẩn cho bạn: lấy mã từ kiểm soát nguồn, xây dựng, tạo nhóm ứng dụng, thiết lập IIS, v.v.
• phát hành dựa trên những gì trong kiểm soát nguồn
• nó có các móc nhiệm vụ , vì vậy hành vi mặc định có thể dễ dàng được mở rộng hoặc thay đổi
• nó có hồi phục
• đó là tất cả PowerShell , vì vậy không có bất kỳ phụ thuộc bên ngoài
• nó sử dụng tính năng xóa powershell để truy cập các máy từ xa

Đây là phần giới thiệu và một số bài đăng trên blog khác.

Vì vậy, để trả lời các câu hỏi trên:

• Ứng dụng được đóng gói như thế nào (ZIP, MSI, ...)?

  Git (hoặc một scm khác) là cách mặc định để tải ứng dụng trên máy đích. Ngoài ra, bạn có thể thực hiện xây dựng cục bộ và sao chép kết quả qua kết nối loại bỏ Powereshell

• Khi một ứng dụng được triển khai lần đầu tiên, bạn làm cách nào để thiết lập Nhóm ứng dụng và Thư mục ảo (bạn tạo chúng theo cách thủ công hoặc bằng một số công cụ)?

  Unfold định cấu hình nhóm ứng dụng và ứng dụng trang web bằng cách sử dụng Mô-đun quản trị web của Powershell. Nó cho phép chúng tôi (và bạn) sửa đổi bất kỳ khía cạnh nào của nhóm ứng dụng hoặc trang web

• Khi một tài nguyên tĩnh thay đổi (CSS, JS hoặc tệp hình ảnh), bạn có triển khai lại toàn bộ ứng dụng hay chỉ tài nguyên đã sửa đổi? Còn khi một trang assembly / ASPX thay đổi thì sao?

  Có mở ra làm điều này, bất kỳ triển khai nào được cài đặt bên cạnh các triển khai khác. Bằng cách đó, chúng tôi có thể dễ dàng khôi phục khi một số lỗi xảy ra. Nó cũng cho phép chúng tôi dễ dàng truy tìm lại một phiên bản đã triển khai đến một bản sửa đổi kiểm soát nguồn.

• Bạn có theo dõi tất cả các phiên bản đã triển khai cho một ứng dụng nhất định không?

  Có, mở ra giữ các phiên bản cũ xung quanh. Không phải tất cả các phiên bản, nhưng một số phiên bản. Nó làm cho việc lăn trở lại gần như tầm thường.

Chúng tôi đã cải thiện quy trình phát hành của mình trong năm qua và bây giờ chúng tôi đã nhận được điều đó. Tôi đang sử dụng Jenkins để quản lý tất cả các phiên bản và bản phát hành tự động của chúng tôi, nhưng tôi chắc chắn rằng bạn có thể sử dụng TeamCity hoặc CruiseControl.

Vì vậy, khi đăng ký, bản dựng "bình thường" của chúng tôi thực hiện như sau:

• Jenkins thực hiện cập nhật SVN để tìm nạp phiên bản mới nhất của mã
• Khôi phục gói NuGet đã được thực hiện xong khi chạy trên kho lưu trữ NuGet cục bộ của chúng tôi
• Ứng dụng được biên dịch bằng MsBuild. Thiết lập điều này là một cuộc phiêu lưu, vì bạn cần cài đặt đúng MsBuild và sau đó là ASP.NET và dll MVC trên hộp xây dựng của bạn. (Một lưu ý nhỏ, khi tôi <MvcBuildViews>true</MvcBuildViews>nhập tệp .csproj của mình để biên dịch các chế độ xem, msbuild ngẫu nhiên bị lỗi, vì vậy tôi phải tắt nó)
• Sau khi mã được biên dịch, các bài kiểm tra đơn vị sẽ được chạy (tôi đang sử dụng nunit cho việc này, nhưng bạn có thể sử dụng bất kỳ thứ gì bạn muốn)
• Nếu tất cả các bài kiểm tra đơn vị đều vượt qua, tôi dừng nhóm ứng dụng IIS, triển khai ứng dụng cục bộ (chỉ một vài lệnh XCOPY cơ bản để sao chép qua các tệp cần thiết) và sau đó khởi động lại IIS (tôi đã gặp sự cố với tệp khóa IIS và điều này đã được giải quyết nó)
• Tôi có các tệp web.config riêng biệt cho từng môi trường; dev, uat, prod. (Tôi đã thử sử dụng công cụ chuyển đổi web nhưng không thành công). Vì vậy, tệp web.config bên phải cũng được sao chép qua
• Sau đó, tôi sử dụng PhantomJS để thực hiện một loạt các bài kiểm tra giao diện người dùng. Nó cũng chụp một loạt ảnh chụp màn hình ở các độ phân giải khác nhau (thiết bị di động, máy tính để bàn) và đóng dấu mỗi ảnh chụp màn hình bằng một số thông tin (tiêu đề trang, độ phân giải). Jenkins hỗ trợ đắc lực để xử lý những ảnh chụp màn hình này và chúng được lưu như một phần của bản dựng
• Sau khi kiểm tra giao diện người dùng tích hợp vượt qua, bản dựng thành công

Nếu ai đó nhấp vào "Triển khai tới UAT":

• Nếu lần xây dựng cuối cùng thành công, Jenkins thực hiện một bản cập nhật SVN khác
• Ứng dụng được biên dịch bằng cấu hình RELEASE
• Thư mục "www" được tạo và ứng dụng được sao chép vào đó
• Sau đó, tôi sử dụng wincp để đồng bộ hóa hệ thống tệp giữa hộp xây dựng và UAT
• Tôi gửi một yêu cầu HTTP đến máy chủ UAT và đảm bảo rằng tôi nhận lại được 200
• Bản sửa đổi này được gắn thẻ trong SVN là UAT-datetime
• Nếu chúng ta đã đạt được điều này, quá trình xây dựng đã thành công!

Khi chúng tôi nhấp vào "Triển khai cho Sản phẩm":

• Người dùng chọn một Thẻ UAT đã được tạo trước đó
• Thẻ được "chuyển" thành
• Mã được biên dịch và đồng bộ hóa với máy chủ Prod
• Yêu cầu htp tới máy chủ Sản phẩm
• Bản sửa đổi này được gắn thẻ trong SVN là Prod-datetime
• Bản phát hành được nén và lưu trữ

Toàn bộ quá trình xây dựng hoàn chỉnh đến quá trình sản xuất mất khoảng 30 giây mà tôi rất, rất hài lòng.

Ưu điểm của giải pháp này:

• Nó nhanh
• Các bài kiểm tra đơn vị nên bắt lỗi logic
• Khi một lỗi giao diện người dùng đi vào sản xuất, hy vọng ảnh chụp màn hình sẽ hiển thị bản sửa đổi # nào đã gây ra lỗi đó
• UAT và Sản phẩm được giữ đồng bộ
• Jenkins cho bạn thấy một lịch sử phát hành tuyệt vời cho UAT và Prod với tất cả các thông báo cam kết
• Các bản phát hành UAT và Prod đều được gắn thẻ tự động
• Bạn có thể biết thời điểm phát hành và ai đã thực hiện chúng

Nhược điểm chính của giải pháp này là:

• Bất cứ khi nào bạn phát hành cho Sản phẩm, bạn cần phải phát hành cho UAT. Đây là một quyết định có ý thức, chúng tôi đã thực hiện vì chúng tôi muốn luôn đảm bảo rằng UAT luôn cập nhật với Prod. Tuy nhiên, đó là một nỗi đau.
• Có khá nhiều tệp cấu hình trôi nổi. Tôi đã cố gắng có tất cả trong Jenkins, nhưng cần có một vài tệp hàng loạt hỗ trợ như một phần của quy trình. (Những thứ này cũng đã được đăng ký).
• Các tập lệnh nâng cấp và hạ cấp DB là một phần của ứng dụng và chạy khi khởi động ứng dụng. Nó hoạt động (hầu hết), nhưng đó là một nỗi đau.

Tôi muốn nghe bất kỳ cải tiến nào khác có thể có!

Quay trở lại năm 2009, nơi bắt nguồn câu trả lời này, chúng tôi đã sử dụng CruiseControl.net cho các bản dựng Tích hợp liên tục của chúng tôi, cũng tạo ra Release Media.

Từ đó, chúng tôi đã sử dụng phần mềm Smart Sync để so sánh với máy chủ sản xuất đã nằm ngoài vùng cân bằng tải và chuyển các thay đổi lên.

Cuối cùng, sau khi xác thực bản phát hành, chúng tôi chạy một tập lệnh DOS chủ yếu sử dụng RoboCopy để đồng bộ mã với các máy chủ trực tiếp, dừng / khởi động IIS khi nó hoạt động.

Tại công ty cuối cùng tôi làm việc, chúng tôi đã từng triển khai bằng cách sử dụng tệp loạt rSync để chỉ tải lên các thay đổi kể từ lần tải lên cuối cùng. Cái hay của rSync là bạn có thể thêm danh sách loại trừ để loại trừ các tệp hoặc mẫu tên tệp cụ thể. Vì vậy, việc loại trừ tất cả các tệp .cs, các tệp giải pháp và dự án của chúng tôi thực sự dễ dàng.

Chúng tôi đang sử dụng TortoiseSVN để kiểm soát phiên bản và vì vậy thật tuyệt khi có thể viết trong một số lệnh SVN để thực hiện những điều sau:

• Trước hết, hãy kiểm tra xem người dùng có bản sửa đổi mới nhất hay không. Nếu không, hãy nhắc họ cập nhật hoặc chạy bản cập nhật ngay tại đó và sau đó.
• Tải xuống một tệp văn bản từ máy chủ có tên "synclog.txt" ghi chi tiết người dùng SVN là ai, họ đang tải lên số bản sửa đổi nào và ngày giờ tải lên. Nối một dòng mới cho tải lên hiện tại và sau đó gửi nó trở lại máy chủ cùng với các tệp đã thay đổi. Điều này giúp bạn cực kỳ dễ dàng tìm ra phiên bản nào của trang web để khôi phục nếu quá trình tải lên gây ra sự cố.

Ngoài ra, còn có một tệp hàng loạt thứ hai chỉ kiểm tra sự khác biệt của tệp trên máy chủ trực tiếp. Điều này có thể làm nổi bật vấn đề phổ biến khi ai đó tải lên nhưng không cam kết các thay đổi của họ với SVN. Kết hợp với nhật ký đồng bộ được đề cập ở trên, chúng tôi có thể tìm ra thủ phạm có khả năng là ai và yêu cầu họ thực hiện công việc của mình.

Và cuối cùng, rSync cho phép bạn sao lưu các tệp đã được thay thế trong quá trình tải lên. Chúng tôi đã cho nó di chuyển chúng vào một thư mục sao lưu Vì vậy, nếu bạn đột nhiên nhận ra rằng một số tệp lẽ ra không nên bị ghi đè, bạn có thể tìm thấy phiên bản sao lưu cuối cùng của mọi tệp trong thư mục đó.

Mặc dù giải pháp này hơi rắc rối vào thời điểm đó, tôi đã đánh giá cao nó hơn rất nhiều khi làm việc trong môi trường nơi phương pháp tải lên kém thanh lịch hoặc dễ dàng hơn rất nhiều (ví dụ: máy tính từ xa, sao chép và dán toàn bộ trang web) .

Tôi khuyên bạn KHÔNG chỉ ghi đè các tệp ứng dụng hiện có mà thay vào đó hãy tạo một thư mục cho mỗi phiên bản và chỉ định lại ứng dụng IIS vào đường dẫn mới. Điều này có một số lợi ích:

• Nhanh chóng hoàn nguyên nếu cần
• Không cần dừng IIS hoặc nhóm ứng dụng để tránh sự cố khóa
• Không có nguy cơ các tệp cũ gây ra sự cố
• Nhiều hơn hoặc ít hơn không có thời gian chết (thường chỉ là tạm dừng khi khởi tạo tên miền ứng dụng mới)

Vấn đề duy nhất mà chúng tôi gặp phải là tài nguyên đang được lưu vào bộ nhớ cache nếu bạn không khởi động lại nhóm ứng dụng và dựa vào công tắc tên miền ứng dụng tự động.