2011-08-28 36 views
5

Tôi đang cố gắng xây dựng một môi trường dev/test/QA hợp lệ cho bộ ứng dụng của công ty tôi để di chuyển sang Azure. Tuy nhiên, tôi đang thực thi ràng buộc đối với chúng tôi là dev/test/qa/etc của chúng tôi. môi trường thực sự được lưu trữ tại chỗ và được triển khai thông qua một máy chủ xây dựng (chẳng hạn như CC.NET, TeamCity, Jenkins, v.v.).Đây có phải là môi trường Azure QA hợp lệ và có thể không?

Trong "Môi trường thử nghiệm", chúng tôi cần khả năng kích hoạt triển khai một ảnh chụp cụ thể của mã không được phát hành (và dữ liệu) cho một nhóm chuyên gia QA và Business để kiểm tra cả thử nghiệm kỹ thuật và thử nghiệm chấp nhận kinh doanh. Rõ ràng tất cả những người này sẽ không biên dịch và nhấn F5 trong Visual Studio để thực hiện thử nghiệm này, vì vậy chúng tôi cần một môi trường để triển khai. Trong SDLC của chúng tôi, chúng tôi thực sự trải qua ~ 4 môi trường như vậy trước khi chúng tôi tiến hành dàn dựng và sản xuất. Tóm lại, chúng ta cần một quá trình triển khai tự động ở mức chi phí thấp và dễ tái sản xuất cho việc này.

Khi lên kế hoạch cho môi trường này, câu hỏi về "Cách lưu trữ dịch vụ Azure" rõ ràng là phần khó. Vì vậy, hãy nhìn vào từng phần của Azure. Các tùy chọn in nghiêng là những tùy chọn mà chúng tôi muốn thực hiện.

  • Vai trò Web Vâng, IIS có thể nhiều hơn hoặc ít hơn xử lý những đối với chúng tôi (ít nhất là đủ cho các tình huống dev/kiểm tra - tất cả nhưng thực thử tải mà rõ ràng chúng tôi có để làm trong Azure, đó là tốt).
  • Vai trò của nhân viên Có vẻ như chúng tôi có hai tùy chọn. Đầu tiên là có một ứng dụng "wrapper" là Windows Service và chúng ta có thể sử dụng nó để lưu trữ các DLL mà Roles Worker của chúng ta gọi cho chức năng (sau khi tất cả, dự án Worker Role thực sự của chúng ta không được gì hơn là tập tin cấu hình và ~ 4 dòng mã gọi một DLL để làm việc). Tùy chọn đó hoạt động, nhưng yêu cầu một số mã ứng dụng rất khác nhau và việc quản lý/bảo trì mã triển khai. Tùy chọn thứ hai là sử dụng Trình giả lập tính toán Azure. Điều này hoạt động miễn là Vai trò công nhân của bạn không cần giám sát các cổng bên ngoài hoặc bất kỳ thứ gì. Trong trường hợp của chúng ta, Role của Worker của chúng ta chỉ cần theo dõi các hàng đợi, và sau đó truy cập các tài nguyên khác nhau. (Các) vấn đề này xoay quanh các kịch bản xây dựng khác nhau vì cách duy nhất để tự động triển khai Azure Emulator là chạy CSPackCSRun trên máy lưu trữ Azure Emultor, có thể không phải là máy chủ xây dựng của bạn. Bởi vì điều này, bạn sẽ phải làm một số loại kịch bản từ xa để thực hiện điều này.
  • Vai trò VMChúng tôi không thực sự quan tâm những, vì vậy tôi hoàn toàn bỏ qua khía cạnh này của thử nghiệm.
  • Hàng đợi Ở đây, chúng tôi có 3 tùy chọn. Đầu tiên là sử dụng MSMQ. Bởi vì điều này đòi hỏi một codebase hoàn toàn khác mà chúng ta không có (hoặc ít nhất là trừu tượng xung quanh codebase khác nhau), tôi không xem xét tùy chọn này. Thứ hai là giữ hàng đợi trong Azure vì chúng quá nhỏ/rẻ. Chúng tôi thực sự tạm thời thực hiện việc này cho đến khi chúng tôi có thể thử tùy chọn thứ ba. Tùy chọn thứ ba là sử dụng Trình giả lập lưu trữ Azure. Tôi không chắc chắn nhưng tôi tin rằng tùy chọn này sẽ chỉ cho phép các dịch vụ chạy trên máy cục bộ để truy cập các đối tượng lưu trữ. Đối với Hàng đợi, mã ứng dụng của chúng tôi là mã thực sự "triển khai" các hàng đợi, vì vậy sẽ ổn khi mã ứng dụng của chúng tôi thực sự chạy trên máy chủ lưu trữ Trình mô phỏng bộ nhớ Azure.
  • Bàn Ở đây, chúng tôi có 3 tùy chọn.Đầu tiên là cái tôi ghét và đó là sử dụng cơ sở dữ liệu và tạo một bảng trong đó để truy cập vào các bảng này. Tôi không xem xét lựa chọn đó. Thứ hai là giữ các bảng trong Azure. Tôi không thích điều này bởi vì đó là rất nhiều back-and-ra cho những thứ có thể lưu trữ dữ liệu có kích thước đáng kể (lên đến 1MB cho mỗi bản ghi). Trong khi hàng đợi là cực kỳ nhẹ và rẻ, chi phí bảng có thể tăng lên khá nhanh chóng. Điều này để lại cho chúng ta tùy chọn thứ ba, sử dụng Trình giả lập lưu trữ Azure. Tôi không chắc chắn nhưng tôi tin rằng tùy chọn này sẽ chỉ cho phép các dịch vụ chạy trên máy cục bộ để truy cập các đối tượng lưu trữ. Tôi vẫn không hiểu tất cả các bảng ưu/khuyết điểm trong Trình giả lập.
  • Blobs Ở đây, chúng tôi có 2 tùy chọn. Việc đầu tiên là một xấu, và đó là giữ chúng trong Azure. Đây là những tệp có khả năng có kích thước đáng kể nhất, vì vậy đó là không khôn ngoan. Vì vậy, tùy chọn thứ hai, một lần nữa, là sử dụng Trình giả lập lưu trữ Azure. Tôi nghĩ đây là những gì chúng ta cần làm.

Vì vậy, cho rằng chúng ta có MVC Apps (vai trò web), các dịch vụ web WCF (web vai trò), Queues, Bàn, Blobs, và Worker Role được kích hoạt bởi hàng đợi nhưng bảng truy cập, các đốm màu, và WCF dịch vụ web, điều này có vẻ giống như một cách hợp lý để lưu trữ các môi trường QA (và tương tự) nội bộ của chúng tôi không? Và khác với một số phiền toái với CSPack script từ xa và CSRun để triển khai cho trình mô phỏng Azure, điều này có tất cả âm thanh hợp lý tự động với một máy chủ xây dựng?

Trả lời

10

IMHO: Bạn đang nhảy qua quá nhiều vòng để không phải triển khai Azure cho Dev & môi trường QA .. tại sao không chỉ triển khai và thử nghiệm các tập lệnh triển khai của bạn cùng một lúc? Sử dụng các phiên bản nhỏ để giữ chi phí thấp.

Giả lập lưu trữ không phải là/điều đó/tuyệt vời chút nào. Có nhiều khác biệt nhỏ sẽ làm cho thử nghiệm của bạn không đáng tin cậy. Bạn cũng không thử nghiệm cân bằng tải - điều gì đó sẽ tìm thấy các vấn đề với bất kỳ trạng thái phiên không có kế hoạch

+0

Tôi bắt đầu xem xét các đề xuất của bạn và của bạn về việc thực hiện mọi thứ trong Azure. Tuy nhiên, điều này chỉ cảm thấy sai với tôi. Ngay bây giờ chúng tôi có 2 "bản sao" của bộ ứng dụng của chúng tôi trong sản xuất nhưng cũng sẽ chiếm thêm 6 "bản sao" của bộ phần mềm của chúng tôi trong Azure. Điều đó có vẻ phần lớn lãng phí. Chúng tôi đang sử dụng các trường hợp cực nhỏ ngay cả đối với môi trường sản xuất của chúng tôi (rẻ hơn và nhanh hơn) để có thêm 6 bản sao kết thúc tăng thêm chi phí một cách khủng khiếp một cách nhanh chóng. Có một công cụ đã được thực hiện cho phép phi công nghệ để dễ dàng quay lên & quay xuống bộ trường hợp tính toán hoặc điều này sẽ cần phải được tùy chỉnh? – Jaxidian

+0

Bạn có thể quản lý mọi khía cạnh của dịch vụ được lưu trữ qua [Cổng quản lý Windows Azure] (http://msdn.microsoft.com/en-us/library/gg433078.aspx): "... Bạn có thể tạo, triển khai, chạy , tạm ngừng và xóa các dịch vụ được lưu trữ bằng Cổng Quản lý ... ". Vì vậy, quay lên/xuống dịch vụ lưu trữ theo yêu cầu là một nhiệm vụ dễ dàng. Khi các phiên bản không hoạt động, bạn sẽ không bị tính phí cho chúng. – andriys

+0

@Andriys: Đó thực sự không phải là giải pháp khả thi đối với những người QA phi kỹ thuật. Điều đó cũng đòi hỏi rằng họ có quyền truy cập quản trị, đó là KHÔNG cái gì đó tôi sẵn sàng làm với những người không nên là quản trị viên. – Jaxidian

7

Một trong những lời khuyên hữu ích nhất về Azure mà tôi nhận được là "Thử nghiệm trên Azure sớm nhất có thể". Nó sẽ giúp bạn giải quyết sự khác biệt giữa Azure thực và trình giả lập càng sớm càng tốt trong vòng đời phát triển của bạn, và có rất nhiều.

Thứ hai, các giải pháp thay thế của bạn nghe như rất nhiều công việc chỉ để có môi trường thử nghiệm. Tôi nghĩ lưu trữ trên Azure sẽ hiệu quả hơn về chi phí. Và cuối cùng, bạn sẽ vẫn phải kiểm tra trên Azure trước khi phát hành sản phẩm của bạn.

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