Integrieren Sie die Work IQ-Entwicklungstools in das Microsoft 365 Copilot-Plug-In CI/CD

Verwenden Sie Work IQ Dev Tools (WIQD), um Continuous Integration und Continuous Delivery (CI/CD)-Prüfungen zu Ihrem Microsoft 365 Copilot Plug-In-Projekt hinzuzufügen. In diesem Artikel werden kostengünstige Pull-Request-Prüfungen von authentifizierten Kandidatentests und genehmigten Releaseeinreichungen getrennt.

Dieser Leitfaden richtet sich an Entwickler, die WIQD in ein vorhandenes CI/CD-System integrieren. Es dokumentiert die Anforderungen und Befehlssequenzen, nicht das Einrichten einer vollständigen CI/CD-Umgebung. Es wird erwartet, dass Sie die Jobs, Trigger, Runner, Geheimnisse, Genehmigungen und die Artefaktbehandlung Ihres Systems konfigurieren und die Beispiele in dieses System integrieren. Bereiten Sie zunächst den Runner, die Umgebungen und die Anmeldeinformationen vor, die unter "Voraussetzungen" aufgeführt sind.

Das Releaseziel ist der App-Katalog Ihrer organization Ihres Mandanten, in dem ein Administrator übermittelte Plug-Ins genehmigt, bevor Benutzer sie entdecken können. Die direkte Weitergabe ist eine separate Verteilungsmethode. Dieser Workflow automatisiert weder die Genehmigung durch den Administrator noch die Veröffentlichung öffentlicher Speicher über das Partner Center.

Voraussetzungen

Um die WIQD-Befehle in Ihren vorhandenen Pipelines oder Workflows auszuführen, stellen Sie sicher, dass Sie über Folgendes verfügen:

  • Ein quellcodegesteuertes WIQD-Plug-In-Projekt mit seinen Lebenszyklusdateien, Komponententests und einer nicht geheimen Umgebungskonfiguration. Weitere Informationen finden Sie unter Erstellen eines Plug-Ins mit Work IQ Dev Tools.
  • Ein vorhandenes CI/CD-System mit Quellauschecken, Runnern, geschützten Geheimnissen und Freigabegenehmigungskontrollen. Sie wissen, wie Sie Jobs, Trigger und Artefaktbehandlung in diesem System konfigurieren.
  • Node.js 24.15.0 oder höher und ein genau genehmigtes WIQD-Release auf dem Runner. Befolgen Sie die WIQD-Installationsanweisungen, und notieren Sie die installierte Version mit wiqd --version.
  • PowerShell 7, um die Befehlsbeispiele in diesem Artikel zu verwenden.
  • Eine konfigurierte WIQD-Umgebung für mandantengestützte Befehle. Befolgen Sie die WIQD-Umgebungskonfiguration , um die Umgebungsdateien vorzubereiten. Separate Test- und Produktionsumgebungen oder Microsoft 365-Mandanten sind optional, keine Voraussetzungen. dev, stagingund prod sind herkömmliche Namen, keine Garantie für den Mandanten oder den Bereitstellungsbereich.
  • Eine Microsoft 365-Identität, die für die ausgewählten Bereitstellungs-, Deep-Validation- und Veröffentlichungsvorgänge mit der erforderlichen delegierten Zustimmung autorisiert ist. Erteilen Sie nur die Berechtigungen, die für diese Vorgänge erforderlich sind, wie in den WIQD-Zustimmungs- und Ressourcenlimits aufgeführt.
  • Für deklarative Agent-Bewertungen ein bereitgestelltes Ziel, eine überarbeitete Eingabeaufforderungsdatei, ein genehmigter Qualitätsschwellenwert sowie eine separat konfigurierte Evaluierungsauthentifizierung und EULA-Akzeptanz. Befolgen Sie den Leitfaden zur Evaluierung des WIQD-Agents für detaillierte Setups und Anforderungen. Die Agent-Auswertung ist für Plug-Ins ohne Agenten, z. B. Nur-Skill- oder Nur-Tool-Plug-Ins, nicht erforderlich. Behalten Sie ihre anwendbaren Komponenten- und Zielerfahrungstests bei.

Befolgen Sie die Dokumentation Ihres CI/CD-Anbieters für die Plattformeinrichtung und Workflow-Erstellung. Weitere Informationen finden Sie unter Erstellen Ihrer ersten Azure-Pipeline oder Implementieren von GitHub Actions.

Auswählen der Pipelineszenarien

Konfigurieren Sie separate Aufträge, sodass nicht vertrauenswürdige Änderungen nicht auf Anmeldeinformationen für die Bereitstellung zugreifen oder keine Freigabe übermitteln können.

Szenario Gründe für die Ausführung WIQD-Vorgänge Gate
Validierung von Pull-Anfragen Wenn ein Pull Request geöffnet wird und nach jeder Aktualisierung der vorgeschlagenen Änderungen Offline-Plugin-Validierung; Optionale Offline-Veröffentlichungsbereitschaft Statische Überprüfungen werden erfolgreich durchgeführt, wobei die Abdeckungsgrenzen aufgezeichnet werden
Kandidatenerstellung und -tests Genehmigte Änderungen in einem vertrauenswürdigen Branch oder eine autorisierte manuelle Ausführung Bereitstellen des Plug-Ins in der ausgewählten Umgebung, Verpacken, Tiefenvalidieren, Testen und Evaluieren der anwendbaren Agents Paket-, Komponenten-, Erfahrungs- und Qualitätsprüfungen bestehen
Freigabe einreichen Genehmigte Kandidaten- und Freigabeautorisierung Bestätigen Sie die Releasekonfiguration und das überprüfte Paket, und veröffentlichen Sie sie dann im App-Katalog der organization. Erfolgreiche Einreichung, gefolgt von Administratorgenehmigung und Überprüfung des Rollouts

Behalten Sie den Komponentenbuild und die Tests Ihres Projekts bei. WIQD bietet keinen universellen Kompilierungsbefehl für jedes Plug-in oder aktualisiert die Remotedienste, auf die Ihr Plug-In verweist.

Wenn Sie die Anleitung zur Einrichtung der WIQD-Pipeline an ein Plugin-Projekt anpassen, verwenden Sie die wiqd plugin Befehlssequenzen dieses Artikels. Die Lebenszyklusbeispiele dieses Leitfadens wiqd agent zielen auf Agent-Projekte ab, nicht auf eigenständige Plug-In-Projekte.

Fügen Sie kostengünstige Pull Request-Checks hinzu

Führen Sie die Offlinevalidierung ohne Microsoft 365-Anmeldeinformationen aus. Bei diesen Überprüfungen werden keine Ressourcen bereitgestellt, kein Agent aufgerufen oder etwas an die Registrierung übermittelt.

So fügen Sie einem vorhandenen Auftrag eine statische Prüfung hinzu:

  1. Sehen Sie sich die vorgeschlagene Quelle an, und installieren Sie das genehmigte WIQD-Release.
  2. Führen Sie die entsprechenden Komponententests Ihres Projekts aus.
  3. Führen Sie den folgenden WIQD-Schritt aus, und ersetzen Sie .\plugins\contoso ihn dabei durch Ihren Projektpfad und dev den vorgesehenen Umgebungskontext.
  4. Erfordern einen systemeigenen Beendigungserfolg und einen JSON-Erfolgsumschlag, bevor der Auftrag erfolgreich ausgeführt werden kann.

In diesem Schritt von GitHub Actions wird die Quelloberfläche des deklarativen Agents in einem eigenständigen Plug-In-Projekt überprüft:

- name: Validate plugin source
  shell: pwsh
  run: |
    $ErrorActionPreference = 'Stop'
    $PSNativeCommandUseErrorActionPreference = $false
    $text = wiqd plugin validate --path .\plugins\contoso --env dev --mode static --json
    if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
    $result = ($text -join "`n") | ConvertFrom-Json
    if ($result.status -cne 'success') { throw 'Plugin source validation failed.' }

Derselbe PowerShell-Text kann in einem Azure Pipelines-Schritt pwsh: ausgeführt werden. Fügen Sie keine Lebenszyklus- oder Bewertungsanmeldeinformationen in den nicht vertrauenswürdigen Pull Request-Auftrag eines der beiden Anbieter ein.

Die statische Validierung umfasst deklarative Agent-Manifeste und referenzierte API-Plugin- oder OpenAPI-Dateien. Das App-Manifest der obersten Ebene, der eigenständige Skill-Inhalt oder die Stammconnectordeklarationen werden nicht überprüft. Ein Nur-Skill- oder Connector-Plug-In kann erfolgreich sein, weil keine Überprüfungen für deklarative Agents gelten, und nicht, weil jede Komponente gültig ist.

Führen Sie für eine zusätzliche Offline-Veröffentlichungsbereitschaftsprüfung den folgenden Befehl aus, und wenden Sie dieselben Exitcode- und JSON-Prüfungen an:

wiqd plugin publish --path .\plugins\contoso --env dev --dry-run --no-runtime --no-network --json

Bei dieser Überprüfung wird das Plug-In nicht übermittelt. Laufzeit- und Netzwerkprüfungen sind deaktiviert, und deklarative Agent-Phasen werden übersprungen, wenn kein Agent vorhanden ist. Weder die Offlineprüfung ersetzt die Paket-zuerst-Tiefenvalidierung noch Tests in der Zielumgebung von Microsoft 365.

Konfigurieren der Authentifizierung für vertrauenswürdige Aufträge

Für Bereitstellung, umfassende Überprüfung und Veröffentlichung sind Anmeldeinformationen erforderlich, die der Pull Request-Auftrag nicht enthält. Überprüfen Sie die dokumentierten Authentifizierungsmodi mit Ihrem Mandantenadministrator, bestätigen Sie die Unterstützung in Ihrer ausgewählten WIQD-Version, und fügen Sie dann Anmeldeinformationen nur in vertrauenswürdige Schritte ein.

Warnung

Verwenden Sie keine Authentifizierung mit Benutzername/Kennwort. Verwenden Sie den Aktualisierungstokenmodus, sobald die Unterstützung in Ihrer ausgewählten WIQD-Version bestätigt ist. Verwenden Sie den Kennwortmodus nur, wenn die Sicherheitsrichtlinie Ihrer Organization dies explizit zulässt. Schwächen Sie nicht die MFA- oder bedingten Zugriffsanforderungen, um die Pipeline erfolgreich zu machen. Aktualisierungstoken sind ebenfalls sensible Anmeldeinformationen und erfordern geschützten Speicher und eingeschränkten Zugriff.

Wichtig

Der Leitfaden zur WIQD-Pipelineauthentifizierung kennzeichnet die Aktualisierungstokenauthentifizierung als noch nicht veröffentlicht oder vollständig validiert. Bei den Beispielen zum Aktualisieren des Tokens handelt es sich um den Integrationsleitfaden, nicht um einen bestätigten produktionsbereiten Authentifizierungspfad. Bestätigen Sie die Releaseverfügbarkeit, die Sicherheitsgenehmigung und die Live-Zustimmungs- und Betriebsprüfungen für genau die ausgewählte WIQD-Version, bevor Sie diese Beispiele verwenden.

Modus Erforderliche Prozesseingaben Zu entfernende Eingaben
Token aktualisieren CI_ENABLED=true, eine Mandanten-GUID in M365_TENANT_IDund geschützte M365_REFRESH_TOKEN Entfernen von sowohl als auch M365_ACCOUNT_NAMEM365_ACCOUNT_PASSWORDleere Definitionen
Benutzername und Kennwort CI_ENABLED=true, geschützt M365_ACCOUNT_NAMEund geschützt M365_ACCOUNT_PASSWORD Entfernen M365_REFRESH_TOKEN; M365_TENANT_ID ist in diesem Modus optional

Für die Authentifizierung des Aktualisierungstokens:

  1. Befolgen Sie das private, lokale Bootstrap-Verfahren in der WIQD-Pipelineauthentifizierung.
  2. Legen Sie das resultierende Token direkt in den geheimen Speicher Ihrer genehmigten Pipeline ab. Übergeben Sie es nicht, übergeben Sie es nicht als Befehlsargument, und fügen Sie es nicht in Protokolle oder Artefakte ein.
  3. Ordnen Sie den Mandanten und das Token dem vertrauenswürdigen Befehlsprozess zu.
  4. Überprüfen Sie die ausgewählte WIQD-Version, die Identität, den Runner und die erforderlichen Vorgänge in einer kontrollierten Ausführung, bevor Sie die Releaseübermittlung aktivieren.

Verwenden Sie für einen vertrauenswürdigen GitHub Actions-Schritt diese Umgebungsbindungen:

env:
  CI_ENABLED: 'true'
  M365_TENANT_ID: ${{ vars.M365_TENANT_ID }}
  M365_REFRESH_TOKEN: ${{ secrets.M365_REFRESH_TOKEN }}

Azure Pipelines erfordert eine explizite env Zuordnung für geheime Variablen. Verwenden Sie diese Bindungen, und lehnen Sie nicht aufgelöste $(NAME) Makros ab, bevor Sie WIQD aufrufen:

env:
  CI_ENABLED: 'true'
  M365_TENANT_ID: $(M365_TENANT_ID)
  M365_REFRESH_TOKEN: $(M365_REFRESH_TOKEN)

Dies sind Umgebungsbindungen, keine vollständigen Pipelinedefinitionen. Verwenden Sie die Beispiele für die WIQD-Pipeline sowohl für Authentifizierungsmodi als auch für anbieterspezifische Überprüfungen.

CI_ENABLED Muss genau klein geschrieben truesein; generisch CI=true ist nicht ausreichend. Aufrufen von Lebenszyklusbefehlen direkt, nicht wiqd auth login in CI. Dies sind delegierte Anmeldeinformationen, keine reine App-Identität. MFA, bedingter Zugriff, Zustimmung oder Berechtigungen werden nicht umgangen.

WIQD rotiert den geheimen Speicher der Pipeline nicht. Wenn für die Authentifizierung eine menschliche Anmeldung oder Zustimmung erforderlich ist, beheben Sie das Richtlinien- oder Zustimmungsproblem und ersetzen Sie das Geheimnis durch das dokumentierte lokale Verfahren. Wechseln Sie nicht automatisch zu einer anderen Identität.

Erstellen und Überprüfen eines Kandidaten

Erstellen und testen Sie einen Kandidaten in Ihrer ausgewählten WIQD-Umgebung, bevor Sie die Veröffentlichung einreichen. Bei Tests können derselbe Mandant, die gleiche Umgebungskonfiguration und die autorisierte Microsoft 365-Identität wie in der Version verwendet werden. Eine separate Testumgebung ist optional. Behalten Sie die zugehörigen Befehle auf demselben Projekt- und Umgebungsstatus bei.

Warnung

Wenn das Kandidat und das veröffentlichte Plug-In dieselbe Plug-In-Ressourcenidentität verwenden, kann die Bereitstellung Ressourcen aktualisieren, die von vorhandenen Benutzern vor der Katalogübermittlung oder der Administratorgenehmigung verwendet werden. Verwenden Sie diese Identität nur dann für Kandidatenaktualisierungen, wenn diese Änderungen autorisiert sind und der Zugriff kontrolliert wird. Eine separate Kandidatenidentität ist optional, isoliert jedoch Kandidatenänderungen vom veröffentlichten Plug-In.

So bereiten Sie einen Kandidaten vor:

  1. Wählen Sie die genehmigte Quellrevision und die Version des Plug-In-Pakets aus.
  2. Wenn die ausgewählte Umgebung bereits bereitgestellt wurde, stellen Sie den festgelegten Umgebungszustand über Ihren genehmigten sicheren Persistenzmechanismus zur Verfügung. Behalten Sie alle für den Lebenszyklus erforderlichen Werte bei, nicht nur die App-ID. Stellen Sie Anmeldeinformationen nicht wieder her, indem Sie ein Projektarchiv oder einen Authentifizierungscache herunterladen.
  3. Führen Sie Komponentenbuilds, Tests und Offline-Plug-In-Validierungen aus.
  4. Stellen Sie die ausgewählte Umgebung bereit oder aktualisieren Sie sie, falls dies für diesen Kandidaten erforderlich ist.
  5. Wenn die Bereitstellung Eingaben ändert, die von der statischen Überprüfung abgedeckt werden, überprüfen Sie die betroffene Quelle erneut.
  6. Verpacken Sie das Projekt.
  7. Überprüfen Sie die exakt generierte ZIP-Datei genau.
  8. Behalten Sie die ZIP-Aufzeichnung, das Validierungsergebnis, die Quellrevision, die Paketversion, die WIQD-Version und die Umgebungsidentität mit dem Kandidatendatensatz bei.

Im folgenden PowerShell-Beispiel wird ein Kandidat behandelt, für den eine Bereitstellung oder ein Update der Mandantenressourcen erforderlich ist. Führen Sie es innerhalb eines vertrauenswürdigen Auftrags aus, nachdem die Authentifizierung konfiguriert wurde. Wenn die ausgewählte Umgebung bereits identitätsgebunden ist und kein Bereitstellungsupdate erforderlich ist, lassen Sie den Bereitstellungsbefehl aus. Wiederholen Sie die statische Überprüfung nur, wenn sich die Eingaben geändert haben. Ersetzen Sie den Projektpfad und dev die Umgebung durch Ihre Kandidatenkonfiguration. Das Hilfsprogramm stoppt bei systemeigenen Fehlern, falsch formatiertem JSON oder einem nicht erfolgreichen Umschlag.

Im Beispiel wird der vollständige JSON-Validierungscode .artifacts\validation.json als Zwischenbeweis geschrieben. Beschränken Sie den Zugriff, und überprüfen Sie die Nutzlast auf Mandanteninformationen, Bezeichner, URLs und vertrauliche Inhalte, bevor Sie sie aufbewahren oder freigeben. Bereinigen Sie die Beweise vor dem Hochladen; Laden Sie das Artefaktverzeichnis nicht automatisch hoch.

$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $false

function Invoke-WiqdJson([string[]]$Arguments) {
    $text = & wiqd @Arguments
    if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
    $result = ($text -join "`n") | ConvertFrom-Json
    if ($result.status -cne 'success') { throw 'WIQD operation failed.' }
    return $result
}

$project = (Resolve-Path .\plugins\contoso).Path
$environment = 'dev'
$artifactDirectory = Join-Path $PWD '.artifacts'
New-Item -ItemType Directory -Path $artifactDirectory -Force | Out-Null
$package = Join-Path $artifactDirectory 'plugin-dev.zip'
$common = @('--path', $project, '--env', $environment, '--json')

Invoke-WiqdJson (@('plugin', 'validate', '--mode', 'static') + $common) | Out-Null
Invoke-WiqdJson (@('plugin', 'provision') + $common) | Out-Null
Invoke-WiqdJson (@('plugin', 'validate', '--mode', 'static') + $common) | Out-Null
Invoke-WiqdJson (@('plugin', 'package', '--output', $package) + $common) | Out-Null
if (-not (Test-Path -LiteralPath $package -PathType Leaf)) { throw 'Package output is missing.' }
$validation = Invoke-WiqdJson (@('plugin', 'validate', '--mode', 'deep', '--package-file', $package) + $common)
$validation | ConvertTo-Json -Depth 100 | Set-Content -LiteralPath (Join-Path $artifactDirectory 'validation.json')

Die Tiefenvalidierung sendet die erstellte ZIP-Datei an die App-Validierungsbibliothek der Plattform und meldet die Paketüberprüfungen. Sie legt nicht das Laufzeitverhalten, die Verbindungsbereitschaft, den Remotedienststatus oder die Partner Center-Akzeptanz fest. Es erfordert authentifizierten Dienstzugriff und ist kein Offline-Pull-Request-Check. Fehlende Authentifizierung, ein Dienstfehler oder ein abgelehntes Paket blockiert den Kandidaten.

Die Bereitstellung geht normalerweise der Verpackung voraus, da die ausgewählte Umgebungsdatei geschrieben wird und die TEAMS_APP_ID diese Verpackung verbraucht wird. Wenn die Umgebung bereits identitätsgebunden ist und kein Bereitstellungsupdate erforderlich ist, lassen Sie den Bereitstellungsbefehl und das Paket für diesen vorhandenen Status aus. Bei der erneuten Bereitstellung wird diese Identität verwendet, aber beim erneuten Auschecken wird sie nicht automatisch beibehalten. Bewahren Sie die stabilen IDs sicher zwischen den Ausführungen auf; Veröffentlichen Sie keine Umgebungsdateien, Dateien mit geheimen Benutzerschlüsseln, Authentifizierungscaches oder den gesamten Arbeitsbereich als Artefakte.

Versuchen Sie nicht automatisch, die Bereitstellung oder Veröffentlichung nach einem Timeout erneut durchzuführen. Überprüfen Sie den vorhandenen Vorgang und die vorhandenen Ressourcen, bevor Sie eine erneute Ausführung autorisieren.

Testen und Evaluieren des bereitgestellten Kandidaten

Testen Sie den Kandidaten in jeder Zielerfahrung, einschließlich der erforderlichen Verbindungen, Berechtigungen, Fähigkeiten und Remotedienste. Die Paketüberprüfung stellt nicht fest, dass jede Funktion zur Laufzeit funktioniert.

Fügen Sie für ein Plug-In, das einen deklarativen Agenten enthält, ein Quality Gate hinzu:

  1. Identifizieren Sie die Titel-ID der bereitgestellten deklarativen Agent-Komponente. Ersetzen Sie nicht die Katalogtitel-ID des eigenständigen Plug-Ins.
  2. Bereiten Sie eine Datei mit überprüften Eingabeaufforderungen und eine Annahmeschwelle für repräsentative Aufgaben vor. Lassen Sie die Suite unverändert, wenn Sie den Kandidaten mit der Baseline vergleichen.
  3. Konfigurieren Sie die Microsoft 365-Agent-Verbindungsauthentifizierung der Eval-CLI und die erforderliche Mandantengenehmigung für den beabsichtigten Runner. Konfigurieren Sie die Anmeldeinformationen des ausgewählten Richters separat und schließen Sie die erforderliche EULA-Zustimmung der Eval-CLI außerhalb der CI ab.
  4. Führen Sie die Ausführung wiqd agent eval gegen diese bereitgestellte Komponente aus, und halten Sie das Ergebnis mit dem Kandidaten fest.
  5. Blockierung der Freigabe, wenn die Auswertung fehlschlägt, der Schwellenwert nicht erreicht wird oder der Runner sich nicht authentifizieren kann.

In diesem Beispiel wird ein bereitgestellter Agent aus dem evals\contoso Arbeitsbereich ausgewertet. Platzieren Sie die Datei mit den überprüften Eingabeaufforderungen in evals\contoso\evals\prompts.jsonRelation zum Stammverzeichnis des Auscheckvorgangs. Der Ausgabepfad wird relativ zu diesem Arbeitsbereich aufgelöst. Ersetzen Sie den Code <deployed-agent-title-id> durch die Titel-ID der Kandidatenkomponente. Der 0.85 Schwellenwert ist ein Beispiel. Wählen Sie die für Ihr Szenario erforderliche Qualitätsleiste.

$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $false
$agentId = '<deployed-agent-title-id>'
$text = wiqd agent eval --path .\evals\contoso --agent-id $agentId --env dev --threshold 0.85 --output .evals\results.json --json
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
$result = ($text -join "`n") | ConvertFrom-Json
if ($result.status -cne 'success') { throw 'Agent evaluation failed.' }

Die Referenzdokumente des Befehls "WIQD Eval " verweisen nur auf Eingabeaufforderungen Arbeitsbereiche und explizite Agent-IDs. Der Eval-Workflow dokumentiert die Schwellenwertbehandlung: Eine Schwellenwertüberschreitung und ein Upstream-Fehler geben beide einen Exit ungleich Null zurück, mit unterschiedlichen Fehlercodes in JSON.

Lebenszyklusaktualisierungstoken authentifizieren keine Auswertungen. Die Eval-CLI verwendet ihre eigene Microsoft 365-Authentifizierung, während der Richter separate GitHub Copilot- oder Azure-Anmeldeinformationen verwendet. Die WIQD-Quellen bieten keinen vollständigen unbeaufsichtigten Bootstrap für Bewertungsberechtigungen für beliebige gehostete Runner. Qualifizieren Sie diese Einrichtung an Ihrem Läufer, bevor Sie ihn zu einem automatisierten Tor machen. Wenn sie nicht unbeaufsichtigt ausgeführt werden kann, fordern Sie eine autorisierte Bewertung und deren Nachweise an, anstatt eine übersprungene Ausführung als Erfolg zu behandeln.

wiqd agent eval ist kein Evaluator für das gesamte Plug-In und wertet keine eigenständigen Skills, Root-Connectors oder benutzerdefinierten Engine-Agenten aus. Bewahren Sie für diese Funktionen die von Validieren und Testen Ihres Plug-Ins erforderlichen Komponenten- und Zielerfahrungstests auf.

Wenn Tester direkten Zugriff benötigen, autorisieren Sie die Zielgruppe explizit und folgen Sie der WIQD-Plugin-Freigabe. Die Freigabe erfordert AGENT_SCOPE=shared die ausgewählte Umgebungsdatei und eine entsprechende freigegebene Bereitstellung; das Benennen einer Umgebung dev richtet diesen Bereich nicht ein. Benennen Sie eine persönliche Bereitstellung nicht um, und kopieren Sie nicht ihre IDs, um die Freigabeanforderung zu umgehen.

Übermitteln eines genehmigten Updates an den App-Katalog der organization

Verwenden Sie einen geschützten Freigabeauftrag, um ein Update für den App-Katalog der organization zu übermitteln. Kandidatentests autorisieren keine Produktionsmutation oder Administratorgenehmigung.

So geben Sie ein Update frei:

  1. Genehmigen Sie die Revision der möglichen Quelle, die Paketversion, die Validierungsergebnisse, gegebenenfalls die Bewertungsnachweise und die Zielgruppe für die Produktion.
  2. Stellen Sie den eingerichteten Umgebungszustand des Releaseziels für den Job zur Verfügung. Behalten Sie die vorhandene Plug-In-Identität für ein Update bei, anstatt bei jeder Ausführung eine neue App-Registrierung zu erstellen.
  3. Wenn das Release eine andere Umgebungskonfiguration oder Plug-In-Ressourcenidentität als der getestete Kandidat verwendet, wiederholen Sie die betroffene Bereitstellung, Paketierung, Validierung und Tests für dieses Ziel.
  4. Wenn sich nur die authentifizierte Microsoft 365-Identität ändert, überprüfen Sie den Mandanten, die delegierte Zustimmung, die Berechtigungen und den Zugriff auf die erforderlichen Vorgänge. Für eine Änderung der Authentifizierungsidentität allein ist keine Neuerstellung des Pakets erforderlich.
  5. Vergewissern Sie sich, dass das Paket und die Bereitstellung für das Releaseziel die entsprechenden Tests bestehen. Wenn sich die effektive Konfiguration, das Paket und der Bereitstellungsstatus nicht geändert haben, verwenden Sie die möglichen Nachweise wieder, ohne die Zielüberprüfung zu wiederholen.
  6. Übermitteln Sie das bereitgestellte Projekt für das Releaseziel über den WIQD, und notieren Sie das Ergebnis.
  7. Übergeben Sie die Übermittlung dem Administrator zur Genehmigung, und überprüfen Sie dann den aktualisierten App-Katalogeintrag, die Paketversion, die Verfügbarkeit und die Benutzererfahrung.

Nach dem Überprüfen des Releaseziels und der Autorisierung der Übermittlung veröffentlicht dieser Befehl das Plug-In des ausgewählten Projekts im App-Katalog der organization. prod ist ein Beispiel für einen Umgebungsnamen; Verwenden Sie Ihre konfigurierte Releaseumgebung, bei der es sich um die gleiche Umgebung handeln kann, die für Kandidatentests verwendet wird.

$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $false
$text = wiqd plugin publish --path .\plugins\contoso --env prod --json
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
$result = ($text -join "`n") | ConvertFrom-Json
if ($result.status -cne 'success') { throw 'Plugin submission failed.' }

Behalten Sie das Veröffentlichungsergebnis mit dem Releasedatensatz bei.

wiqd plugin publish akzeptiert ein Projekt und eine Umgebung, nicht einen zuvor erstellten ZIP-Through --package-file. Die Tiefenvalidierung einer erfassten ZIP-Datei beweist nicht, dass bei der Veröffentlichung genau diese Bytes übermittelt werden. Lassen Sie den genehmigten Quell- und Umgebungsstatus unverändert, qualifizieren Sie das Veröffentlichungsverhalten Ihrer angehefteten WIQD-Version, und überprüfen Sie die resultierende übermittelte Version. Beschreiben Sie dies nicht als einen unveränderlichen ZIP-Werbeaktion-Workflow.

Im Leitfaden für das WIQD-Plug-In werden diese Ergebnisse unterschieden:

Vorgang Ergebnis Verbleibende Aktion
wiqd plugin publish Übermittlung an den App-Katalog der Tenant organization Administratorgenehmigung, bevor Benutzer das Plug-In entdecken können
wiqd plugin share Direkter Zugriff für benannte Benutzer oder den Mandanten Überprüfen der autorisierten Zielgruppe, der Installation und der Verbindungen
wiqd plugin package gefolgt von Partner Center-Einreichung Paket für einen Public-Store-Prozess vorbereitet Partner Center Einreichung, Zertifizierung und Veröffentlichung werden nicht durch WIQD automatisiert

WIQD dokumentiert keine Plugin-Registrierung, Slot-Heraufstufung oder Rollback-Befehl. Legen Sie das unterstützte Ersatz- oder Wiederherstellungsverfahren vor der Veröffentlichung fest, und gehen Sie nicht davon aus, dass ein Paketupdate separat betriebene Dienste oder Berechtigungen wiederherstellt. Folgen Sie Verbessern und aktualisieren Sie Ihr Plug-In für die Rollout-Überprüfung und Wiederherstellungsplanung.

Beweismittel aufbewahren und Kandidaten sauber bereinigen

Bewahren Sie die für die Rückverfolgung eines genehmigten Updates erforderlichen Nachweise auf, ohne die Anmeldeinformationen des Mandanten oder Bewertungsdaten nicht autorisierten Lesern zugänglich zu machen.

  1. Bewahren Sie die genehmigte Quellrevision, das WIQD-Release, die Paketidentitäten und -versionen, die bereinigten Validierungs- und Bewertungsergebnisse sowie den Veröffentlichungsstatus bei.
  2. Schränken Sie den Zugriff auf Auswertungsergebnisse ein, da Eingabeaufforderungen und Antworten Organisationsdaten enthalten können.
  3. Überprüfen Sie das Produktionsupdate, bevor Sie einen Bereitstellungskandidaten entfernen.
  4. Wenn ein temporärer Kandidat über eine separate Ressourcenidentität verfügt und nicht mehr benötigt wird, autorisieren Sie seine Löschung ausdrücklich. Verwenden Sie den dokumentierten Befehl zum Löschen des WIQD-Plug-Ins nur für die Umgebung und Identität dieses Kandidaten.

Machen Sie die destruktive Bereinigung nicht zu einer bedingungslosen Pipelinephase oder löschen Sie die Identität des freigegebenen Plug-Ins als Teil der Kandidatenbereinigung. Wenn für Testen und Freigeben dieselbe Identität verwendet wird, löschen Sie sie nicht als temporären Kandidaten.

Verwandte Inhalte

  • Zuletzt aktualisiert um