Hướng dẫn cho người mới bắt đầu triển khai các thay đổi mô hình Django vào sản xuất

Bạn có thể tìm thấy nhiều bài viết trên internet về cách triển khai dự án Django lần đầu tiên vào sản xuất. Tuy nhiên, bạn nên làm gì khi dự án của bạn đã đi vào sản xuất và trong quá trình triển khai, bạn cần đảm bảo tính nhất quán của các hệ thống liên quan, đồng thời, tính liên tục của sản phẩm?

Sản xuất là gì?

Sản xuất là một tổ hợp phần mềm và phần cứng có sẵn cho người dùng cuối. Nó bao gồm các máy chủ, máy ảo và vùng chứa được cài đặt phần mềm ổn định.

Có nhiều yêu cầu cho sản xuất. Tuy nhiên, trong bài viết này, chúng tôi sẽ tập trung vào hiệu quả và tính liên tục.

Hiệu quả là sự đảm bảo rằng sản phẩm sẽ làm những gì nó phải làm.

Tính liên tục là sự đảm bảo cho công việc hiệu quả khi sử dụng sản phẩm này.

Nghĩa là, nếu một lần đăng nhập luôn trả về lỗi, điều này là thiếu hiệu quả. Tuy nhiên, nếu người dùng hiếm khi nhận được lỗi như vậy, thì đây là hành vi vi phạm tính liên tục.

Dữ liệu ban đầu

Một số vùng chứa, máy ảo hoặc máy chủ được sử dụng trong quá trình sản xuất tùy thuộc vào kiến trúc.

Tôi không xem xét tình huống khi chỉ có một quy trình đang hoạt động trên một máy chủ trong quá trình sản xuất vì nó tương tự như môi trường phát triển thông thường.

Sơ đồ sản xuất

Nói chung, bạn thường gặp sơ đồ với một số vùng chứa. Chúng được truy cập thông qua một bộ cân bằng. Có thể có nhiều hơn một bộ cân bằng. Từ các vùng chứa, một cơ sở dữ liệu được truy cập, nhưng có thể có một số cơ sở dữ liệu bao gồm phân đoạn và bản sao. Họ cũng có thể truy cập các nhà môi giới như Kafka và các dịch vụ khác. Các dịch vụ khác cũng có thể bằng cách nào đó trao đổi thông tin với các chương trình phụ trợ.

Thay đổi đồng thời trong mã và cơ sở dữ liệu

Ví dụ: chúng ta chỉ xem xét các thay đổi đối với mã và cơ sở dữ liệu.

Những thay đổi có thể được thực hiện trong mã để điều này ảnh hưởng đến cơ sở dữ liệu và ngược lại:

1. Thêm/xóa bảng.
2. Thêm/bớt cột.
3. Đổi tên cột hoặc bảng.
4. Thay đổi loại cột.
5. Thay đổi các thuộc tính (chỉ mục) của cột (NULL, duy nhất, mặc định).

Bạn cũng có thể thêm trình kích hoạt và chức năng, thay đổi lược đồ, v.v. Tuy nhiên, các cách tiếp cận chung để áp dụng điều này vào sản xuất được thể hiện trong chính những ví dụ này.

Ví dụ chi tiết

Nếu bạn cần thêm một mô hình (bảng) vào một ứng dụng cục bộ trong môi trường phát triển, thì bạn nên làm như sau:

1. Thêm một lớp vào mô hình Django.
2. Gọi lệnh: python manage.py makemigrations .
3. Sau đó: python manage.py migrate .
4. Và chỉ sau đó, khởi động lại ứng dụng.

Nhưng khi sản xuất, có nhiều phiên bản ứng dụng của bạn, git và một quy trình riêng để chạy di chuyển.

Bạn không thường xuyên có quyền truy cập trực tiếp vào Prod. Và điều này là tốt. Ví dụ, luồng có thể trông như thế này.

Trong sơ đồ như vậy, di chuyển được chạy trước. Sau đó, từng nhóm một được khởi động lại.

Trong một kiến trúc như vậy, luôn có thể xảy ra tình huống khi quá trình di chuyển đã được thực hiện nhưng mã sản xuất không thay đổi.

Sau đó, các vỏ đang được thay thế. Một số trường hợp có mã mới, một số có mã cũ.

Ngoài ra, nếu bạn thực hiện di chuyển khi quá trình thay thế nhóm hoàn tất, một tình huống khác sẽ xảy ra: mã trên máy chủ được cập nhật nhưng cơ sở dữ liệu thì không.

Cả hai tình huống ngụ ý một số khoảng thời gian khi cơ sở dữ liệu và mã không nhất quán.

May mắn thay, Django không kiểm tra tính nhất quán. Tuy nhiên, sự vắng mặt của các yếu tố cần thiết dẫn đến ngoại lệ.

Họ đang:

1. Sự hiện diện của một lớp trong mô hình trong mã, nhưng không có nó trong cơ sở dữ liệu
2. Sự hiện diện của một trường trong lớp trong mã, nhưng không có trường đó trong cơ sở dữ liệu
3. Tên khác nhau của bảng và cột trong mã và cơ sở dữ liệu
4. Các loại dữ liệu khác nhau trong mã và bảng
5. Các giá trị mặc định, NULL và các khác biệt khác, nếu sử dụng chúng
6. Những khác biệt khác mà cơ sở dữ liệu không mong đợi khi được truy cập từ mã

Các giải pháp

Di chuyển cần phải được thực hiện trước khi thay đổi mã khi điều này ngụ ý:

1. Thêm một bảng
2. Thêm một cột
3. Thêm khả năng chèn NULL vào trường

Di chuyển cần được thực hiện sau khi thay đổi mã khi điều này ngụ ý:

1. Xóa bảng
2. Loại bỏ một cột
3. Loại bỏ khả năng chèn NULL vào trường

Đổi tên được thực hiện trong một số bước:

1. Tạo một trường hoặc bảng mới
2. Thêm đồng bộ hóa trường hoặc bảng mới và cũ
3. Sao chép dữ liệu lịch sử nếu cần
4. Bắt đầu sử dụng một trường hoặc bảng mới
5. Xóa một trường hoặc bảng cũ cùng với đồng bộ hóa

Tất cả điều này có vẻ phức tạp. Nhưng nhìn vào các kế hoạch đưa ra ở trên. Khi sản xuất nhiều nhóm, trong quá trình triển khai, điều luôn xảy ra là một phần của mã hoạt động với lược đồ cơ sở dữ liệu cũ trong khi phần khác hoạt động với lược đồ cơ sở dữ liệu mới. Điều này có thể dẫn đến ngoại lệ.

Do đó, các thuật toán cơ bản để xử lý các mô hình Django không hoạt động khi sản xuất. Các thay đổi cần được triển khai theo nhiều bước tùy thuộc vào kiến trúc mã và luồng CI/CD được sử dụng trong một trường hợp cụ thể.

Tuy nhiên, khi thực hiện thay đổi, bạn luôn có thể được hướng dẫn bởi những gì mã mong đợi khi gửi yêu cầu đến cơ sở dữ liệu. Bên cạnh các trường hợp tiêu chuẩn, có thể có nhiều trường hợp ngoại lệ và trở ngại khác nhau đòi hỏi sự khéo léo để tìm ra cách giải quyết.

Trong các bài viết sắp tới, tôi sẽ mô tả chi tiết một số trường hợp được đề cập ở đây.