2011-01-12 31 views
7

Nền:
Bước 1 -> Chúng tôi có một hộp chạy đơn vị và thử nghiệm chức năng của ứng dụng bằng cách chạy nó ở chế độ thử nghiệm với cấu hình cụ thể.
Bước 2 -> Khi thành công của Bước 1, chúng tôi chạy thử nghiệm tích hợp của một ứng dụng bằng cách chạy nó trong chế độ thử nghiệm với bộ cấu hình khác nhau, trong một hộp khác.
Bước 3 -> Khi thành công của bước 2, chúng tôi chạy thử nghiệm hiệu suất của một ứng dụng bằng cách chạy nó trong chế độ sản xuất, trong hộp kiểm tra hiệu suất.
Bước 4 -> Khi thành công của bước 3, bản dựng được coi là ổn định và hộp UAT được cập nhật với cơ sở mã đó và ứng dụng được chạy ở chế độ sản xuất, để xem xét và phản hồi của khách hàng. Bước 5 -> Với GO từ khách hàng, hộp sản xuất được cập nhật với cơ sở mã.Biến môi trường hoặc tệp cấu hình YAML

Bây giờ, từ các bước trên, chúng tôi quan sát thấy ở bước 1 và 2, trong khi ứng dụng chạy ở chế độ thử nghiệm, nó có cấu hình khác nhau. Tương tự như trường hợp với các bước 3,4 và 5.

Trong những trường hợp như vậy, thực hành được khuyến nghị là gì? Chúng tôi đã có các tệp cấu hình YAML, nhưng cá nhân tôi cảm thấy rằng việc duy trì nhiều tệp cấu hình không có ý nghĩa. Và như vậy, tôi đã thay đổi từ việc thực hành
"tập tin cấu hình cho mỗi môi trường"
để
"tập tin cấu hình cho mỗi chế độ đường ray, externalizing các biến môi trường linux".

Tôi có đi đúng hướng không? Không phải hành động của tôi, đơn giản hóa mọi thứ sao?

Ưu và nhược điểm của hai cách tiếp cận này là gì?

Trả lời

11

Theo kinh nghiệm của tôi, các biến môi trường là tùy chọn cấu hình của phương sách cuối cùng.Họ hoàn toàn có vị trí của họ, nhưng các ứng dụng thường nên kiểm tra một số tùy chọn cấu hình đáng tin cậy hơn và rõ ràng có chủ ý khác trước. Tôi rất khuyên bạn nên tải cấu hình từ một tập tin YAML và chỉ sử dụng một biến môi trường như một dự phòng. Luôn luôn giả sử rằng biến môi trường của bạn sẽ áp dụng cho tất cả mọi thứ trên toàn hệ thống và giả định rằng nó sẽ vô tình bị bỏ đặt hoặc đặt giá trị sai tại một số điểm. tức là, ứng dụng của bạn không được cam kết vì một số thư mục cấu hình đã được đặt thành / và không có quyền đối với nó (hoặc tệ hơn là bạn xóa ổ đĩa của mình vì ứng dụng chạy dưới dạng root). Hoặc nhiều khả năng, một cái gì đó như số RAILS_ENV của bạn đã được đặt thành test khi nó phải là production và không ai nhận ra và bây giờ người dùng đang ghi dữ liệu sai địa điểm hoặc đến /dev/null trên tài khoản của tất cả 500s.

Cá nhân, tôi muốn thả logger.warn thư bất cứ lúc nào tôi dự phòng thành biến môi trường cho giá trị cấu hình.

Với vấn đề chính xác của bạn, thành thật mà nói, tôi có thể vượt qua trong giá trị cấu hình mà môi trường để bắt đầu trên dòng lệnh.

+0

Cảm ơn. Nó dựa trên tuyên bố của bạn rằng biến môi trường cho cấu hình ứng dụng là hành động cuối cùng được sử dụng và lời khuyên của bạn để sử dụng tệp YAML để tải cấu hình ứng dụng, tôi đã đưa ra thiết kế mà tôi đã viết trong bài đăng của mình. Câu trả lời của bạn đã tăng gấp đôi niềm đam mê của tôi để có được giải pháp. Một lần nữa cám ơn! – karthiks

+0

Vâng, điều này, một triệu lần. Cấu hình các tập tin bị rối tung với ít hơn Môi trường. Ngoài ra, khi bạn đọc lại tệp cấu hình, bạn sẽ nhận được giá trị được lưu mới nhất. Tôi không thể nói cho bạn biết bao nhiêu lần tôi phải giải thích cho mọi người rằng bạn phải thay đổi một cách rõ ràng biến môi trường hiện tại của shell của bạn hoặc giết shell của bạn sau khi thay đổi .profile và khởi động lại nó để có được một biến môi trường được cập nhật. Nó khiến mọi người bối rối. Chỉ cần sử dụng một tập tin cấu hình. – kmort

0

Tại công ty của tôi, chúng tôi thực sự có cả hai, theo cách nào đó.

Chúng tôi có ứng dụng Rails có thể trỏ vào một trong nhiều cài đặt khác nhau của một phần mềm khác và sử dụng API từ cài đặt đó. Để chỉ định cài đặt, cần phải đặt khoảng 5 biến.

Chúng tôi đã có mỗi biến số này dưới dạng biến môi trường riêng biệt, nhưng việc đặt tất cả các biến trở thành cũ thực sự nhanh và chúng tôi chắc chắn đã quên một biến. Vì vậy, bây giờ chúng ta có một biến môi trường mà chúng ta gọi là ENV_TOKEN và chúng ta có các tệp yaml chứa các mục tương ứng với các biến ENV_TOKEN hợp lệ và mã trong config/initializers đặt ENV [key] = value.

Vì vậy, giả sử tôi có các biến "FOO" và "BAR" mà tôi muốn đặt thành "một" và "hai", tương ứng. Tôi có thể tạo ra một tập tin yaml có chứa:

carolclarinet: 
    FOO: one 
    BAR: two 

và sau đó tôi sẽ thiết lập môi trường ENV_TOKEN biến tôi để carolclarinet và FOO và BAR được thiết lập để một và hai.

Tôi không biết đây có phải là cách tốt nhất để thực hiện việc này hay không, nhưng nó có hiệu quả đối với chúng tôi.

ETA: Lưu ý rằng đây chỉ dành cho việc phát triển và kiểm tra, trình cài đặt phần mềm của chúng tôi sẽ xử lý tất cả những điều này để khách hàng của chúng tôi không bao giờ thay đổi bất kỳ biến môi trường nào.

+0

Tôi không chắc đó có phải là cách tốt nhất hay không, nhưng đó chắc chắn là một sự cải tiến. –

0

Sau rất nhiều googling vô ích, thảo luận với một số đường ray folks và một số brainstroming, tôi đã thực hiện thay đổi mã như vậy mà tôi có "Một tập tin cấu hình cho mỗi chế độ ray, bên ngoài các cấu hình ứng dụng vào một tập tin yml, mà trong trường hợp của tôi vẫn còn bên ngoài môi trường đường ray"

Thêm các chi tiết của nó có thể được tìm thấy trong bài viết trên blog của tôi tại http://bit.ly/hpChwl

Cảm ơn tất cả các bạn đã chia sẻ suy nghĩ của bạn. Hy vọng giải pháp của tôi có lợi cho bạn tất cả :)

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