RetoolのGitワークフロー
RetoolアプリケーションをGitリポジトリーと同期させることができ、それにより、複数の環境にわたるRetoolアプリケーションの開発方法とデプロイ方法をカスタマイズできます。
最も一般的な手法は、開発、ステージング、および本番という複数のRetoolインスタンスの使用です。環境間でのコード昇格はGitで制御されるため、すべての変更内容を、上位環境へのその昇格の前にプル・リクエストとして確認する必要があります。エンジニアは、開発インスタンスで安全にRetoolアプリケーションを構築し、ステージング・インスタンスでテストの実行とQAの実行を行うことができます。そして、エンド・ユーザーは本番インスタンス上のアプリケーションにアクセスできます。
オプション1: 変更内容を自動的に同期させます
Git Syncingのこのバージョンでは、開発インスタンスは、変更内容をdevブランチに継続的にプッシュするように構成され、一方、ステージング・インスタンスと本番インスタンスは、stagingブランチとmasterブランチからのコードをそれぞれ自動的に監視およびデプロイするように構成されます。エンジニアには開発サーバー上のアプリケーションを編集するためのアクセス権のみが与えられ、一方、ステージングおよび本番アプリケーションはロックされます。
オプション2: featureブランチを使用して開発します
注意: オプション2は、現在のGitHubでのみサポートされています。
アプリケーションが昇格に値すると判断すると、エンジニアが開発インスタンスでそのアプリケーションを「保護」し、それによって、そのアプリケーションが新しいブランチでGitHubに同期されます。明示的にGitHubに同期されたアプリケーションのみ、ステージング・インスタンスおよび本番インスタンスに到達します。
この手法には、次の2つの利点があります。(1)エンジニアは、すべてのアプリケーションがステージングまたは本番に表示されるという心配をすることなく、開発インスタンスを「サンドボックス」環境として扱うことができます。また、(2)featureブランチがサポートされているため、自分のすべてのアプリケーションを同時に同期させる必要なく、個々のアプリケーションを本番に昇格させることができます。
インスタンスのロック
どちらのフローでも、Retoolのステージング・インスタンスと本番インスタンスは、それぞれのブランチからのプルのみを行うことを覚えておいてください。何らかの理由で、あるユーザーに、これらのインスタンスのいずれかで実行されているRetoolアプリケーションへの編集アクセス権がある場合は、それらのユーザーに、UIを介して変更を加えることはできないことを知らせる警告が表示されます。このようにするには、そのインスタンスのdocker.env
ファイル内でVERSION_CONTROL_LOCKED=true
を設定します。
Updated over 3 years ago