カスタマイズされたデータベースをアップグレード

特にデータベースにカスタムモジュールが含まれている場合、新しいバージョンの Odoo にアップグレードするのは難しい場合があります。 このページでは、カスタマイズされたモジュールでデータベースをアップグレードする技術的なプロセスを説明します。 カスタマイズされたモジュールなしでデータベースをアップグレードする方法については、 :doc:の Upgrade documentation </administration/upgrade> を参照してください。

Odoo の標準コードを拡張し、Studio アプリで構築されていない任意のモジュールをカスタムモジュールと考えます。 このようなモジュールをアップグレードする前、またはアップグレードを要求する前に、 :ref:の upgrade-sla を見て、誰がそのモジュールを担当しているか確認してください。

データベースの カスタムアップグレード と呼ばれるものに取り組んでいますが、アップグレードの目標に留意してください。

1. サポートを続ける

2. 最新の機能を取得する

3. パフォーマンスの向上をお楽しみください

4. 技術的な負債を減らす

5. セキュリティ改善のメリット

Odoo の新しいバージョンごとに変更が導入されます。これらの変更はカスタマイズが開発されたモジュールに影響を与える可能性があります。 これが、カスタムモジュールを含むデータベースをアップグレードするには、ソースコードをアップグレードするために追加の手順が必要な理由です。

以下は、カスタマイズされたデータベースをアップグレードするための手順です。

1. :ref:`開発を停止して <upgrade_custom/stop_developments> ` に挑戦します。

2. :ref:`アップグレードされたデータベース <upgrade_custom/request_upgrade> をリクエストします。

3. :ref:`空のデータベース <upgrade_custom/empty_database> `にモジュールをインストールできるようにします。

4. :ref:`アップグレードされたデータベース <upgrade_custom/upgraded_database> `にモジュールをインストール可能にします。

5. :ref:`広範囲にテストし、 <upgrade_custom/testing_rehearsal> `リハーサルを行います。

6. :ref:`本番データベース <upgrade_custom/production> ` をアップグレードします。

ステップ 1: 開発を停止

アップグレードを開始するには、コミットメントと開発リソースが必要です。 開発が同時に行われ続ける場合、それらを変更するたびに、それらの機能を再度アップグレードしてテストする必要があります。 このため、アップグレードプロセスを開始する際には、コードベースの完全なフリーズをお勧めします。 言うまでもなく、バグ修正はこの推奨事項から免除されます。

開発を停止したら、 開発を評価し、現在のバージョンとターゲットバージョンの間で導入された機能と比較するのは良い方法です。 可能な限り開発に挑戦し、機能的な回避策を見つけます。 あなたの開発と標準バージョンのOdooの間の冗長性を取り除くことは、簡単なアップグレードプロセスにつながり、技術的な負債を減らします。

注釈

バージョン間の変更については、 Release Notes を参照してください。

ステップ 2: アップグレードされたデータベースをリクエストする

カスタムモジュールの開発が中止され、実装された機能は冗長性と不要なコードを削除するように求められました。 次のステップはアップグレードされたテストデータベースを要求することです これを行うには、データベースのホスティングタイプに応じて、 アップグレードされたテストデータベースの取得 に記載されている手順に従います。

このステージの目的は、アップグレードされたデータベース内のカスタムモジュールを使い始めることではありません。 標準的なアップグレードプロセスがシームレスに機能しテストデータベースが正しく提供されるようにしました そうでない場合は、アップグレード要求に失敗します。 アップグレードのテストに関連するオプションを選択して、 support page 経由で Odoo の支援を要求します。

ステップ 3: データベースを空にする

アップグレードされたテストデータベースで作業する前に アップグレードの対象となるバージョンの空のデータベースでカスタム開発を行うことをお勧めします。 これにより、新しいバージョンの Odoo との互換性が確保され、新しい機能との動作やインタラクションを分析できます。 データベースをアップグレードする際に問題が発生しないことを保証します。

カスタムモジュールを空のデータベースで動作させることは、プロダクションデータベースに存在する可能性のある変更や誤った設定を回避するのに役立ちます (スタジオのカスタマイズなど)。 カスタマイズされたウェブサイトページ、電子メールテンプレートまたは翻訳)。 これらはカスタムモジュールと本質的に関連しておらず、アップグレードプロセスのこの段階で望ましくない問題を引き起こす可能性があります。

カスタムモジュールを空のデータベースで動作させるには、次の手順に従うことをお勧めします。

1. カスタムモジュールをインストール可能にする

2. テストと修正

3. コードを消去する

4. Make standard tests run successfully

カスタムモジュールをインストール可能にする

最初のステップは、新しいOdooバージョンにカスタムモジュールをインストールできるようにすることです。 これは、インストール中にトレースバックや警告がないことを確認することから始めることを意味します。 このために、カスタムモジュールを一つずつインストールしてください。 新しいOdooバージョンの空のデータベースで、そこから生じるトレースバックと警告を修正します。

このプロセスは、モジュールのインストール中に問題を検出するのに役立ちます。例:

• モジュールの依存関係が無効です。

• 構文 change: assets declaration, OWL update, attrs.

• 標準フィールド、モデル、ビューが存在しないか、名前を変更しました。

• ビューから移動または削除された Xpath

• メソッドの名前の変更または削除。

• ...

テストと修正

モジュールのインストール時にトレースバックがなくなったら、次のステップはそれらをテストすることです。 カスタムモジュールが空のデータベースにインストール可能であっても、実行中にエラーがないことを保証するものではありません。 このため、すべてのカスタマイズを徹底的にテストし、すべてが期待どおりに動作していることを確認することをお勧めします。

このプロセスは、モジュールのインストール中に特定されていないさらなる問題を検出するのに役立ち、ランタイムでのみ検出できます。 例えば、標準のPythonやOWL関数、標準のフィールドへの非存在の参照などへの非存在の呼び出しです。

すべてのカスタマイズ、特に次の要素をテストすることをお勧めします。

• ビュー

• メールテンプレート

• レポート

• サーバーアクションと自動アクション

• 標準ワークフローの変更

• 計算されたフィールド

また、テストの繰り返し時間を節約するために自動化されたテストを書くことをお勧めします。 テスト範囲を拡大し、導入された変更と修正が既存のフローを壊さないようにします。 カスタマイズにすでに実装されているテストがある場合。 それらが新しいOdooバージョンにアップグレードされていることを確認し、正常に実行される可能性のある問題を修正してください。

コードを消去する

この段階では、可能な限りコードをクリーンアップすることをお勧めします。これには以下が含まれます：

• 冗長で不要なコードを削除します。

• ステップ 1: 開発を停止 で説明されているように、Odoo 標準の一部である機能を削除します。

• 不要な場合はコメントしたコードをクリーンアップします。

• 必要に応じてコード(機能、フィールド、ビュー、レポートなど)をリファクタリングします。

標準テスト

前のステップが完了したら、カスタムモジュールの依存関係に関連付けられたすべての標準テストを確認することをお勧めします。 標準テストはコードロジックの検証を確実にし、データの破損を防ぎます。 これらはデータベースで作業する前にバグや不要な動作を特定するのに役立ちます。

標準的なテストに失敗した場合は、以下の理由を分析することをお勧めします。

• カスタマイズによって標準ワークフローが変更されます。標準テストをワークフローに適用します。

• カスタマイズは特別な流れを考慮しませんでした。カスタマイズを適応させて、すべての標準ワークフローで動作するようにします。

ステップ 4: アップグレードされたデータベース

カスタムモジュールがインストール可能になったら、空のデータベースで正しく動作します。 :ref:`upgraded database <upgrade-request-test> ` で動作させる時が来ました。

新しいバージョンでカスタムコードが正常に動作していることを確認するには、以下の手順に従ってください。

• データを移行

• カスタムモジュールをテスト

データを移行

During the upgrade of the custom modules, you might have to use upgrade scripts to reflect changes from the source code to their corresponding data. Together with the upgrade scripts, you can also make use of the ユーティリティのアップグレード and its helper functions.

• Any technical data that was renamed during the upgrade of the custom code (models, fields, external identifiers) should be renamed using upgrade scripts to avoid data loss during the module upgrade. See also: rename_field(), rename_model(), rename_xmlid().

• 新しいOdooバージョンのソースコードと標準アップグレードプロセス中にデータベースから削除された標準モデルからのデータは、まだ存在する場合、古いモデルテーブルから復元する必要があるかもしれません。

  Example

  モデルの sale.subscription のカスタムフィールドは、Odoo 15 から Odoo 16 に自動的に移行されません(モデルが sales にマージされた場合)。 この場合、アップグレードスクリプト上でSQLクエリを実行して、あるテーブルから別のテーブルにデータを移動することができます。 すべての列/フィールドが既に存在している必要があることを考慮してください。ですから、``post- スクリプト ( :ref:`upgrade-scripts/phases`を参照してください) でこれを行うことを検討してください。

  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
        """
     )
  

  スクリプトをアップグレード の詳細については、ドキュメントを確認してください。

アップグレードスクリプトを使用することもできます：

• アップグレードの処理時間を容易にします。 たとえば、SQL クエリを使用して、過剰なレコード数を持つモデルに計算された格納されたフィールドの値を格納します。

• 値の計算が変更された場合に備えてフィールドを再計算します。 recompute_fields() も参照してください。

• 不要なカスタムモジュールをアンインストールします。 remodule() も参照してください。

• 誤ったデータまたは設定が正しくありません。

アップグレードスクリプトの実行とテスト

Odoo OnlineOdoo.shOn-premise

Python ファイルを含むカスタムモジュールのインスタンス化は、Odoo Online データベースでは許可されていません。 このプラットフォームでアップグレードスクリプトを実行することはできません。

カスタムモジュールをテスト

アップグレードされたデータベースでカスタム モジュールが正しく動作するようにするには、それらもテストする必要があります。 これにより、データベースに保存されている標準データとカスタムデータの両方が一貫性があり、アップグレードプロセス中に失われることはありませんでした。

注意を払うべき事:

• 動作していないビュー: アップグレード中に、コンテンツによってビューが問題を引き起こすと、無効になります。 無効化されたビューの情報は、format@@0レポートで確認できます。 このビューを再度有効にする必要があります(もしくは、もう役に立たない場合は削除する必要があります)。これを実現するためには、スクリプトをアップグレードすることをお勧めします。

• Module data not updated: Custom records that have the noupdate flag are not updated when upgrading the module in the new database. For the custom data that needs to be updated due to changes in the new version, we recommend to use upgrade scripts to do so. See also: update_record_from_xml().

ステップ 5: テストとリハーサルを行う

アップグレードされたデータベースでカスタムモジュールが正常に動作する場合 データベースの使いやすさを評価し、以前のテストで気付かれなかった可能性のある問題を検出するために、別のテストを行うことが重要です。 アップグレードされたデータベースのテストの詳細については、 データベースの新しいバージョンをテストする を参照してください。

本番データベースのアップグレード で述べたように、標準的なアップグレードスクリプトとデータベースは常に進化しています。 したがって、アップグレードされた新しいテストデータベースを頻繁に要求し、アップグレードプロセスが成功することを確認することを強くお勧めします。

それに加えて 本番データベースをアップグレードする前日に、アップグレードプロセスの完全なリハーサルを行い、アップグレード中に望ましくない動作を避け、移行されたデータで発生した可能性のある問題を検出する。

ステップ 6: 本番環境のアップグレード

プロダクションデータベースのアップグレードに自信を持ったら、データベースのホスティングタイプに応じて、 本番データベースのアップグレード に記載されているプロセスに従ってください。