Thực hành tốt nhất về triển khai / bảo trì ASP.NET

Tôi đã làm việc trong ngành phát triển web được khoảng 5 năm rồi, luôn làm việc trong môi trường nguồn mở. Chủ yếu là apache, mysql và php với một chút ruby, sử dụng git để kiểm soát phiên bản. Nhưng gần đây đã đảm nhận một công việc trong đó phát triển hoàn toàn là C # ASP.NET MVC.

Mặc dù tôi có thể tiếp nhận ngôn ngữ khá dễ dàng, nhưng các thành viên khác trong nhóm của tôi (có nhiều kinh nghiệm về Phát triển MS hơn tôi) đều có cách nghĩ khác khi xuất bản và triển khai trang web cuối cùng, và đặc biệt là những thay đổi trong tương lai.

Tâm lý với các nhà phát triển khác là một khi một trang web đã được xuất bản thì nó là cuối cùng. Không có nhiều thay đổi có thể được thực hiện cho trang web, khi tôi đã hỏi lý do đằng sau điều này, câu trả lời là nó quá nguy hiểm, tốn thời gian hoặc khó khăn.

Theo kinh nghiệm trước đây của tôi, cập nhật một trang web chỉ đơn giản là một trường hợp tải lên các tệp đã thay đổi, thường khá nhanh nếu đó là một thay đổi nhỏ hoặc đặt trang web ở chế độ bảo trì trong khi cập nhật xảy ra.

Gần đây chúng tôi đã xuất bản một trang web MVC và doanh nghiệp đã liên hệ với chúng tôi để cập nhật một số văn bản và thêm một liên kết đến một tài liệu pdf mới. Phần còn lại trong nhóm của tôi đã nhanh chóng nói rằng điều này không nên được thực hiện bởi vì trang web hiện đang hoạt động và không nên sửa đổi. Có điều gì tôi đã bỏ lỡ khi không được 'đưa lên' một nhà phát triển của Microsoft không?

Lập luận chống lại việc sửa đổi ứng dụng web trực tiếp trong sản xuất là gì và suy nghĩ này có phải là duy nhất cho các nhà phát triển .NET không?

Tôi thực sự muốn hiểu suy nghĩ này và liệu nó có hợp lý trong môi trường phát triển của Microsoft hay không, hay đây chỉ là một cách nghĩ cũ.

LƯU Ý: Chúng tôi sử dụng TFS để kiểm soát phiên bản và sử dụng hồ sơ xuất bản để xác định nơi trang web được triển khai (UAT hoặc Sản xuất)

Các ứng dụng ASP.NET MVC được biên dịch. Điều này có nghĩa là bạn không thể tải lên các tệp đã thay đổi, ví dụ như bạn làm với một trang web PHP. Điều này cũng có nghĩa là khi bạn bắt đầu cập nhật trang web, người dùng hiện tại sẽ bị loại bỏ (ví dụ như mất phiên của họ).

Ngoài ra còn có nhiều việc phải làm hơn là chỉ cập nhật các tệp: bạn phải xử lý:

• Quyền

  Phiên bản mới có thể yêu cầu một bộ quyền khác trên máy chủ.

• Cấu hình

  Phiên bản mới có thể yêu cầu dịch vụ Điều phối giao dịch phân tán (MSDTC) được cài đặt hoặc có thể muốn sử dụng máy chủ SMTP khác hoặc có quyền truy cập vào Active Directory, v.v. Điều này liên quan đến việc thay đổi cả cấu hình của ứng dụng và của chính máy chủ .

• Phụ thuộc

  Ví dụ, một trong những vấn đề thường gặp của người mới bắt đầu là họ giữ các DLL cũ trong /binkhi thêm các tên mới với các tên khác nhau: ứng dụng vẫn có thể sử dụng các cái cũ, điều này tạo ra một tình huống điên rồ khi bạn thay đổi mã của ứng dụng, nhưng hành vi ứng dụng vẫn giữ nguyên.

• Dữ liệu

  Điều gì xảy ra nếu lược đồ cơ sở dữ liệu thay đổi và ứng dụng sử dụng máy chủ SQL thông thường thay vì NoQuery? Làm thế nào để thực hiện thay đổi trong lược đồ? Làm thế nào để giữ dữ liệu chính xác trong quá trình thay đổi?

Xử lý quá trình chuyển đổi giữa phiên bản cũ và phiên bản mới của ứng dụng là một nhiệm vụ khó khăn. Một vài năm trước, đây là một trong những vấn đề, trong đó một phiên bản ứng dụng mới đã sẵn sàng, nhưng phải mất nhiều ngày hoặc vài tuần để các quản trị viên hệ thống triển khai. DevOps giải quyết vấn đề này, nhưng yêu cầu các nhà phát triển mô tả (thông qua mã hoặc cấu hình) hệ thống sẽ lưu trữ ứng dụng.

Ứng dụng càng lớn thì nhiệm vụ này càng phức tạp.

• Đối với một ứng dụng web nhỏ, sao chép tệp nguồn vào máy chủ là đủ,

• Đối với một cái gì đó lớn hơn, bạn phải có một quy trình tự động liên quan đến quá trình cập nhật và khôi phục trong trường hợp có sự cố,

• Đối với các hệ thống thậm chí còn lớn hơn, ở mỗi phiên bản mới, các máy ảo mới được tạo và triển khai và các máy ảo cũ được tái chế, đảm bảo chuyển đổi liền mạch của người dùng từ phiên bản cũ sang phiên bản mới.

Các ứng dụng được biên dịch đơn giản là bắt buộc / khuyến khích tự động hóa quá trình trước đó.

doanh nghiệp đã liên hệ với chúng tôi để cập nhật một số văn bản và thêm liên kết đến tài liệu pdf mới. Phần còn lại trong nhóm của tôi đã nhanh chóng nói rằng điều này không nên được thực hiện bởi vì trang web hiện đang hoạt động

IMO, không có lý do kỹ thuật thực sự cho sự từ chối này; họ chỉ muốn tránh làm điều đó, bởi vì, nếu không được tự động hóa tốt, nhiệm vụ dễ bị lỗi .

Điều thường xảy ra là:

1. Ứng dụng này được triển khai lần đầu tiên.

2. Nhóm dành vài giờ để điều chỉnh cấu hình để làm cho nó hoạt động. Vì nhóm dự kiến ​​sẽ giao hàng ba tuần trước, mọi người đều hối hả và không ai ghi chú các thay đổi.

3. Ứng dụng này hiện đang hoạt động.

4. Trong một vài tuần, vài tháng hoặc vài năm, một số người ngẫu nhiên thay đổi một số nội dung ngẫu nhiên trên máy chủ: ví dụ: họ đã chuyển cơ sở dữ liệu đến một vị trí khác hoặc mật khẩu SMTP đã thay đổi, gây ra những thay đổi trong Web.config.

Nếu bạn cập nhật phiên bản mới ngay bây giờ, bạn sẽ quay lại bước đầu tiên và có thể mất vài ngày để khôi phục cấu hình chính xác. Vì trang web đang hoạt động, nên tránh điều này bằng mọi giá.

Bạn có người quản lý dự án, Người quản lý phát triển hoặc người nào khác ngoài các nhà phát triển khác không?

Nó làm cho ZERO có ý nghĩa rằng bạn không thể thực hiện triển khai sau khi đi vào hoạt động.

Tất nhiên, những thay đổi này cần được lên lịch, chi phí và cung cấp lại trong số những thứ khác, nhưng chỉ nói "không" là vô nghĩa.

Lý do chính cho hành vi bạn đang thấy là những loại thay đổi này dễ bị lỗi. Cập nhật thủ công ứng dụng dẫn đến những thứ bị lãng quên và không đồng bộ. Bạn vẫn có thể thực hiện các bản phát hành mới (và nó sẽ dễ dàng) , không phải là bản vá một phần.

Các cập nhật một phần như thay đổi một số CSS hoặc văn bản trên một trang web trực tiếp có thể dẫn đến việc bỏ qua các môi trường kiểm tra, kiểm tra hoặc giai đoạn không đồng bộ hoặc thậm chí, không cam kết mã với kiểm soát nguồn. Nếu đây là thay đổi mã, bạn thậm chí có thể phá vỡ trang web trực tiếp mà không có kế hoạch khôi phục.

Trong .NET vì mã được biên dịch, có thể có các vấn đề khác như thời gian tải lâu và mất phiên người dùng. Những vấn đề này có thể được giảm nhẹ việc tôi chuyển sang môi trường ấm áp và sử dụng trạng thái phiên quá trình. Tuy nhiên, trừ khi bạn muốn nghĩ về các loại vấn đề này và các vấn đề khác cụ thể cho ứng dụng của bạn mỗi khi bạn muốn triển khai. Sau đó vá các trang web trực tiếp là một ý tưởng tồi.

Khi ứng dụng của bạn tăng kích thước và mọi người đến và đi, điều này có thể chuyển từ một sự bất tiện sang một vấn đề nghiêm trọng. Vì vậy, để làm cho mọi thứ an toàn hơn, chúng tôi tuân theo các quy tắc như: Để cập nhật một trang web trực tiếp, nó phải là một triển khai hoàn chỉnh, không bao giờ chỉ là bản vá.

Nếu bạn chưa tự động hóa việc triển khai của mình (điều này giúp việc tuân thủ quy tắc trở nên dễ dàng và nhanh chóng). Việc triển khai mới thường được thực hiện bên cạnh phiên bản hiện có và sau đó trang web của bạn chỉ là một con trỏ đến phiên bản bạn muốn (Lưu ý lược đồ cơ sở dữ liệu làm cho việc này phức tạp hơn một chút).

1.0.0  // Old version you can roll back to   
2.0.0 <-- IIS points here

Trong thực tế, tôi nghĩ rằng tất cả các triển khai nên thực sự được tự động hóa và bao gồm cả các triển khai không .NET, vì những lý do tương tự. Khi bạn bắt đầu tự động hóa các triển khai, bạn có thể đảm bảo chúng luôn nhanh và đáng tin cậy.

Tôi thường xuyên tái xuất bản / triển khai lại khá nhiều trang web ASP.NET MVC được triển khai cho Amazon AWS, Windows Azure và máy chủ web riêng tư và không thấy bất kỳ lý do nào khiến nhóm của bạn tạo ra số lượng lớn như vậy.

Tuy nhiên, bạn nên thiết kế trang web của mình theo cách sao cho các tác vụ như cập nhật văn bản và liên kết phải được thực hiện thông qua cơ sở dữ liệu thông qua giao diện quản trị trang web.

Quan điểm của tôi là trong khi các thay đổi đối với một trang web trực tiếp vẫn ổn (được gọi là phát triển), thì việc triển khai lại ứng dụng để thay đổi chuỗi văn bản có khả năng là một thiết kế tồi. Tôi không đề xuất việc tái xuất bản có thể được thực hiện mà không cần quan tâm.