Nâng cấp một cơ sở dữ liệu đã tùy chỉnh

Upgrading to a new version of Odoo can be challenging, especially if the database you work on contains custom modules. This page intent is to explain the technical process of upgrading a database with customized modules. Refer to the Upgrade documentation for guidance on how to upgrade a database without customized modules.

Chúng ta coi một module tùy chỉnh là bất kỳ module nào mở rộng code chuẩn của Odoo và không được xây dựng bằng ứng dụng Studio. Trước khi nâng cấp một module như vậy, hoặc trước khi yêu cầu nâng cấp nó, hãy xem qua upgrade-sla để chắc chắn ai là người chịu trách nhiệm cho nó.

Trong khi thực hiện điều mà chúng ta gọi là nâng cấp tùy chỉnh (custom upgrade) cho cơ sở dữ liệu của bạn, hãy ghi nhớ các mục tiêu của việc nâng cấp:

1. Tiếp tục được hỗ trợ

2. Có được các tính năng mới nhất

3. Tận hưởng cải thiện hiệu suất

4. Giảm nợ kỹ thuật (technical debt)

5. Hưởng lợi từ các cải thiện bảo mật

Mỗi phiên bản mới của Odoo đều mang đến những thay đổi. Những thay đổi này có thể ảnh hưởng đến các module đã được phát triển tùy chỉnh trên đó. Đây là lý do vì sao việc nâng cấp một cơ sở dữ liệu chứa các module tùy chỉnh đòi hỏi thêm các bước để nâng cấp mã nguồn.

Đây là các bước cần thực hiện để nâng cấp các cơ sở dữ liệu đã được tùy chỉnh:

1. Dừng việc phát triển và xem xét lại chúng.

2. Yêu cầu một cơ sở dữ liệu đã được nâng cấp.

3. Làm cho module của bạn có thể cài đặt được trên một cơ sở dữ liệu trống.

4. Làm cho module của bạn có thể cài đặt được trên cơ sở dữ liệu đã nâng cấp.

5. Kiểm thử kỹ lưỡng và thực hiện một buổi diễn tập.

6. Nâng cấp cơ sở dữ liệu production.

Bước 1: Dừng việc phát triển

Bắt đầu một cuộc nâng cấp đòi hỏi sự cam kết và nguồn lực phát triển. Nếu việc phát triển vẫn tiếp tục diễn ra song song, các tính năng đó sẽ cần được nâng cấp và kiểm thử lại mỗi lần bạn thay đổi chúng. Đây là lý do chúng tôi khuyến nghị đóng băng hoàn toàn codebase khi bắt đầu quá trình nâng cấp. Tất nhiên, việc sửa lỗi (bug fixing) được miễn trừ khỏi khuyến nghị này.

Sau khi đã dừng việc phát triển, đây là thời điểm tốt để đánh giá lại những gì đã phát triển và so sánh chúng với các tính năng được giới thiệu giữa phiên bản hiện tại của bạn và phiên bản mục tiêu. Hãy xem xét lại các phần phát triển càng nhiều càng tốt và tìm các giải pháp thay thế về mặt chức năng. Việc loại bỏ sự trùng lặp giữa các phần phát triển của bạn và phiên bản chuẩn của Odoo sẽ giúp quá trình nâng cấp dễ dàng hơn và giảm nợ kỹ thuật.

Ghi chú

Bạn có thể tìm thông tin về những thay đổi giữa các phiên bản trong Release Notes.

Bước 2: Yêu cầu một cơ sở dữ liệu đã được nâng cấp

Sau khi việc phát triển các module tùy chỉnh đã dừng lại và các tính năng đã triển khai được xem xét lại để loại bỏ sự trùng lặp và code không cần thiết, bước tiếp theo là yêu cầu một cơ sở dữ liệu kiểm thử đã được nâng cấp. Để làm điều đó, hãy làm theo các bước được đề cập trong upgrade-request-test, tùy theo loại hosting của cơ sở dữ liệu bạn.

Mục đích của giai đoạn này không phải là bắt đầu làm việc với các module tùy chỉnh trong cơ sở dữ liệu đã nâng cấp, mà là để đảm bảo quá trình nâng cấp chuẩn hoạt động suôn sẻ và cơ sở dữ liệu kiểm thử được cung cấp đúng cách. Nếu không phải như vậy, và yêu cầu nâng cấp thất bại, hãy yêu cầu sự hỗ trợ từ Odoo qua trang hỗ trợ bằng cách chọn tùy chọn liên quan đến việc kiểm thử nâng cấp.

Bước 3: Cơ sở dữ liệu trống

Trước khi làm việc trên một cơ sở dữ liệu kiểm thử đã nâng cấp, chúng tôi khuyến nghị làm cho các phần phát triển tùy chỉnh hoạt động được trên một cơ sở dữ liệu trống ở phiên bản mục tiêu của bạn. Điều này đảm bảo rằng phần tùy chỉnh tương thích với phiên bản Odoo mới, cho phép phân tích cách nó hoạt động và tương tác với các tính năng mới, và đảm bảo rằng chúng sẽ không gây ra vấn đề gì khi nâng cấp cơ sở dữ liệu.

Việc làm cho các module tùy chỉnh hoạt động được trên một cơ sở dữ liệu trống cũng giúp tránh những thay đổi và cấu hình sai có thể tồn tại trong cơ sở dữ liệu production (như tùy chỉnh studio, các trang website được tùy chỉnh, mẫu email hoặc bản dịch). Những thứ này về bản chất không liên quan đến các module tùy chỉnh và có thể gây ra các vấn đề không mong muốn ở giai đoạn này của quá trình nâng cấp.

Để làm cho các module tùy chỉnh hoạt động được trên một cơ sở dữ liệu trống, chúng tôi khuyên bạn nên làm theo các bước sau:

1. Làm cho các module tùy chỉnh có thể cài đặt được

2. Kiểm thử và sửa lỗi

3. Dọn dẹp code

4. Làm cho các bài test chuẩn chạy thành công

Làm cho các module tùy chỉnh có thể cài đặt được

Bước đầu tiên là làm cho các module tùy chỉnh có thể cài đặt được trên phiên bản Odoo mới. Điều này có nghĩa là bắt đầu bằng việc đảm bảo không có traceback hay cảnh báo nào trong quá trình cài đặt chúng. Để làm điều này, hãy cài đặt lần lượt từng module tùy chỉnh trên một cơ sở dữ liệu trống ở phiên bản Odoo mới, và sửa các traceback cũng như cảnh báo phát sinh từ đó.

Quá trình này sẽ giúp phát hiện các vấn đề trong quá trình cài đặt module. Ví dụ:

• Phụ thuộc module không hợp lệ.

• Thay đổi cú pháp: khai báo assets, cập nhật OWL, attrs.

• Tham chiếu đến các field, model, view chuẩn không còn tồn tại hoặc đã bị đổi tên.

• Xpath đã bị di chuyển hoặc bị xóa khỏi các view.

• Các phương thức bị đổi tên hoặc bị xóa.

• ...

Kiểm thử và sửa lỗi

Sau khi không còn traceback nào khi cài đặt các module, bước tiếp theo là kiểm thử chúng. Ngay cả khi các module tùy chỉnh có thể cài đặt được trên một cơ sở dữ liệu trống, điều đó không đảm bảo rằng không có lỗi trong quá trình chúng thực thi. Vì vậy, chúng tôi khuyến khích kiểm thử kỹ lưỡng tất cả các phần tùy chỉnh để đảm bảo mọi thứ hoạt động như mong đợi.

Quá trình này sẽ giúp phát hiện thêm các vấn đề không được xác định trong quá trình cài đặt module và chỉ có thể phát hiện được lúc chạy (runtime). Ví dụ: các lời gọi đã bị loại bỏ (deprecated) đến các hàm python hoặc OWL chuẩn, tham chiếu đến các field chuẩn không còn tồn tại, v.v.

Chúng tôi khuyến nghị kiểm thử toàn bộ phần tùy chỉnh, đặc biệt là các thành phần sau:

• View

• Mẫu email

• Báo cáo

• Hành động server (server actions) và hành động tự động (automated actions)

• Thay đổi trong các quy trình làm việc (workflow) chuẩn

• Các field tính toán (computed fields)

Chúng tôi cũng khuyến khích viết các bài test tự động để tiết kiệm thời gian trong các vòng lặp kiểm thử, tăng độ bao phủ kiểm thử (test coverage), và đảm bảo rằng các thay đổi và bản sửa lỗi được đưa vào không phá vỡ các luồng hiện có. Nếu đã có các bài test được triển khai trong phần tùy chỉnh, hãy đảm bảo chúng được nâng cấp lên phiên bản Odoo mới và chạy thành công, đồng thời sửa các vấn đề có thể tồn tại.

Dọn dẹp code

Ở giai đoạn này của quá trình nâng cấp, chúng tôi cũng đề xuất dọn dẹp code càng nhiều càng tốt. Việc này bao gồm:

• Loại bỏ code dư thừa và không cần thiết.

• Loại bỏ các tính năng hiện đã trở thành một phần của Odoo chuẩn, như được mô tả trong Bước 1: Dừng việc phát triển.

• Dọn dẹp code đã bị comment nếu không còn cần thiết nữa.

• Tái cấu trúc (refactor) code (hàm, field, view, báo cáo, v.v.) nếu cần.

Các bài test chuẩn

Sau khi hoàn tất các bước trước đó, chúng tôi khuyên bạn nên đảm bảo tất cả các bài test chuẩn liên quan đến các phụ thuộc của module tùy chỉnh đều vượt qua. Các bài test chuẩn đảm bảo tính hợp lệ của logic code và ngăn chặn dữ liệu bị hỏng. Chúng sẽ giúp bạn phát hiện các lỗi hoặc hành vi không mong muốn trước khi bạn làm việc trên cơ sở dữ liệu của mình.

Trong trường hợp có bài test chuẩn bị lỗi, chúng tôi đề xuất phân tích lý do khiến chúng thất bại:

• Phần tùy chỉnh làm thay đổi quy trình chuẩn: Hãy điều chỉnh bài test chuẩn theo quy trình của bạn.

• Phần tùy chỉnh chưa tính đến một luồng đặc biệt nào đó: Hãy điều chỉnh phần tùy chỉnh của bạn để đảm bảo nó hoạt động được với tất cả các quy trình chuẩn.

Bước 4: Cơ sở dữ liệu đã nâng cấp

Sau khi các module tùy chỉnh có thể cài đặt được và hoạt động đúng cách trên một cơ sở dữ liệu trống, đã đến lúc làm cho chúng hoạt động được trên một cơ sở dữ liệu đã nâng cấp.

Để đảm bảo code tùy chỉnh hoạt động hoàn hảo trên phiên bản mới, hãy làm theo các bước sau:

• Di chuyển dữ liệu

• Kiểm thử các module tùy chỉnh

Di chuyển dữ liệu

Trong quá trình nâng cấp các module tùy chỉnh, bạn có thể phải sử dụng upgrade scripts để phản ánh các thay đổi từ mã nguồn vào dữ liệu tương ứng của chúng. Cùng với các upgrade script, bạn cũng có thể sử dụng Upgrade utils và các hàm hỗ trợ của nó.

• Bất kỳ dữ liệu kỹ thuật nào đã bị đổi tên trong quá trình nâng cấp code tùy chỉnh (model, field, external identifier) đều nên được đổi tên bằng cách sử dụng upgrade script để tránh mất dữ liệu trong quá trình nâng cấp module. Xem thêm: rename_field(), rename_model(), rename_xmlid().

• Dữ liệu từ các model chuẩn đã bị xóa khỏi mã nguồn của phiên bản Odoo mới hơn và khỏi cơ sở dữ liệu trong quá trình nâng cấp chuẩn có thể cần được khôi phục từ bảng model cũ, nếu bảng đó vẫn còn tồn tại.

  Example

  Các field tùy chỉnh cho model sale.subscription không được tự động di chuyển từ Odoo 15 sang Odoo 16 (khi model này được hợp nhất vào sale.order). Trong trường hợp này, một truy vấn SQL có thể được thực thi trong một upgrade script để chuyển dữ liệu từ bảng này sang bảng khác. Lưu ý rằng tất cả các cột/field phải đã tồn tại sẵn, vì vậy hãy cân nhắc thực hiện việc này trong một script post- (Xem Phases of upgrade scripts).

  Spoiler

  def migrate(cr, version):
     cr.execute(
        """
        UPDATE sale_order so
           SET custom_field = ss.custom_field
          FROM sale_subscription ss
         WHERE ss.new_sale_order_id = so.id
        """
     )
  

  Kiểm tra tài liệu để biết thêm thông tin về Upgrade scripts.

Upgrade script cũng có thể được sử dụng để:

• Giảm thời gian xử lý của một cuộc nâng cấp. Ví dụ, để lưu trữ giá trị của các field tính toán được lưu trữ (computed stored field) trên các model có số lượng bản ghi quá lớn bằng cách sử dụng truy vấn SQL.

• Tính toán lại các field trong trường hợp cách tính giá trị của chúng đã thay đổi. Xem thêm recompute_fields().

• Gỡ cài đặt các module tùy chỉnh không mong muốn. Xem thêm remove_module().

• Sửa chữa dữ liệu lỗi hoặc cấu hình sai.

Chạy và kiểm thử upgrade script

Odoo OnlineOdoo.shOn-premise

Vì việc cài đặt các module tùy chỉnh chứa file Python không được phép trên các cơ sở dữ liệu Odoo Online, nên không thể chạy các upgrade script trên nền tảng này.

Kiểm thử các module tùy chỉnh

Để đảm bảo các module tùy chỉnh hoạt động đúng với dữ liệu của bạn trong cơ sở dữ liệu đã nâng cấp, chúng cũng cần được kiểm thử. Điều này giúp đảm bảo cả dữ liệu chuẩn lẫn dữ liệu tùy chỉnh được lưu trữ trong cơ sở dữ liệu đều nhất quán và không có gì bị mất trong quá trình nâng cấp.

Những điều cần chú ý:

• View không hoạt động: Trong quá trình nâng cấp, nếu một view gây ra sự cố vì nội dung của nó, view đó sẽ bị vô hiệu hóa. Bạn có thể tìm thông tin về các view bị vô hiệu hóa trong báo cáo nâng cấp (Upgrade report). View này cần được kích hoạt lại (hoặc xóa bỏ nếu không còn hữu ích nữa). Để thực hiện việc này, chúng tôi khuyến nghị sử dụng upgrade script.

• Dữ liệu module không được cập nhật: Các bản ghi tùy chỉnh có cờ noupdate sẽ không được cập nhật khi nâng cấp module trong cơ sở dữ liệu mới. Đối với dữ liệu tùy chỉnh cần được cập nhật do các thay đổi trong phiên bản mới, chúng tôi khuyến nghị sử dụng upgrade script để làm việc đó. Xem thêm: update_record_from_xml().

Bước 5: Kiểm thử và diễn tập

Khi các module tùy chỉnh hoạt động đúng trong cơ sở dữ liệu đã nâng cấp, việc thực hiện thêm một vòng kiểm thử nữa là rất quan trọng để đánh giá khả năng sử dụng của cơ sở dữ liệu và phát hiện bất kỳ vấn đề nào có thể đã bị bỏ sót trong các lần kiểm thử trước. Để biết thêm thông tin về việc kiểm thử cơ sở dữ liệu đã nâng cấp, hãy xem upgrade-testing.

Như đã đề cập trong upgrade-production, cả các upgrade script chuẩn lẫn cơ sở dữ liệu của bạn đều liên tục thay đổi. Do đó, chúng tôi khuyến nghị mạnh mẽ rằng bạn nên thường xuyên yêu cầu các cơ sở dữ liệu kiểm thử đã nâng cấp mới và đảm bảo quá trình nâng cấp vẫn thành công.

Bên cạnh đó, hãy thực hiện một buổi diễn tập đầy đủ cho quá trình nâng cấp vào ngày trước khi nâng cấp cơ sở dữ liệu production, để tránh các hành vi không mong muốn trong quá trình nâng cấp và để phát hiện bất kỳ vấn đề nào có thể đã xảy ra với dữ liệu đã di chuyển.

Bước 6: Nâng cấp production

Khi bạn đã tự tin về việc nâng cấp cơ sở dữ liệu production của mình, hãy làm theo quy trình được mô tả trong upgrade-production, tùy theo loại hosting của cơ sở dữ liệu bạn.