Theo dõi hiệu quả các thay đổi về cấu hình từ dev đến prod

Câu hỏi này lấy một dịch vụ Spring Boot làm ví dụ, nhưng nó có thể là bất kỳ công nghệ nào.

Giả sử như sau:

• Môi trường (dev / QA / prod) được sở hữu bởi các đội khác nhau. Điều này có nghĩa là dev phải không có quyền truy cập vào cấu hình prod.
• Cấu hình (giả sử application.properations) được đặt ngoài, tức là không phải là một phần của nhị phân
• Cùng một gói nhị phân / gói (giả sử service.jar) được triển khai trong từng môi trường và được kiểm soát bởi triển khai tự động

Mặc dù các thay đổi đối với tạo tác nhị phân (service.jar) được truyền tự động đến từng môi trường, các thay đổi về cấu hình vẫn cần can thiệp thủ công, chắc chắn cuối cùng sẽ bị đồng bộ hóa trong từng môi trường.

Ví dụ: giả sử nhóm dev thêm một vài cặp khóa-giá trị vào application.properations trong môi trường của họ. Điều gì sẽ là cách tốt nhất để ghi lại các khóa mới này, để khi việc triển khai xảy ra trong nhóm ops, họ biết chính xác những khóa nào cần thêm, vì vậy nguy cơ bắt đầu dịch vụ mới và thấy nó bị lỗi do thiếu khóa được giảm thiểu?

Tôi biết sẽ có các bước thủ công liên quan, nhưng tôi muốn biết mọi người giải quyết vấn đề này như thế nào và tìm ra cách hiệu quả nhất.

Đây chủ yếu là một vấn đề giao tiếp, nhưng bạn có thể ít mắc lỗi hơn bằng một số biện pháp kỹ thuật và tổ chức đơn giản. Trước tiên, bạn nên cung cấp một tài liệu tốt, chất lượng cao cho tất cả các mục trong tệp cấu hình của bạn, cũng như một số ví dụ dễ truy cập hoặc tệp cấu hình "mặc định". Tệp ví dụ có thể được tự động triển khai cho từng môi trường, vì nó không được dự định thay đổi trực tiếp bởi nhóm prod.

Tiếp theo, với mỗi bản phát hành mới, cung cấp một thay đổi, trong đó các thay đổi quan trọng được ghi lại. Thay đổi cấu hình có thể ngăn hệ thống hoạt động khi chúng bị thiếu luôn luôn quan trọng, vì vậy hãy đảm bảo thông tin có ở đó.

Ví dụ: giả sử nhóm dev thêm một vài cặp khóa-giá trị vào application.properations trong môi trường của họ. Điều gì sẽ là cách tốt nhất để ghi lại các khóa mới này, để khi việc triển khai xảy ra trong nhóm ops, họ biết chính xác nên thêm khóa nào, vì vậy nguy cơ bắt đầu dịch vụ mới và thấy nó bị lỗi do thiếu khóa bị giảm thiểu?

Cách tốt nhất để giảm rủi ro thất bại là tránh thay đổi ứng dụng của bạn theo cách nó yêu cầu các khóa mới, vì vậy ứng dụng phải tương thích ngược với các tệp cấu hình cũ bất cứ khi nào có thể. Thông thường, ứng dụng của bạn có thể hoạt động theo cách hợp lý bằng cách cung cấp các giá trị mặc định sẵn có cho các khóa mới cho trường hợp chúng bị thiếu.

Tuy nhiên, nếu điều đó là không thể, hệ thống của bạn sẽ giúp nhóm prod dễ dàng tìm ra lý do tại sao dịch vụ mới không khởi động khi thiếu khóa. Cần có thông báo lỗi rõ ràng, cho biết chính xác khóa nào bị thiếu trong tệp nào và nếu cần tìm thông tin về khóa bị thiếu hoặc gợi ý hoặc ví dụ về mục nhập có ý nghĩa cho khóa này.

Nếu cấu hình phức tạp và định dạng thay đổi theo cách chỉnh sửa thủ công dễ bị lỗi, bạn cũng có thể xem xét để cung cấp các công cụ để chỉnh sửa cấu hình và để chuyển sang phiên bản mới hơn.

Ví dụ: tôi đang sử dụng trình duyệt web Firefox và với mỗi bản phát hành mới (mà tôi nhận được tự động), một số thứ nhất định được thêm vào cấu hình cục bộ mà người ta có thể kiểm tra trên trang "about: config". Điều này có thể so sánh với cấu hình trong môi trường "sản xuất" của bạn. Vì toàn bộ cấu hình được giữ tương thích ngược hoàn toàn, tôi không bao giờ phải thêm khóa mới vào cấu hình theo cách thủ công chỉ vì có một bản phát hành mới của trình duyệt. Và trong trường hợp tôi muốn thay đổi một cái gì đó ở đó (có thể là một mục mới không phải là một phần của phiên bản trước), tôi sử dụng menu Công cụ / Tùy chọn hoặc trang "about: config" và có thể tìm thấy mục đó cộng với một số loại tài liệu. Vì vậy, tôi khuyên bạn nên cố gắng thực hiện hệ thống của bạn theo cách so sánh.

Tại một nơi tôi từng làm việc, họ có một vấn đề tương tự. Cấu hình sản xuất được kiểm soát bởi nhóm xây dựng, chỉ họ mới có quyền truy cập vào kho lưu trữ mã. Mọi người đều có thể nhìn thấy các cấu hình dev, qa, test, v.v.

Trong ví dụ của bạn, nhà phát triển sẽ cập nhật tệp cục bộ, kiểm tra tệp để kiểm soát nguồn và sau đó ai đó sẽ yêu cầu nhóm xây dựng thực hiện bản dựng "chỉ cấu hình" mới để kiểm tra tệp cấu hình và triển khai chúng, nhưng không biên dịch lại hoặc triển khai lại toàn bộ ứng dụng.

Các thành viên trong nhóm phải cập nhật các tệp cấu hình cho các môi trường khác vào thời điểm thích hợp. Khi đến lúc cập nhật để sản xuất, nhóm xây dựng phải cập nhật tệp, thông qua một yêu cầu rõ ràng từ trưởng nhóm phát triển, mặc dù thông thường yêu cầu chỉ đơn giản là "sao chép tệp app.config từ QA1 sang PROD". Những thứ nhạy cảm như mật khẩu nằm trong một tệp cấu hình riêng biệt và một lần nữa, chỉ nhóm xây dựng mới có thể truy cập tệp mật khẩu Sản xuất. Sự khác biệt là các nhà phát triển thường khôngyêu cầu thay đổi tập tin mật khẩu vì họ sẽ không có mật khẩu sản xuất. Lần duy nhất họ sẽ yêu cầu nhóm xây dựng cập nhật nó là khi thêm mật khẩu mới cho một dịch vụ mới. Và thậm chí sau đó, các nhà phát triển có thể sẽ không biết mật khẩu Sản xuất, họ chỉ biết khóa để thêm vào tệp (chẳng hạn như "newService2.password").

Công nghệ được sử dụng để quản lý rất nhiều thứ này là Jenkins. Ngoài ra còn có một công cụ nội bộ được sử dụng để yêu cầu và lên lịch xây dựng thông qua Jenkins.