Làm thế nào để bạn xử lý việc triển khai thay đổi cơ sở dữ liệu?

Chúng tôi đã thảo luận về các kỹ thuật triển khai cơ sở dữ liệu ngày hôm nay, đã có một vài lỗi gần đây trong quy trình hiện tại của chúng tôi và đã thấy các tình huống mà chúng tôi muốn quay lại triển khai nhưng phiên bản cũ của ứng dụng chưa bao giờ được thử nghiệm so với phiên bản mới của cơ sở dữ liệu.

Một mặt, có các triển khai kiểu Di chuyển, trong đó bạn có hướng dẫn phiên bản và hướng dẫn giảm phiên bản (cho dù được viết bằng SQL hoặc bằng ngôn ngữ ứng dụng của bạn) và ứng dụng của bạn biết phiên bản nào cần có.

Đây là những điều đơn giản và vì chúng tôi sẽ không quay trở lại thường xuyên, các nhà phát triển quan tâm đến sự đơn giản. Tuy nhiên, có những rủi ro khi bạn thêm một trường / bảng và trường đó được điền trước khi bạn quay lại. Hoặc tệ hơn, nơi bạn thả dữ liệu có liên quan đến phiên bản trước.

Mặt khác, chúng ta có thể xem xét một phương pháp nâng cấp, rollback, rollforward trong đó việc quay trở lại không quyết liệt như với Migration. Ví dụ: nâng cấp có thể thêm trường không nullable; rollback làm cho nó vô hiệu để ứng dụng cũ không quan tâm; rollforward điền vào các trường null và làm cho nó không thể rỗng nữa.

Điều này giữ lại dữ liệu nhưng phức tạp cả về mã và kiểm tra (đáng buồn thay, các kiểm tra tích hợp tự động của chúng tôi không tồn tại nhiều và trong khi chúng tôi đang sửa lỗi đó, chúng tôi gặp vấn đề trong lúc này).

Có những cách an toàn để giảm thiểu những vấn đề với những điều này? Có những lựa chọn khác tôi nên xem xét? Bạn đã có những trải nghiệm tồi tệ mà bạn muốn chia sẻ có thể giúp tôi giảm đau sau này chưa?

Các thay đổi cơ sở dữ liệu nên được xử lý như tất cả các thay đổi khác và được triển khai dưới dạng các tập lệnh như là một phần của việc triển khai (và tất nhiên được lưu trong kiểm soát nguồn). Vì chúng được triển khai với mã cho cùng một phiên bản ứng dụng, bạn biết chính xác những gì cần được khôi phục. Bạn có thể thích và viết một tập lệnh để hoàn tác mỗi thay đổi tại thời điểm bạn viết tập lệnh cơ sở dữ liệu nhưng nếu việc khôi phục không phổ biến, bạn có thể không muốn làm điều đó. Nếu một cột mới được điền, bạn sẽ mất dữ liệu nếu bạn quay lại cơ sở dữ liệu ban đầu.

Trong SQL Server, bạn có thể chụp ảnh ngay trước khi triển khai và sau đó quay lại ngay lập tức nếu việc triển khai thất bại. Điều này giả định rằng việc triển khai KHÔNG xảy ra khi người dùng ở trên hệ thống (bạn không muốn mất các thay đổi dữ liệu của họ). Điều này hữu ích nhất trong một phiên bản chính khi bạn có thể phải đưa toàn bộ hệ thống xuống tạm thời để thực hiện nâng cấp. Hoặc bạn vẫn có thể chụp ảnh nhanh và so sánh cơ sở dữ liệu giữa ảnh chụp nhanh và cơ sở dữ liệu để xem sự khác biệt nếu bạn cần quay lại. Một công cụ như SQLCompare thậm chí có thể tạo mã để quay lại cấu trúc ảnh chụp nhanh. Tôi không biết những gì có sẵn cho các cơ sở dữ liệu khác.

Thay đổi cấu trúc cơ sở dữ liệu nên được tự động / viết kịch bản và kiểm tra bằng môi trường kiểm tra. Thay đổi thủ công là quá rủi ro trên môi trường sản xuất

Chiến lược rollback hợp lý duy nhất (chiến lược có ít khả năng làm mọi thứ tồi tệ hơn) là quay lại ảnh chụp nhanh trước khi nâng cấp. Nếu mọi thứ sẽ đi sai, nó sẽ xảy ra nhanh chóng - đủ để khiến nó có thể quản lý để quay lại ảnh chụp nhanh hoặc quá muộn cho việc quay lại (báo cáo cuối tuần tiếp theo không thành công do sự cố trong cơ sở dữ liệu).

Các thay đổi có thể được thực hiện tăng dần (như thêm một trường) và do đó được thử nghiệm trực tiếp với ít rủi ro hơn so với khi thực hiện tất cả trong một lần.

Với kế hoạch, bạn có thể thay đổi cơ sở dữ liệu để hỗ trợ một số bản phát hành sắp tới, thay vì phải đối đầu với việc nâng cấp phần mềm và cơ sở dữ liệu với mỗi bản phát hành.

Hãy chuẩn bị ở chế độ khẩn cấp những ngày sau khi nâng cấp cơ sở dữ liệu, giống như bạn sẽ làm nếu đó là nâng cấp phần mềm.

Chống lại sự thôi thúc để vá các vấn đề bằng tay. Sử dụng chiến lược dự phòng của bạn (rollback, snapshot) và sau đó suy nghĩ về lý do tại sao mọi thứ đã sai trước khi thử nâng cấp lại.