Jedes externe Plug-in besteht aus einem Logikteil, der in PowerShell geschrieben sein muss, und einem deklarativen Teil, der als XML-Manifestdatei bereitgestellt wird. Diese Dateitypen müssen immer als dynamisches Duo betrachtet werden, das niemals getrennt werden sollte. Daher ist es in der Regel erforderlich, beide Dateien zu aktualisieren, wenn die Plug-in-Funktion geändert wird, z. B. durch Hinzufügen einer neuen Funktion oder Ändern von Funktionssignaturen.
Es gibt einige Eigenschaften, die für jedes Plug-in klar und deutlich definiert werden müssen, damit RayQC das Plug-in-Ressourcenpaket erkennen und in die Checklisten-Workflows integrieren kann:
Plug-in-Name
Jedes externe Plug-in muss einen Namen haben, der im aktuellen Plug-in-Kontext eindeutig ist. Der Plug-in-Name ist auch der Name des Verzeichnisses, das die Plug-in-Skriptlogik und die Manifestdateien enthält. RayQC sucht nach diesen Ressourcenstrukturen, um den Satz verfügbarer Plug-ins für eine bestimmte Checkliste aufzubauen, wenn sie zur Auswertung im Checklisten-Viewer geöffnet wird oder für strukturelle Manipulationen im Checklisten-Editor.
Plug-in-Kontext
Der Plug-in-Kontext ist die Umgebung, die der RayQC-Anwendungsinstanz zum Erstellen oder Auswerten von Plug-in-erweiterten Checklisten zur Verfügung steht. In der Regel ist er auf das lokale Plug-ins-Unterverzeichnis für eine Checklistenvorlage sowie das globale Plug-ins-Unterverzeichnis im RayQC-Anwendungsinstanz-Stammordner beschränkt (in der Regel etwas wie C:\Program Files (x86)\RayQC\).
Da RayQC in der Lage ist, mit gemeinsam genutzten Checklistenressourcen aus verschiedenen Netzwerkstandorten zu arbeiten, ist dieser Kontextbereich ziemlich dynamisch und kann sich bei jedem Checklistenübertragungsvorgang ändern.
Plug-in-Version
Eine weitere wichtige Plug-in-Eigenschaft ist die Version, die bei jeder Aktualisierung der Plug-in-Quellen erhöht werden muss. Sie ist in der Manifestdatei dokumentiert und wird von RayQC verwendet, um zu bestimmen, ob eine Kopie der geparsten Plug-in-Logik, die sich im Sitzungsspeicher befindet, noch auf dem neuesten Stand ist, verglichen mit der auf dem physischen Dateisystem gespeicherten Plug-in-Version.
Auch wenn dies nicht durch technische Einschränkungen gefordert wird, wird dringend empfohlen, mit Versionen zu arbeiten, die unterschiedliche Stufenindikatoren für ihren Aktualisierungsstatus haben. Das einfache Erhöhen von Versionsnummern wie 1, 2, 3, 4 kann sicherlich ausreichen. Die Bereitstellung zusätzlicher Informationen über den Grad der Änderung kann jedoch dazu beitragen, Plug-in-Ressourcen leicht wartbar zu halten. Die empfohlene Plug-in-Versionsstruktur ist [Major Upgrade].[Minor Update].[Small Revision].
Besonders in ausgedehnten QA-Teams ist es sehr praktisch, diese Art von Metainformationen für gemeinsam genutzte Ressourcen bereitzustellen, wenn sie nicht explizit durch Softwareversionierungs- und Revisionskontrollsysteme verwaltet werden.
Plug-in-Signatur
Diese Signatur wird durch die Kombination von Plug-in-Name und -Version gebildet. Als eindeutiger Bezeichner für einen bestimmten Plug-in-Zustand angesehen, kann die kontextweite Best-Practice-Einschränkung für eindeutige Plug-in-Signaturen vor schwerwiegenden Wartungsproblemen bewahren, die auftreten können, wenn Plug-ins nicht gut aufeinander abgestimmt sind.
Stellen Sie sich die Verwirrung vor, die durch unterschiedliche Versionszustände und identische Kopien desselben Plug-ins verursacht wird, die in verschiedenen lokalen und globalen \plug-ins\-Verzeichnissen gespeichert sind: Was passiert mit einer Checkliste, die von einem Repository-Zweig in einen anderen kopiert wird? Stimmt die lokale Version des Plug-ins, die im neuen Kontext bereitgestellt wird, mit der im früheren Kontext verwendeten Version überein? Oder muss der Benutzer die Plug-in-Ressourcen mitkopieren? Was ist, wenn ein Plug-in mit demselben Namen, aber einer anderen Version bereits im neuen Kontext vorhanden ist?
|
Achtung: Es wird dringend empfohlen, eine unternehmensweite Richtlinie für die Bereitstellung eines gut abgestimmten Plug-in-Managements zu definieren. Sie sollte klare Regeln für Versionierung, Benennung, Kopieren und Anpassen von Plug-ins enthalten. Alle Benutzer mit Zugriff auf die Checklisten und Plug-ins sollten diese Richtlinien kennen und deren Bedingungen befolgen. |
