2011-02-02 32 views
8

Tôi muốn biết cách người khác duy trì tệp web.config của họ cho các ứng dụng được triển khai. (giả sử không có cơ chế triển khai tự động nào - nằm ngoài phạm vi của câu hỏi này)duy trì các tệp web.config

Vì vậy, trong quá trình phát triển, một số nhà phát triển có thể sử dụng chuyển đổi web.config, xây dựng/xuất bản dự án của họ (debug/release, test/live configuration), sau đó triển khai tất cả các tạo phẩm đã xuất bản lên máy chủ web và thiết lập IIS. Một số nhà phát triển có thể xây dựng/xuất bản các dự án của họ, triển khai các tạo phẩm đã xuất bản lên máy chủ web, thiết lập IIS, sau đó cập nhật web.configs theo cách thủ công cho môi trường cụ thể (test/live, v.v.) mà chúng đang triển khai.

Sau khi triển khai nội tại và ứng dụng đang được sản xuất (trong môi trường sống hoặc môi trường thử nghiệm), làm thế nào để bạn duy trì tệp web.config theo thời gian nếu nói chuỗi kết nối cơ sở dữ liệu hoặc khóa cài đặt ứng dụng thay đổi?

Bạn có sử dụng biến đổi web.config, thực hiện thay đổi trong VS xuất bản lại ứng dụng, sau đó sao chép toàn bộ ứng dụng hoặc có thể chỉ web.config mới vào máy chủ?

Bạn có thực hiện thay đổi web.config theo cách thủ công trên máy chủ không?

Bạn có phiên bản kiểm soát thay đổi web.config trong điều khiển nguồn nếu những thứ như chuỗi kết nối, khóa ứng dụng, vv (không phải cấu trúc) thay đổi không?

Tôi muốn biết cách người khác tiếp cận vấn đề này.

Hiện tại chúng tôi thực hiện các thay đổi đối với web.config trong quá trình sản xuất. Khi chúng tôi triển khai các tính năng mới hoặc sửa lỗi, phiên bản chúng tôi kiểm soát những thay đổi đó và mọi thay đổi đối với web.config chẳng hạn như khóa ứng dụng mới, v.v. Nếu chúng tôi phải triển khai phiên bản mới của ứng dụng, chúng tôi sẽ sao lưu phiên bản hiện tại vào sản xuất máy chủ, xóa tất cả các tệp cấu hình ngoại lệ, sau đó sao chép phiên bản mới mà không cần tệp cấu hình vào máy chủ sản xuất, giữ lại cấu hình hiện có. Sau đó, so sánh thủ công cấu hình hiện tại với cấu hình chúng tôi có trong điều khiển nguồn để tính toán các thay đổi trong lược đồ.

Chúng tôi đang tạm ẩn để sửa đổi điều này bởi vì chúng tôi muốn một quy trình có thể tái tạo và không dễ bị lỗi của con người. Tôi không tin rằng giải pháp là 100% biến đổi web.config. Ngay cả khi bạn sử dụng các biến đổi, dường như có một số can thiệp của con người cần thiết trong việc triển khai vì có khả năng một giá trị trong tệp cấu hình sản xuất có thể đã thay đổi và không được cập nhật trong điều khiển nguồn. Những người khác giải quyết vấn đề này như thế nào?

Trả lời

1

Kiểm soát nguồn cho chúng tôi là cửa hàng chính. Mọi thứ cần được thay đổi HAS để tham gia. Các nhà phát triển cố gắng để vượt qua điều này bằng cách sửa đổi cài đặt cấu hình trên các trang PROD hoặc STAGE bị busted. Nếu xảy ra sự cố, họ chịu trách nhiệm khắc phục mọi sự cố. Thông thường sau lần đầu tiên tất cả-nighter, họ không làm điều đó nữa. Các tệp cấu hình điều khiển nguồn sau đó được xây dựng thành tệp web.config và settings.config sử dụng xml/xslt

Về dự án hiện tại của tôi, tôi đang sử dụng web.config giống nhau trên mọi môi trường và sử dụng configSource để kéo trong cài đặt cụ thể máy chủ

<appSettings configSource="App_Data\appsettings.config"/> 

Mỗi môi trường có nó thiết lập riêng nộp

  • appsettings.user1.dev.config
  • appsettings.user2.dev.cấu hình
  • appsettings.stage.config
  • appsettings.prod.config

Các kịch bản phát hành gói chúng ta có, lấy các tập tin thiết lập nó cần, và đổi tên để appsettings.config, sau đó toàn bộ thông cáo được tải lên . Bản phát hành sau đó có thể được gắn thẻ trong điều khiển nguồn.

+0

trong khi sử dụng configSource, thay đổi trong bất kỳ thuộc tính nào trong appsettings.config không tự động được chọn bởi IIS cho đến khi bạn cập nhật dấu thời gian của web.config – Adeel

+0

yeh, web.config bị tấn công khi chúng tôi tải lên lại toàn bộ trang web – djeeg

+0

vai trò quản trị viên và nhà phát triển của bạn được xử lý bởi một người hoặc một nhóm (phát triển trong trường hợp của bạn). Đối với chúng tôi, điều này đang thay đổi theo hướng tách biệt nghiêm ngặt giữa hai, vì vậy môi trường sản xuất thực tế bị trừu tượng hóa và cấu hình của nó không được biết đến với nhóm phát triển. Vì vậy, chúng ta có thể kiểm soát các tập tin cấu hình của chúng ta - nhưng chúng ta làm, nhưng về cơ bản điều duy nhất hữu ích trong điều khiển phiên bản là lược đồ/cấu trúc của tệp cấu hình, chứ không phải dữ liệu, vì vai trò quản trị xử lý việc quản lý đó. – Jeremy

2

Chúng tôi sử dụng web.config transformations với VS 2010.

Bạn có thể chỉ định một file web.config tiểu học và sử dụng biến để vận dụng nó cho các môi trường khác nhau (ví dụ: thay đổi chuỗi kết nối cơ sở dữ liệu). Các biến đổi này được tự động hiển thị khi bạn triển khai/xuất bản (các) dự án của bạn.

Điều này cũng phụ thuộc vào loại thay đổi cần được triển khai. Mặc dù thông thường, cài đặt triển khai của chúng tôi chỉ thay thế các tệp đã được cập nhật. Vì vậy, nếu tất cả chúng ta thay đổi là chuyển đổi web.config.production, thì đó là tất cả những gì được triển khai.

Và có, chúng tôi lưu giữ tất cả tệp web.config và các biến đổi của chúng trong điều khiển nguồn vì chúng là một phần của ứng dụng dựa trên chúng.

Cũng có một số môi trường mà chúng tôi mở cho các nhóm/nhà phát triển khác nhưng không cho phép họ thay đổi cài đặt web.config để cài đặt triển khai/xuất bản của họ bỏ qua tệp web.config. Mặc dù là quy tắc chung, chúng tôi không trực tiếp chạm vào tệp trên máy chủ. Chúng tôi luôn cập nhật các tệp cục bộ để các thay đổi có thể được theo dõi thông qua kiểm soát nguồn và được triển khai đúng cách.

Các vấn đề liên quan