Kiểm soát phiên bản và tập tin cấu hình cá nhân

Dự án của chúng tôi sử dụng một tập tin cấu hình dành riêng cho người dùng. Tập tin này hiện không nằm trong kiểm soát phiên bản, vì nó khác nhau đối với mỗi người dùng. Vấn đề là, bất cứ khi nào nhà phát triển thêm một mô-đun mới yêu cầu cấu hình hoặc thay đổi tên của các mô-đun hiện có, các nhà phát triển khác sẽ gặp lỗi vì các tệp cấu hình riêng tư của họ không được cập nhật.

Để giải quyết vấn đề, chúng tôi đã nghĩ đến việc làm việc với hai tệp cấu hình: tệp cấu hình mặc định / toàn cầu sẽ được kiểm soát phiên bản và sẽ được cập nhật thường xuyên bởi mỗi nhà phát triển có thêm mô-đun mới và tệp cấu hình riêng sẽ được giữ ngoài kiểm soát phiên bản và sẽ chỉ chứa các thay đổi cụ thể của người dùng.

Tuy nhiên, đây vẫn có vẻ là một giải pháp đặc biệt.

Bạn có thể đề xuất một giải pháp tốt hơn?

Các chuyên gia làm gì?

Mặc dù bạn đã có một số câu trả lời tốt ở đây, nhưng hầu hết chúng đều bỏ lỡ nguyên nhân cốt lõi của vấn đề của bạn: các tệp cấu hình người dùng của bạn dường như chứa nhiều thông tin không chỉ dành cho người dùng, chúng còn chứa thông tin (có thể là dự phòng) nằm dưới sự kiểm soát phiên bản ở một nơi khác , có lẽ trong các tệp khác nhau, như tên mô-đun.

Tôi có thể nghĩ về hai giải pháp khả thi ở đây:

• cố gắng tách thông tin đó một cách chặt chẽ Ví dụ: không sử dụng bất kỳ tên mô-đun nào trong cấu hình người dùng của bạn. Sử dụng số id (ví dụ: GUID) để chỉ các mô-đun và để các số id đó không bao giờ thay đổi sau khi chúng được gán cho mô-đun. Tất nhiên, điều đó có thể có nhược điểm là các tệp cấu hình người dùng của bạn mất đi một số tính đơn giản mà chúng có thể có bây giờ. Có lẽ bạn sẽ cần phải tạo một công cụ GUI để chỉnh sửa các tệp cấu hình của mình thay vì sử dụng trình soạn thảo văn bản thuần túy.

• cung cấp cho định dạng tệp cấu hình của bạn một số phiên bản và bất cứ khi nào một cái gì đó như tên mô-đun được thay đổi, hãy gán cho chúng một số phiên bản mới. Sau đó, bạn có thể cung cấp tập lệnh nâng cấp để kiểm tra số phiên bản và nếu tệp cấu hình không cập nhật, nó sẽ thay đổi tất cả các tên mô-đun mà nó tìm thấy trong tệp và tăng số phiên bản sau đó. Điều này có thể được tự động hóa, vì vậy quá trình nâng cấp sẽ không làm phiền đồng đội của bạn trong công việc hàng ngày.

EDIT: sau khi đọc bài đăng của bạn một lần nữa, tôi nghĩ giải pháp được cho là của bạn là hợp lý, miễn là các mô-đun mới chỉ được thêm, nhưng không được đổi tên. Những gì tôi đã viết ở trên sẽ cho phép thay đổi tên mô-đun hoặc cấu trúc cấu hình của các mô-đun hiện có sau đó. Nhưng nếu bạn không cần điều đó, tôi sẽ chọn giải pháp đơn giản nhất.

Đó là một giải pháp hợp lý.

Bạn cần một cách chỉ định (các) giá trị ban đầu của bất kỳ (các) thành phần cấu hình mới nào. Chúng phải được lưu trữ ở đâu đó và tệp cấu hình toàn cầu, chỉ đọc, là lựa chọn rõ ràng.

Sau đó, khi mỗi người dùng thay đổi cấu hình cá nhân của họ, bạn viết những thay đổi này vào bản sao cục bộ của họ.

Mã của bạn sẽ cần phải đọc cấu hình toàn cầu trước và người dùng cụ thể để ghi đè lên bất kỳ giá trị thay đổi nào. Điều này sẽ đơn giản hơn nhiều so với việc đọc địa phương và sau đó cố gắng tìm ra cái nào chưa được đặt và do đó cần đọc từ tệp cài đặt chung.

Nếu bạn sử dụng một cái gì đó như XML để lưu trữ thì bạn không phải lo lắng về việc xử lý trường hợp bạn xóa cài đặt. Họ sẽ không được yêu cầu từ người dùng sao chép tệp và nếu bạn tạo lại tệp khi lưu, họ sẽ bị xóa lần đầu tiên khi ứng dụng được sử dụng sau khi thay đổi.

Chúng tôi có một giải pháp khá thú vị, chủ yếu là các nhà phát triển PHP, vì vậy chúng tôi sử dụng Phing cho phép bạn tạo các tác vụ tự động được viết bằng PHP, vì vậy thay vì thực hiện cập nhật svn thông thường, chúng tôi thực hiện "cập nhật phing" gọi là cập nhật svn, và sau đó thay thế các cấu hình của chúng tôi bằng các biến thích hợp, ví dụ: một cấu hình:

$db_user = "${test.db_user}";

Vì vậy, các tệp cấu hình đều được phiên bản với cú pháp thú vị đó và sau đó chúng tôi tạo một tệp cấu hình adhoc, không đảo ngược cho trường hợp cụ thể của tôi, thay thế các "biến" đó bằng các cài đặt không đảo ngược được chỉ định trong các tệp ini không đảo ngược. Bằng cách này, chúng tôi có thể sửa đổi bất kỳ tệp cụ thể nào của người dùng và có các thay đổi được đưa vào trong các bản sao làm việc khác.

Chương trình nên có một cài đặt mặc định trong mã khi không tìm thấy giá trị trong tệp cấu hình. Bằng cách này, khi những thứ mới được thêm vào, nó sẽ không bị hỏng, đường dẫn nâng cấp của bạn sẽ mượt mà hơn và người dùng của bạn sẽ có dự phòng khi họ làm hỏng tập tin cấu hình.

Một ví dụ phức tạp khác sẽ là khi khởi động chương trình hoặc một số điểm chính khác, mở tệp cấu hình bằng mô-đun khởi tạo và thêm bất kỳ mặc định nào bị thiếu, nhưng điều này có vẻ khá nặng.

Đặt số phiên bản vào tệp cấu hình cá nhân (số phiên bản của định dạng tệp cấu hình).

Tạo mã xử lý tệp cấu hình cá nhân kiểm tra số phiên bản và nếu nó lỗi thời, hãy chạy qua quy trình cập nhật. Vì vậy, về cơ bản, bất kỳ ai thực hiện thay đổi sẽ phá vỡ các tệp cấu hình hiện tại đều cần phải tăng số phiên bản của định dạng tệp cấu hình và viết một quy trình để cập nhật các tệp cấu hình của phiên bản trước (đổi tên các phần, v.v.) và lưu lại họ

Bạn có thể sẽ muốn một số quy trình như thế này cho người dùng cuối, vì vậy bạn cũng có thể sử dụng nó để làm cho cuộc sống của các nhà phát triển của bạn dễ dàng hơn.

Thông thường cách tôi đã thấy nó là để có một tệp cấu hình với các giá trị mặc định được kiểm tra vào kho lưu trữ. Đây có thể là, ví dụ, các giá trị cần thiết trên máy chủ thử nghiệm. Sau đó, khi một nhà phát triển kiểm tra tệp, họ sẽ có tất cả các giá trị. Nếu một trường mới được thêm vào hoặc một trường bị loại bỏ, trường này được xử lý trong một sự hợp nhất. Nhà phát triển sẽ kiểm tra giá trị cần thiết cho máy chủ mục tiêu và không kiểm tra bất kỳ thay đổi nào khác đối với các trường dành cho môi trường phát triển cá nhân của anh ta.

Cần phải đảm bảo rằng việc hợp nhất được thực hiện đúng, nhưng nó có vẻ khá an toàn với tôi.

Những gì chúng tôi làm ở đây là tạo các khối cài đặt. Điều này có thể được thực hiện trong Zend như thế này:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Điều này có nghĩa là thử nghiệm kế thừa sản xuất và mở rộng nó với key3. Tất cả mỗi nhà phát triển sau đó cần làm là thiết lập môi trường của mình (thử nghiệm hoặc sản xuất trong trường hợp này)

Đây là một giải pháp hữu ích dựa trên bài đăng: Giữ mật khẩu trong kiểm soát nguồn

Tóm lại, chiến lược là "giữ một phiên bản được mã hóa của tệp cấu hình trong kiểm soát nguồn và sau đó cung cấp một phương tiện để người dùng có thể mã hóa và giải mã dữ liệu đó".

1. Tạo một tệp comfig giả và .gitignore nó.
2. Tạo một tệp thực hiện có thể mã hóa và giải mã tệp cấu hình
3. Lưu trữ tệp Makefile và tệp cấu hình được mã hóa trong kho lưu trữ
4. Makefile yêu cầu mật khẩu và cách liên hệ với tác giả để biết mật khẩu.
5. Khi xây dựng dự án, nếu tệp Makefile chưa chạy, hãy thông báo cho người dùng với console.error ("Tệp cấu hình [conf / settings.json] bị thiếu! Bạn có quên chạy make decrypt_confkhông?");
6. Một kiểm tra được mô tả để đảm bảo tập tin cấu hình được cập nhật.

Chúng tôi đã xây dựng một công cụ có tên là Config để xử lý các vấn đề cấu hình như thế này. Những gì bạn sẽ làm là tạo (hoặc nhập) 1 tệp cấu hình chính. Sau đó tạo một môi trường gọi là Local. Trong môi trường cục bộ, tạo nhiều phiên bản, 1 phiên bản cho mỗi người dùng. Nếu bạn cần thực hiện một thay đổi phổ biến trên bảng, như thêm mục nhập cấu hình mới hoặc sửa đổi tên mô-đun, chỉ cần thực hiện thay đổi và nó sẽ được áp dụng trên bảng. Nếu bạn muốn thay đổi cá thể / người dùng, hãy biến giá trị cấu hình đó thành một biến, sau đó thay đổi biến. Thay đổi này sẽ chỉ được áp dụng cho cá thể / người dùng của bạn. Tất cả những thứ này đều nằm dưới sự kiểm soát của phiên bản. Bạn triển khai các tệp cấu hình thông qua đẩy hoặc kéo. Tùy chọn kéo tương tự như git pull, nhưng đối với cá thể / người dùng cụ thể đó.

Cấu hình cung cấp cho bạn các tính năng bổ sung như so sánh cấu hình giữa người dùng, tìm kiếm, gắn thẻ, xác thực và quy trình làm việc. Đó là SaaS nên không thực sự dành cho những người chưa sẵn sàng cho đám mây, nhưng chúng tôi có kế hoạch tại chỗ.