2008-09-25 19 views
7

Subversion là một cách tuyệt vời để cập nhật các ứng dụng web của chúng tôi trên các máy chủ của chúng tôi. Với một đơn giản svn update tất cả các tập tin thay đổi nhận được ... tốt, thay đổi.Bạn xử lý việc triển khai các tệp cấu hình trên các hệ thống khác nhau trong Subversion như thế nào?

Ngoại trừ các tệp cấu hình ở khắp nơi như config.php giữ cấu hình truy cập cơ sở dữ liệu, đường dẫn máy chủ v.v ... Và do đó khác nhau trên hệ thống phát triển cục bộ của tôi và máy chủ từ xa.

Với lệnh update, một tệp được sửa đổi trên máy chủ sẽ không bị ghi đè, nhưng nếu tôi thay đổi tệp cục bộ và cam kết, máy chủ sẽ nhận tệp cấu hình sai.

Nhưng tôi cũng không muốn đặt thuộc tính svn:ignore vì tệp cấu hình thuộc về dự án.

Có cơ chế Subversion nào cho phép tôi dễ dàng xử lý các loại tệp này không? Hoặc là cách duy nhất để giải quyết vấn đề này để thực hiện chuyển đổi hệ thống trong tệp cấu hình để xác định hệ thống thực thi và đặt cấu hình cho phù hợp?

Trả lời

1

Tôi tìm cách dễ nhất là bật tên máy của máy. Tôi có một tệp .ini với một phần chung cũng ghi đè điều này cho các hệ thống sản xuất, thử nghiệm và phát triển.

[general] 
info=misc 
db.password=secret 
db.host=localhost 

[production : general] 
info=only on production system 
db.password=secret1 

[testing : general] 
info=only on test system 
db.password=secret2 

[dev : general] 
info=only on dev system 
db.password=secret3 

Vì vậy, dev: db.hostword == 'secret3', nhưng dev: db.host == 'localhost', từ nhóm 'chung' ban đầu.

'Sản xuất', 'thử nghiệm' và 'dev' có thể là tên máy chủ, hoặc chúng là bí danh cho chúng được đặt từ một số cơ chế khác trong tập lệnh điều khiển cấu hình.

+0

Điều này có vẻ là ý tưởng chung, cảm ơn bạn. –

+0

Đối với hồ sơ, tôi sử dụng Zend Framework Zend_Config_Ini để đạt được điều này. Hiệu ứng thừa kế là chức năng out-of-the-box cho nó. –

+1

Tôi không nghĩ rằng điều này quy mô ... ở tất cả. – xmjx

3

Tạo mẫu cho tệp (ví dụ: config.php-default) và cho phép người dùng sao chép mẫu. Cô cũng có thể làm một sự khác biệt để xem những gì đã thay đổi giữa các phiên bản để kết hợp những thay đổi này trong phiên bản được triển khai cục bộ của tệp.

+0

Đó cũng là một ý tưởng hay, tôi thích nó vì sự đơn giản của nó. –

1

Trên các dự án tôi hiện đang làm việc trên chúng tôi có 2 tệp thuộc tính cho thông tin lược đồ cơ sở dữ liệu - một cho môi trường sản xuất và một cho phát triển. Chúng tôi có một lớp tải tất cả các thuộc tính của chúng tôi cho mô-đun đang được thực thi, với logic xác định tệp cần tải.

Vì môi trường phát triển của chúng tôi cục bộ là hệ thống tệp Windows và máy chủ sản xuất hoạt động trên hệ thống tệp UNIX, giải pháp của chúng tôi là xác định hệ điều hành của máy chủ và tải tệp chính xác.

Chúng tôi giữ các thông tin này trực tiếp trong kiểm soát nguồn của chúng tôi để giữ lịch sử bất kỳ thay đổi nào được thực hiện. Tôi nghĩ rằng chúng tôi đã học được một bài học từ ngón tay khách hàng (nội bộ) của chúng tôi chỉ liên quan đến YÊU CẦU YÊU CẦU B INSNG CÁCH THAY ĐỔI, trong đó chúng tôi cần có khả năng bảo vệ bất kỳ thay đổi nào trong quá khứ đối với các tệp.

Điều này có thể là duy nhất cho tình huống của chúng tôi, nhưng tôi thấy điều này cực kỳ hữu ích, đặc biệt nếu tôi đang cố gắng lặp lại chạy thử từ bản sửa đổi trước đó.

1

Một số giải pháp khả thi:

Nếu bạn đang sử dụng một máy chủ ứng dụng J2EE, bạn có thể tra cứu bất động sản thông qua JNDI, có các công cụ để dễ dàng thiết lập và xem chúng trên máy chủ.

Bạn có thể có tệp thuộc tính mặc định trong máy chủ lật đổ, nhưng tìm ở nơi khác trên máy chủ (bên ngoài các phần của dự án được kiểm tra vào svn) cho tệp thuộc tính thực, nhưng sau đó bạn thường nhận được đường dẫn phụ thuộc vào hệ điều hành và phải nhớ cập nhật các tệp thuộc tính thực theo cách thủ công khi bạn thêm thuộc tính mới vào tệp svn của mình.

Bạn có thể đặt thuộc tính trong tệp thuộc tính như một phần của bản dựng và chuyển thông số vào lệnh xây dựng để cho biết môi trường máy chủ cần xây dựng. Điều này có thể cảm thấy một chút bùng binh, và bạn phải nhớ cập nhật kịch bản xây dựng với các thuộc tính mới. Nhưng nó có thể hoạt động tốt - nếu bạn thiết lập một máy chủ tích hợp liên tục, nó có thể xây dựng cho tất cả các môi trường khác nhau và kiểm tra các gói cho bạn. Sau đó, bạn biết bạn đã triển khai một cái gì đó sẵn sàng.

+0

Tôi không ở trên máy chủ J2EE, nhưng nguyên tắc chung vẫn giữ nguyên: Xây dựng một công tắc vào mã. –

2

Bạn có thể muốn xem xét thực tế là các nhà phát triển sẽ không (Và có lẽ không nên) có quyền truy cập vào tên người dùng/mật khẩu cho máy sản xuất.

Để đối phó với điều này, cấu hình như vậy phải được coi là 'chi tiết triển khai', thay vì cấu hình ứng dụng tổng thể. Ngay cả khi bạn tạo ra sự khác biệt về khái niệm này, bạn vẫn cần phải xử lý các môi trường triển khai khác nhau, nhưng dường như bạn đang xử lý PHP, tôi không thể nhận xét về các chi tiết cụ thể cho trường hợp của bạn. Như Lars đã đề cập, một giải pháp J2EE có thể là lưu trữ các chi tiết như vậy dưới JNDI, làm cho cùng một ứng dụng nhị phân có thể triển khai trên bất kỳ môi trường nào, để các quản trị viên/quản trị viên thiết lập tên người dùng/mật khẩu cho mỗi máy.

1

Bạn cũng có thể đặt tên miền tệp cấu hình của mình phụ thuộc. Bằng cách này bạn có thể tạo cấu hình cho máy cục bộ của bạn và cho (các) máy chủ sản xuất. Bạn cần phải xây dựng logic của khóa học để xử lý điều này.

Nếu bạn chạy máy chủ web apache, bạn có thể dễ dàng định cấu hình để mọi nhà phát triển sử dụng tên miền phụ của họ trên hộp địa phương thay vì chỉ sử dụng localhost. Bằng cách này, mọi nhà phát triển đều có thể sử dụng cấu hình của riêng họ.

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