Thay đổi hệ thống hiện có một cách an toàn

Xác định các hợp đồng quanh thay đổi

Phần mềm hiện có có thành phần gọi, dữ liệu lưu trữ, job theo lịch và quy trình vận hành. Một số phụ thuộc không hiện trong tệp bạn muốn sửa. Agent có thể tạo thay đổi đúng ở cục bộ nhưng phá vỡ một trong các hợp đồng đó.

Trước khi thực hiện, xác định các thành phần đọc và ghi dữ liệu bị ảnh hưởng. Kiểm tra route, job nền, báo cáo và tích hợp bên ngoài. Xem nhóm khác hoặc phiên bản client cũ có phụ thuộc vào hành vi hiện tại không.

Yêu cầu agent đưa bằng chứng cho sơ đồ này. Kết quả tìm kiếm là điểm bắt đầu hữu ích, nhưng lời gọi động và bên sử dụng bên ngoài có thể cần người phụ trách xác nhận phụ thuộc.

Làm cho hành vi hiện tại có thể quan sát

Với mô-đun thiếu tài liệu, thêm kiểm tra có trọng tâm quanh hành vi phải giữ ổn định. Các kiểm tra mô tả hợp đồng hiện tại. Chúng không chứng minh mọi hành vi hiện có đều là mong muốn.

Nếu hành vi hiện tại xung đột yêu cầu, ghi xung đột. Không giữ lỗi bảo mật chỉ vì test đã ghi nhận nó. Xin quyết định cần thiết để phân biệt hành vi mong muốn với lỗi.

Dùng fixture sát thực tế, không nhạy cảm. Bao gồm cấu trúc dữ liệu cũ và bản ghi không đầy đủ ở nơi chúng có thể xuất hiện. Schema mới chỉ được thử với dữ liệu mới tạo có thể che vấn đề migration.

Review quá trình chuyển giữa các phiên bản

Xét ví dụ giả định đổi customer_name thành display_name. Đổi tên ngay có thể làm instance ứng dụng cũ lỗi trong lúc triển khai. Cập nhật hai tệp trong cùng pull request không khiến quá trình triển khai trở thành thao tác nguyên tử.

Cách làm theo giai đoạn có thể giữ tương thích:

1. Thêm trường mới mà không xóa trường cũ.
2. Xác định cách thao tác ghi mới giữ các giá trị cần thiết nhất quán.
3. Backfill bản ghi hiện có bằng quy trình có thể chạy tiếp sau gián đoạn.
4. Kiểm chứng tính đầy đủ và hành vi của thành phần đọc.
5. Chuyển thành phần đọc sang trường mới.
6. Chỉ xóa trường cũ khi không còn thành phần sử dụng.

Phương pháp cụ thể phụ thuộc cơ sở dữ liệu và cách ghi. Ghi kép có thể gây không nhất quán nếu một lần ghi thất bại. Có thể cần transaction cơ sở dữ liệu hoặc phương pháp đồng bộ rõ ràng khác. Không áp dụng ví dụ này khi chưa kiểm tra các bảo đảm của hệ thống.

Martin Fowler mô tả quá trình chung này là parallel change, còn gọi là expand-and-contract. Ý chính là chuyển đổi tương thích trước khi xóa bỏ.

Lập kế hoạch khôi phục riêng với rollback

Rollback mã khôi phục phiên bản ứng dụng trước đó. Nó không tự động hoàn tác migration dữ liệu. Phiên bản cũ có thể không hiểu dữ liệu mới. Migration phá hủy dữ liệu có thể xóa thông tin mà rollback mã không khôi phục được.

Xác định hành động khôi phục cho từng bước. Một quy trình backfill hỗ trợ chạy lại có thể được tiếp tục một cách an toàn. Biến đổi sai có thể cần sửa từ dữ liệu nguồn đã giữ. Thao tác phá hủy có thể cần quy trình khôi phục đã kiểm chứng.

Hỏi ai phụ trách quyết định khôi phục và có thể mất bao lâu. Đừng coi “chúng tôi có backup” là bằng chứng rằng khôi phục đáp ứng yêu cầu dịch vụ.

Giữ thay đổi có thể review

Tách dọn dẹp không liên quan khỏi thay đổi chức năng. Cung cấp kế hoạch tương thích, kết quả kiểm chứng và điều kiện xóa bỏ trong pull request. Đánh dấu thời điểm sau đó rollback cần công việc bổ sung.

Agent có thể hỗ trợ kiểm tra bên sử dụng và chuẩn bị mã migration. Người phụ trách vẫn phải chấp nhận kế hoạch chuyển đổi và khôi phục. Thiết kế cuối cùng chỉ là một phần của thay đổi an toàn.