ブランチ

概要

ブランチビューでは、リポジトリが持つさまざまなブランチの概要を確認できます。

ステージ

Odoo.shは、ブランチ用にプロダクト、ステージング、開発の3つの異なるステージを提供しています。

ステージセクションのタイトルにドラッグ＆ドロップすることで、ブランチのステージを変更することができます。

製造

これは、プロダクションデータベースが稼働するコードを保持するブランチです。プロダクションブランチは1つだけです。

このブランチに新しいコミットをプッシュすると、プロダクションサーバが新しいリビジョンのコードで更新され、再起動されます。

フォームビューの変更など、変更によってモジュールの更新が必要となり、自動的に実行させたい場合は、マニフェスト (__manifest__.py) 内のモジュールのバージョン番号を上げてください。プラットフォームが更新を実行し、その間、メンテナンスのため一時的にインスタンスが利用できなくなります。

この方法は、アプリメニューからモジュールのアップグレードを行うか、またはコマンドラインの -u スイッチを使用する方法と同等です。</developer/reference/cli>` 。

コミットの変更によりサーバの再起動が不可能になった場合、またはモジュールの更新に失敗した場合、サーバは自動的に以前の正常なコードリビジョンに戻され、データベースは更新前の状態にロールバックされます。失敗した更新のログには引き続きアクセスできるため、トラブルシューティングが可能です。

デモデータは、本番データベースで使用されることを想定していないため、読み込まれません。ユニットテストは、更新中に本番データベースの使用不可時間が長くなるため、実行されません。

トライアルプロジェクトを利用している取引先は、本番ブランチと全てのステージングブランチが30日後に自動的に開発段階に戻されることに注意して下さい。

ステージング

ステージングブランチは、実際の本番データベースをテスト記録で損なうことなく、本番データを使用して新機能をテストすることを目的としています。ステージングブランチでは、本番データベースの複製を無効化したデータベースが作成されます。

無効化には以下が含まれます:

• スケジュールされたアクションを無効にします。テストを行いたい場合は、手動でアクションをトリガするか、または再度有効にすることができます。リソースを節約するために、データベースを使用するオーダがない場合は、プラットフォームがアクションをトリガする頻度が低くなることにご注意下さい。

• メールキャッチャーでメールを傍受して、送信メールを無効にします。データベースから送信されたEメールを確認するための インターフェース が提供されています。そのため、連絡先にテストメールを送信する必要はありません。

• 決済プロバイダーと配送プロバイダーをテストモードに設定します。

• IAPサービスの無効化

最新のデータベースは無期限で維持されますが、同じブランチにある古いデータベースは、新しいデータベースのスペースを確保するためにガベージコレクションの対象となる場合があります。 3か月間は有効ですが、その後はブランチを再構築する必要があります。 これらのデータベースで設定やビューの変更を行う場合は、ドキュメントを作成するか、デフォルトの設定やビューを上書きするXMLデータファイルを使用して、ブランチのモジュールに直接書き込んで下さい。

Odooでは現在、本番データベースに読み込まれていないデモデータに依存しているため、ユニットテストは実行されていません。将来的に、Odooがデモデータなしでユニットテストを実行できるようになれば、Odoo.shはステージングデータベース上でテストを実行することを検討します。

開発

開発ブランチでは、ユニットテストを実行するために、デモデータを使用して新しいデータベースが作成されます。インストールされたモジュールは、ブランチに含まれているものです。インストールするモジュールのリストを プロジェクト設定 で変更することができます。

これらのブランチのいずれかに新しいコミットをプッシュすると、ゼロから作成されたデータベースとブランチの新しいリビジョンとともに、新しいサーバが起動します。デモデータが読み込まれ、デフォルトでユニットテストが実行されます。これにより、変更によってテストされた機能が壊れていないことが確認されます。必要に応じて、 ブランチ設定 でテストを無効にしたり、特定のテストをカスタムタグとともに実行したりすることができます。

ブランチのステージングと同様に、Eメールは送信されず、メールキャッチャーによって傍受されます。また、データベースが使用されていない限り、スケジュールされたアクションはトリガされません。

開発用ブランチ用に作成されたデータベースは、3日間程度は存続する予定です。その後は、事前の通知なく、新しいデータベース用の領域を確保するために、自動的にガベージコレクションが実行される場合があります。

ブランチをマージする

ドラッグ＆ドロップで簡単にブランチをマージできます。

開発ブランチの変更を本番データでテストしたい場合、次のいずれかの方法をとることができます:

• 開発ブランチをステージングブランチにマージするには、目的のステージングブランチにドラッグ＆ドロップします。

• 開発ブランチをステージングセクションのタイトルにドラッグ＆ドロップすると、ステージングブランチになります。

最新の変更が本番環境で使用できる状態になったら、ステージングブランチを本番ブランチにドラッグ＆ドロップして、本番環境に最新の機能をマージし、デプロイすることができます。

大胆な方法として、開発ブランチをプロダクションブランチにマージすることもできます。これは、ステージングブランチを介したプロダクションデータでの変更の検証をスキップするということです。

開発用のブランチを互いにマージし、ステージング用のブランチを互いにマージすることができます。

もちろん、ワークステーションで直接 git merge を使用して、ブランチをマージすることもできます。新しいリビジョンがブランチにプッシュされると、Odoo.sh に通知が送信されます。

ステージングブランチを本番ブランチにマージしても、ソースコードのみがマージされます。ステージングデータベースで設定変更を行っても、その変更は本番データベースには反映されません。

設定変更をステージングブランチでテストし、本番環境に適用したい場合は、次のいずれかの方法を取る必要があります:

• XMLデータファイルに設定変更を書き込み、デフォルトの設定または支店内のビューを上書きし、その後、ステージングブランチをプロダクションブランチにマージした際にモジュールの更新をトリガするために、マニフェスト (__manifest__.py) 内のモジュールのバージョンを上げます。これは、Gitのバージョン管理機能を使用して設定変更を全て行うため、変更の追跡が可能となり、開発の拡張性を向上させるためのベストプラクティスです。

• ステージングから本番のデータベースに、コピー＆ペーストで手動で転送します。

タブ

履歴

ブランチ履歴の概要:

• コミットのメッセージと作成者、

• ステージ変更、データベースのインポート、バックアップの復元など、プラットフォームに関連するさまざまなイベント。

各イベントについて、ステータスが右上に表示されます。データベース上で実行中のオペレーション(インストール、アップデート、バックアップのインポートなど)に関する情報、またはその結果(テストのフィードバック、バックアップのインポート成功など)を提供します。オペレーションが成功した場合、接続 ボタンによりデータベースにアクセスできます。

メール

このタブにはメールキャッチャーが含まれています。データベースから送信されたEメールの概要が表示されます。メールキャッチャーは、開発およびステージング用のブランチで利用できます。本番データベースのEメールは、実際に送信されるため、傍受されることはありません。

シェル

シェルがコンテナにアクセスします。基本的なLinuxコマンド (ls, top) を実行したり、psql と入力してデータベース上でシェルを開いたりすることができます。

複数のタブを開き、ドラッグ＆ドロップで並べ替えることで、左右に並べるなど、好きなレイアウトに変更することができます。

注釈

長時間稼働するシェルインスタンスは保証されません。アイドル状態のシェルは、リソースを解放するためにいつでも切断される可能性があります。

エディター

ソースコードを編集するためのオンライン統合開発環境(IDE)です。ターミナル、Pythonコンソール、さらにはOdooシェルコンソールを開くこともできます。

複数のタブを開き、ドラッグ＆ドロップで並べ替えることで、左右に並べるなど、好きなレイアウトに変更することができます。

モニタリング

このリンクには、現在のビルドのさまざまなモニタリング指標が含まれています。

各グラフでは、ズーム、時間範囲の変更、特定のメトリックの選択が可能です。 グラフ上の注釈により、ビルド上の変更(データベースのインポート、gitのプッシュなど)との関連付けが容易になります。

ログ

サーバログを閲覧するビューア

さまざまなログが利用可能です:

• install.log: データベースのインストールログです。開発ブランチでは、テストのログも含まれます。

• pip.log: Python 依存関係のインストールログ。

• odoo.log: 実行中のサーバのログ。

• update.log: データベース更新のログです。

• pg_long_queries.log: 異常に長い時間を要した psql クエリのログ。

ログに新しい明細が追加された場合、それらは自動的に表示されます。一番下までスクロールすると、新しい明細が追加されるたびにブラウザが自動的にスクロールします。

ビューの右上にある該当するボタンをクリックすることで、ログの取得を一時停止することができます。取得は5分後に自動的に停止します。再生ボタンを使用して取得を再開することができます。

バックアップ

ダウンロードと復元が可能なバックアップのリスト、手動バックアップの実行とデータベースのインポート機能。

Odoo.shはプロダクトデータベースの日次バックアップを作成しています。日次バックアップを7つ、週次バックアップを4つ、月次バックアップを3つ保持しています。各バックアップには、データベースダンプ、ファイルストア(添付ファイル、バイナリフィールド) 、ログ、セッションが含まれています。

ステージングおよび開発データベースはバックアップされません。ただし、テスト目的で本番データベースのバックアップをステージングブランチに復元したり、本番データベースから誤って削除されたデータを手動で復元したりすることは可能です。

このリストには、あなたの本番データベースがホストされているサーバに保存されているバックアップが含まれています。このサーバには、7日次バックアップと4週次バックアップの1か月分のみが保存されています。

専用バックアップサーバには、同じバックアップに加え、月次バックアップが3つ追加されています。これらの月次バックアップを復元またはダウンロードするには、こちらまでご連絡ください。

1つまたは複数のモジュール（__manifest__.py）のバージョン、またはリンクされたPython依存関係(requirements.txt) を更新するコミットをマージすると、Odoo.shが自動的にバックアップを実行します(リストに更新タイプとしてフラグ付けされます)。新しいpipパッケージのインストールによってコンテナが変更されるか、またはモジュール更新のトリガによってデータベース自体が変更されるためです。この2つのケースでは、何かが壊れる可能性があるため、バックアップを行います。

前述の修正を行わずに、コードの一部のみを変更するコミットをマージした場合、コンテナもデータベースも変更されないため、Odoo.shによるバックアップは実行されません。プラットフォームでは、この変更は安全であるとみなされます。もちろん、万が一に備えて、プロダクトソースに大きな変更を加える前に手動でバックアップを作成しておくこともできます(手動バックアップは約1週間有効です)。悪用を避けるため、手動バックアップは1日あたり5回までとさせていただきます。

インポートデータベース 機能では、指定のフォーマットによるデータベースアーカイブを受け入れます:

• Odooの標準データベースマネジャー(オンプレミスのOdooサーバで利用可能 /web/database/manager)

• Odooオンラインデータベースマネジャー、

• この バックアップ タブのOdoo.shバックアップダウンロードボタンをクリックします。

• ビルドビューのOdoo.shダンプダウンロードボタン.

アップグレード

有効なプロジェクトのためのプロダクションおよびステージングブランチで利用可能です。

参考

アップグレードドキュメンテーション

管理設定

ここでは、現在選択されているブランチにのみ適用される設定をいくつか見つけることができます。

新しいコミット時の動作

開発ブランチとステージングブランチでは、新しいコミットを受け取った際の動作を変更することができます。デフォルトでは、開発ブランチでは新しいビルドが作成され、ステージングブランチでは前のビルドが更新されます (本番ステージ を参照) 。これは、作業中の機能が特定の設定や構成を必要とする場合に特に役立ちます。コミットのたびに手動で設定を再度行う必要がなくなります。ステージングブランチに新しいビルドを選択すると、コミットがプッシュされるたびにプロダクションビルドから新しいコピーが作成されます。ステージングから開発に戻されたブランチは自動的に '何もしない ' に設定されます。

モジュールインスタレーション

開発ビルド用に自動インストールするモジュールを選択して下さい。

• 自分のモジュールのみインストール を選択すると、そのブランチのモジュールのみがインストールされます。サブモジュール が除外されます。

• フルインストール (全モジュール) は、ブランチのモジュール、サブモジュールに含まれるモジュール、Odooの全ての標準モジュールをインストールします。フルインストールを実行すると、テストスイートが無効になります。

• モジュール一覧をインストール すると、このオプションのすぐ下の入力で指定されたモジュールがインストールされます。モジュール名は技術設定名であり、カンマで区切らなければなりません。

テストが有効になっている場合、標準の Odoo モジュールスイートは最大 1 時間かかる場合があります。この設定は開発ビルドのみに適用されます。ステージングビルドはプロダクションビルドを複製し、プロダクションビルドはベースのみをインストールします。

テストスイート

開発ブランチでは、テストスイートの有効化または無効化を選択できます。デフォルトでは有効になっています。テストスイートを有効にした場合、テストタグ:ref:test tags <developer/reference/testing/selection> を指定して制限することができます。

Odooバージョン

開発用ブランチのみ、Odooのバージョンを変更することができます。運用中のデータベースを新しいバージョンにアップグレードしている最中に、アップグレードされたコードをテストしたり、機能を開発したりしたい場合です。

さらに、各バージョンについて、コードの更新に関しては2つのオプションがあります。

• 最新のバグ修正、セキュリティ修正、パフォーマンス修正を自動的に適用するオプションを選択できます。Odooサーバのソースは週次で更新されます。これが '最新' オプションです。

• 日付のリストから選択することで、Odooソースを特定のリビジョンに固定することができます。リビジョンは3か月後に使用期限が切れます。使用期限が近づくとメールで通知が届きます。その後、何も操作を行わない場合、自動的に最新のバージョンに更新されます。

カスタムドメイン

ここでは、選択した支店に追加のドメインを設定することができます。 <name>.odoo.com ドメインまたは独自のカスタムドメインを追加することができます。 後者の場合は、次の操作が必要です:

• ドメイン名を所有または購買する、

• このリストにドメイン名を追加します、

• レジストラのドメイン名マネジャーで、本番データベースのドメイン名に ``CNAME` レコードを設定してドメイン名を設定します。

例えば、www.mycompany.com を mycompany.odoo.com というデータベースに関連付けるには、

• Odoo.shで、プロジェクト設定のカスタムドメインに www.mycompany.com を追加します。

• ドメイン名マネジャ (例：godaddy.com、gandi.net、ovh.com) で、www.mycompany.com を CNAME レコードとして設定し、値として mycompany.odoo.com を指定します。

ベアドメイン (例 mycompany.com) は受け付けられません:

• これらは A レコードを使用してのみ設定できます。

• これらは` A` レコードを使用してのみ設定できます。

• データベースのIPアドレスは、アップグレード、ハードウェアの故障、またはデータベースを別の国や大陸でホストしたいという希望により、変更される可能性があります。

そのため、IPアドレスが変更されたことにより、ベアドメインが突然機能しなくなる可能性があります。

さらに、mycompany.com と www.mycompany.com の両方をデータベースで動作させたい場合、最初のものを2番目のものにリダイレクトさせることは、 `SEOのベストプラクティス<https://support.google.com/webmasters/answer/7451184?hl=en>_ (ドキュメントに到達するためのURLのバージョンを1つ提供する) で、1つの主要なURLを持つために必要です。したがって、mycompany.com を www.mycompany.com にリダイレクトするように設定するだけでよいのです。ほとんどのドメインマネジャーには、このリダイレクトを設定する機能があります。これは一般的にウェブリダイレクトと呼ばれています。

HTTPS/SSL

リダイレクトが正しく設定されていれば、プラットフォームは1時間以内に Let's Encrypt によるSSL証明書を自動的に生成し、ドメインはHTTPSでアクセス可能になります。

現在、Odoo.shプラットフォーム上で独自のSSL証明書を設定することはできませんが、十分な需要があれば、この機能の追加を検討します。

SPFおよびDKIM準拠

ユーザのEメールアドレスのドメインが SPF (Sender Policy Framework) または DKIM (DomainKeys Identified Mail) を使用している場合は、送信するEメールの到達率を高めるために、ドメイン名の設定で Odoo を送信ホストとして承認することを忘れないで下さい。設定手順については、SPF および DKIM についてのドキュメンテーションで説明されています。

警告

Odooを送信ホストとして承認するようにSPFまたはDKIMを設定し忘れると、連絡先の受信トレイにEメールがスパムとして配信される可能性があります。

シェルコマンド

ビューの右上隅にある様々なシェルコマンドが利用できます。

各コマンドは、ターミナルで使用するためにクリップボードにコピーすることができ、そのうちのいくつかは、Odoo.shから *実行*ボタンをクリックすることで 直接使用することができます。このような場合、ポップアップがユーザに <URL>, <PATH>, のような最終的なプレースホルダを定義するよう促します。

クロン

Git リポジトリをダウンロードします。

$ git clone --recurse-submodules --branch master git@github.com:odoo/odoo.git

リポジトリ odoo/odoo を複製します。

• --recurse-submodules: リポジトリのサブモジュールをダウンロードします。サブモジュールに含まれるサブモジュールもダウンロードされます。

• --branch: リポジトリの特定のブランチをチェックアウトします。この場合は master です。

このコマンドでは、実行 ボタンは使用できません。これは、あなたのマシンで使用することを想定しているためです。

フォーク

現在のブランチを基に、新しいブランチを作成します。

$ git checkout -b feature-1 master

master というブランチを基に、feature-1 という新しいブランチを作成し、それをチェックアウトします。

$ git push -u origin feature-1

リモートリポジトリに新しいブランチ feature-1 をアップロードします。

統合

現在のブランチを別のブランチにマージします。

$ git merge staging-1

現在のブランチに、staging-1 というブランチをマージします。

$ git push -u origin master

リモートリポジトリのマスターブランチに、先ほど追加した変更をアップロードします。

SSH

セットアップ

SSH を使用するには、プロファイルの SSH 公開鍵を設定する必要があります(まだ設定されていない場合)。設定するには、以下の手順に従って下さい。

1. 新規SSHキーを生成する

2. SSHをクリップボードにコピーする (ステップ1にのみ適用)

3. コピーした内容をプロファイルのSSHキーに貼り付け、"追加" をクリックします。

   
   

4. 鍵は下に表示されるはずです。

   
   

接続

sshを使用してビルドに接続するには、ターミナルで次のコマンドを使用します:

$ ssh <build_id>@<domain>

このコマンドへのショートカットは、右上のSSHタブ内にあります。

プロジェクトに対して 適正なアクセス権 を持っている場合、ビルドへのSSHアクセスが許可されます。

注釈

長時間のssh接続は保証されません。リソースを解放するために、アイドル状態の接続はオーダで切断されます。

サブモジュール

現在のブランチに、別のリポジトリのブランチを サブモジュール として追加します。

サブモジュール を使用すると、他のリポジトリのモジュールをプロジェクトで使用することができます。

サブモジュール機能については、このドキュメントの章 サブモジュール で詳しく説明されています。

$ git submodule add -b master <URL> <PATH>

リポジトリの <URL> の master というブランチを、現在のブランチの <PATH> というパスにあるサブモジュールとして追加します。

$ git commit -a

現在の変更を全てコミットします。

$ git push -u origin master

リモートリポジトリのマスターブランチに、先ほど追加した変更をアップロードします。

削除

リポジトリからブランチを削除します。

$ git push origin :master

リモートリポジトリのブランチを削除します。

$ git branch -D master

リポジトリのローカルコピーからブランチを削除します。