次の方法で共有


Test Engine 機能のライフサイクル (プレビュー)

注意

プレビュー機能は運用環境での使用を想定しておらず、機能が制限されている可能性があります。 これらの機能を公式リリースの前に使用できるようにすることで、顧客が事前にアクセスし、そこからフィードバックを得ることができます。

Test Engine には、実験的な概念から一般公開される機能への機能の進行状況を管理するための構造化された機能ライフサイクル モデルがあります。 このアプローチにより、ユーザーは運用シナリオの信頼性と安定性を確保しながら、さまざまな成熟度レベルで新しい機能にアクセスできます。

Test Engine での機能の進行状況

Test Engine の機能は、開始から一般的な利用が可能になるまで、3 つのフェーズで定義されたパスを追従します。

  1. オープンソース イノベーション (プレビュー フェーズ)
  2. プレビュー機能 (評価フェーズ)
  3. 一般提供 (安定フェーズ)

1. オープンソース イノベーション (プレビュー フェーズ)

Test Engine の多くの機能は、オープンソース リポジトリで始まります。

  • コミュニティメンバーとMicrosoftエンジニアが新機能を提案し、貢献します
  • より多くのシナリオをサポートするために、新しいプロバイダーと拡張機能が開発されています
  • カスタム Power Fx アクションの作成と実環境でのテスト
  • 実験的なコンセプトは、正式な製品統合の前に検証されます

このプレビュー フェーズは、ソースから Test Engine をビルドする開発者が利用できる最先端の機能を表します。

2. プレビュー機能 (評価フェーズ)

オープンソース環境で価値を実証した機能は、評価フェーズに進み、明示的なオプトインがあれば、公式の Power Platform CLI (pac) リリースで利用可能になる可能性があります。

  • 機能は、Power Fx の Preview 関数のプレフィックスからアクセスできます
  • 機能は、テストの設定で明示的に有効にする必要があります。
testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
      - Preview
  • このフェーズの機能は、より広範なテストを受けますが、フィードバックに基づいて進化する可能性があります
  • ドキュメントには、将来の変更の可能性を示すプレビューの指定が含まれています

3. 一般提供 (安定期)

プレビュー フェーズでの徹底的なテストと改良の後、安定した機能は一般提供へと進みます。

  • 機能は Preview プレフィックスから TestEngine プレフィックスに移行します
  • 機能は、特別な設定なしでデフォルトで利用可能になります
  • 機能は、完全なサポートにより運用環境に対応していると見なされます
  • ドキュメントにより、プレビューの指定が削除されます

Power Fx 機能組織による機能の有効化

Test Engine は、機能の可用性を制御する主なメカニズムとして、Power Fx 関数のプレフィックスを使用します:

関数のプレフィックス プロパティ 在庫状況
TestEngine すべてのユーザーが利用できる運用環境に対応した機能 既定で有効
Preview 変更される可能性のある評価中の機能 明示的なオプトインが必要
(なし) コアな Power Fx の関数 常に利用可能

この構成には、いくつかの利点があります:

  • 機能成熟度の明確な表示: プレフィックスは安定性の期待を表わします
  • アクセス制御: プレビュー機能を明示的に有効にして、意図しない変更からユーザーを保護する必要があります
  • バージョンの耐性: 機能が成熟するにつれて、コードを段階的に更新して新しいプレフィックスを使用できます

これらのプレフィックスの構成と使い方の詳細については、 テストにおける Power Fx 関数の構成を使用する を参照してください。

Test Engine の進化に貢献

Test Engine 製品チームは、コミュニティと積極的に協力して製品を進化させています。

オープンソースの貢献

コミュニティ メンバーは、いくつかの方法で Test Engine に貢献できます。

  • プロバイダー拡張機能: 新しいプロバイダーを作成して、より多くのアプリケーションの種類をサポートします
  • Power Fx アクション: 新しいテスト シナリオを有効にするカスタム アクションを開発します
  • 機能強化: 一般的なシナリオに対応する既存の機能の改善
  • 問題の報告: GitHub リポジトリの課題を使用して、発見した問題を報告します。 既存の既知の問題については、aka.ms/TestEngineOpenIssues を参照してください

製品統合への道筋

オープンソースのコントリビューションとして開始された機能は、以下のプロセスを経て公式 Power Platform CLI (pac test run) に含めることが検討される場合があります。

  1. 初期開発: 機能はオープン ソース リポジトリで作成、テストされます
  2. コミュニティ検証: 他のユーザーが機能の有用性と安定性を確認します
  3. 製品考慮: Test Engine 製品チームが機能をレビューします
  4. プレビュー統合: 承認された場合、機能はプレビューのプレフィックスに統合されます
  5. 一般提供: 十分な検証の後、機能は TestEngine プレフィックスに移行します

製品チームとのコラボレーション

最終的に公式製品に含まれる可能性のある機能の提供に関心のある開発者は、次のことを行う必要があります。

  • 開発前の話し合い: リポジトリでイシューを開いてコンセプトについて話し合います
  • 設計ガイドラインに従う: 実装が Test Engine のアーキテクチャと一致していることを確認します
  • 包括的なテストの提供: 信頼性を実証する自動テストを含めます
  • 機能の文書化: ユーザー向けの明確なドキュメントを作成します

機能ライフサイクル モデルの利点

Test Engine ユーザーにとって、このモデルにはいくつかの利点があります。

  • イノベーションへのアクセス: 正式にリリースされる前に最先端の機能を使用できます
  • リスクの制御: ニーズに基づいて有効にするプレビュー機能を選択します
  • 明確な期待: 一貫したプレフィックス規則による機能の安定性の理解
  • 参加機会: コントリビューションとフィードバックを通じて製品の方向性に影響を与えます