環境におけるホットフィックスの理解

環境におけるホットフィックスの理解

お知らせ:当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の英語版を参照してください。

Notes
メモ
  1. この機能は現在、早期アクセス機能として、Creator 6のすべての有料プランで利用できます
  2. ホットフィックスを適用できるのは次の場合のみです。
    1. 2026年6月27日以降に、開発からステージ、ステージから本番へ公開されたアプリケーション。
    2. すべての環境間で依存関係のない独立したアプリ。
概要

ホットフィックスは、環境において、一時的な分離環境を使用し、重要な修正を本番環境に直接適用できる機能です。特に、本番環境で発生した問題に対して即時修正が必要な一方で、開発環境では未リリースの変更を含む作業が進行中で、まだ本番環境に反映できない場合に役立ちます。これにより、通常の配信サイクル外で緊急の問題に対応でき、変更内容をステージ環境と開発環境に逆マージして、今後のリリースの継続性も確保できます。

提供状況 

  1. ホットフィックスは、Creatorバージョン6のすべての有料プラン作成できます。
  2. スーパー管理者と管理者は、すべてのアプリ環境に修正を適用するためのホットフィックスを作成できます。開発者環境にアクセスできますが、ホットフィックスは作成できません。
  3. ホットフィックスを作成できるのは、フォームワークフローと関数のDelugeスクリプトを編集する場合のみです。

1. 概要

ホットフィックスは専用の一時的な環境で、通常の「開発 > ステージ > 本番」の配信を経由せずに、稼働中のアプリケーションへ重要な修正を直接反映できます。


環境に追加された一般的なアプリケーションでは、バージョン更新は開発、ステージ、本番の順に進みます。これは、安定性と管理されたリリースを確保するための体系的なフローです。ただし、稼働中のアプリケーションで重大な問題が発生した場合、通常の配信を待つと、ユーザーにダウンタイムや業務の中断が発生する可能性があります。ホットフィックスを使用すると、分離されたホットフィックス環境を通じて本番環境の問題を修正し、通常のサイクルを一時的に迂回できます。


ホットフィックスを作成すると、Creatorは本番アプリケーションをホットフィックス環境に複製し、そこで必要な変更を適用できます。準備ができたら、これらの修正を本番環境に直接公開します。その後、変更内容をアプリのステージ版と開発環境にマージし直すことで、今後のリリースと現在稼働中の内容との整合性を保てます。


たとえば製造システムでは、生産データを処理するフォームワークフローに不具合があると、業務に支障が生じる可能性があります。ホットフィックスを使用すると、次のリリースサイクルを待たずに問題を即座に修正できます。

1.1. ホットフィックスで編集できる内容

ホットフィックスでは、次のワークフロー種別でDelugeスクリプトの編集がサポートされています。

  1. フォームワークフロー
  2. 関数

ホットフィックス環境では、これらの既存コンポーネントを変更できますが、新しいコンポーネントの追加や既存コンポーネントの削除はできません。

1.2. ホットフィックスが通常の配信サイクルに与える影響

ホットフィックスを開始すると、対象アプリの配信パイプラインに一時的な制限が適用されます。

  1. 通常の公開操作のロック:これらの操作は公開パイプラインに影響しないため、アプリは開発環境で編集でき、ステージ環境でアクセスできます。ただし、ホットフィックスの作成中は、修正内容を手動でステージ環境と開発環境にマージし直すまで、開発からステージ、ステージから本番への通常の公開操作はロックされます。これにより、ライフサイクルが中間状態にある間に競合する変更が取り込まれないようにします。
  2. 稼働中の本番アプリのメンテナンスモード:本番アプリのライブモードは、ホットフィックスの変更が本番環境に適用されている間のみメンテナンスモードになります。この段階では、稼働中のアプリケーションをエンドユーザーは利用できません。この公開が完了すると、アプリケーションのライブモードに再びアクセスできるようになります。

2. ホットフィックスのライフサイクル

ホットフィックスのライフサイクルは、緊急修正を各環境で進行中の既存作業に支障なくリリースするために、定義された手順に従います。

  1. ホットフィックスの詳細-ホットフィックス環境に追加する対象として選択された本番アプリを確認し、ホットフィックス用の一意のリンク名を指定して、ホットフィックスを設定します。
Notesメモ:選択されたアプリケーションは、修正対象の問題を含む本番アプリです。アプリをホットフィックス環境に追加すると、この選択は確定され、現在のホットフィックスライフサイクル内では変更できません。
  1. 修正の本番環境への適用-ホットフィックス環境のアプリ内で必要なDelugeスクリプトを編集し、変更を本番環境に公開します。修正が本番環境に反映されると、このホットフィックスの一部として再度編集することはできません。
  2. 修正のステージ環境へのマージ-ホットフィックスの変更をアプリのステージ版にマージし直します。この処理中に、同じコンポーネントがホットフィックスとステージ版の両方で変更されている場合、競合が発生することがあります。
    1. 競合なし:マージを直接続行できます。
    2. 競合あり:競合はステージ版で直接解決できないため、競合している各ステージ版を1つずつ順番にホットフィックス環境へ公開し、比較して競合解決を完了する必要があります。前の競合バージョンが完全に解決されるまで、次の競合バージョンをホットフィックスに公開することはできません。すべてのステージ版の競合が解決されると、ステージ環境へのマージを続行できます。
  3. 修正の開発環境へのマージ-ホットフィックスの変更をアプリの開発版にマージします。開発版とホットフィックスの変更の間に競合がある場合は、マージを完了する前に解決する必要があります。
  4. ホットフィックスの完了-すべての手順が完了すると、ホットフィックスは完了としてマークされ、対象アプリのすべての公開操作が再開されます。

2.1. 競合解決プロセス

ホットフィックスのライフサイクルでは、同じコンポーネントがステージ版または開発アプリと、ホットフィックスの両方で変更された場合に競合が発生することがあります。この場合、ステージ版/開発アプリとホットフィックスの変更を並べて比較し、競合を解決する必要があります。すべての競合に対応すると、マージを続行でき、ステージ版または開発アプリは通常の配信に沿って本番環境へスムーズに進められます。


ステージ環境へのマージ時の競合解決
  1. 本番アプリ:v3.0(ホットフィックスを適用中。関数Aが変更されています)
  2. ステージ版:v4.0、v5.0、v5.1

関数Aはステージ版4.0と5.1でも変更されているため、競合が発生します。

解決手順:

  1. バージョン4.0-競合あり
    v4.0をホットフィックス環境に公開し、ホットフィックスの変更と比較して、関数Aの競合を解決します。
  2. バージョン5.0-競合なし
    V5.0には競合がありません。ただし、競合している2つのバージョンの間にあるため、v5.1を公開する際にバージョン順序の整合性を維持する目的で自動的に含まれます。
  3. バージョン5.1-競合あり
    v5.1をホットフィックス環境に公開し、関数Aの競合を解決します。

すべての競合が解決されると、ホットフィックスの変更はステージ環境にマージし直され、各バージョンは通常の配信に沿って本番環境へ進みます。

3. 使用例

新入社員のオンボーディングアプリケーションで、新しい従業員データが送信されるとフォームワークフローアクセス権限の付与がトリガーされるケースを考えます。このワークフローは従業員の部署を読み取り、役割に応じた適切なシステムアクセスを付与するためのAPI呼び出しを送信します。環境で本番アプリをリリースした後、契約部署の新入社員にはシステムアクセスが付与されない状態でオンボーディングされます。その結果、業務を開始できませんが、他の部署には影響がありません。


ワークフローの問題-
このワークフローは、ステージにある既存の部署値を前提に作成、テストされていました。ステージでのテストサイクル後に、本番環境で契約部署が部署項目に追加されたため、フォームワークフロー内の条件ブロックにはそれに一致する分岐がありません。本番アプリで契約従業員データが送信されると、access_levelが割り当てられず、トリガーされたAPI呼び出しはエラー表示なしで失敗します。

  1. dept = input.Department;
  2. role = input.Role;
  3. if(dept == 'Full-Time')
  4. {
  5. access_level = 'standard';
  6. }
  7. else if(dept == 'Part-Time')
  8. {
  9. access_level = 'limited';
  10. }
  11. response = invokeurl
  12. [
  13. url: 'https://api.zylkerhrsystems.com/provision'
  14. type: POST
  15. parameters: {'employee_id': input.Employee_ID,
  16. 'access': access_level}

開発環境には未リリースの変更があり作業サイクルの途中であるため、この問題の修正を標準パイプラインで反映すると、新規契約社員全員のオンボーディングが遅れてしまいます。


ホットフィックスは開始され、リンク名Access_Provisioning_Fixが設定され、オンボーディングアプリがホットフィックス環境に追加されます。アプリビルダー内でAccess Provisioningワークフロースクリプトを更新し、契約部門の追加に対応したうえで、本番に直接公開します。これにより、すべての新規契約社員レコードにシステムアクセスが正しくプロビジョニングされます。その後、修正内容はホットフィックスが完了としてマークされる前に、ステージと開発にマージして戻されます。

4. ナビゲーションガイド

[管理ダッシュボード]の左側ペインにある[デプロイ]セクションで、[環境]を確認できます。ここから、対象の本番アプリケーションの横にある省略記号()アイコンをクリックして、ホットフィックスを作成できます。


5. 注意点

ホットフィックスの作成時。

  1. ステージから本番への公開が現在進行中の場合、ホットフィックスを作成する前に完了している必要があります。
  2. ホットフィックスを作成するには、本番アプリに少なくとも1つのワークフローまたは関数が存在している必要があります。いずれも存在しない場合、そのアプリのホットフィックスは作成できません。
  3. ステージと本番が同じバージョンの場合、ホットフィックスを開始せずに開発アプリを直接編集し、標準パイプラインで問題を解決できます。

ホットフィックスの実行中。

  1. Creatorアカウントで一度に有効にできるホットフィックスは1つだけです。新しいホットフィックスを作成できるのは、進行中のホットフィックスが修正内容をステージと開発にマージして戻すことを含むライフサイクル全体を完了した後のみです。
  2. ホットフィックスを削除できるのは、本番アプリに変更が適用されるまでです。
  3. 修正を本番に適用すると、ロールバックはできません。ホットフィックスのライフサイクルを完了するには、修正内容をステージと開発にマージして戻す必要があります。

6. 関連トピック

  1. 環境内の本番アプリに対するホットフィックスの設定

次のステップ
次のステップ
変更を環境全体に適用するために、ホットフィックスを設定および管理する方法を確認しましょう。