Pakete einreichen und erhöhen
Wenn das CCD-Paket bereit ist, verwenden Sie die automatisierte Build-Bereitstellung, um fortzufahren. Der automatisierte Build-Bereitstellungsprozess umfasst die Orchestrierung der Erhöhung Ihrer Konfiguration und Anpassung in Übereinstimmung mit Ihren Berechtigungen und der Systemlandschaft.
Sie können einen Build einreichen, indem Sie ein CCD-Paket und eine Manifestdatei an die entsprechenden Speicherorte in Ihrem Speicherkonto hochladen. Sie müssen das CCD-Paket zuerst unter /data/builds hochladen. Dann müssen Sie die Manifestdatei unter /data/builds/deploy hochladen.
Diese Aktion löst den automatisierten Build-Bereitstellungs-Workflow aus. Der Prozess wird durch Benachrichtigungsaufgaben gesteuert, die per E-Mail empfangen werden. Die Informationen in der E-Mail führen Sie durch die verschiedenen Schritte. Die Aufgabengenehmiger werden in der Manifestdatei deklariert. Ein Beispiel für eine Manifestdatei finden Sie im Thema Automatische Bereitstellung auslösen.
 |
Beachten Sie die folgenden Punkte als Voraussetzung:
• Sie müssen einen Azure-BLOB-Speicherort festlegen. Die Autorisierungsdetails müssen aus der PTC Cloud abgerufen werden.
◦ PTC stellt Ihnen eine SAS-URL für diese Aktivität bereit.
◦ Sie sollten eine Anfrage über das PTC Support-Portal senden, damit Ihre IP-Adresse in die Zulassungsliste aufgenommen wird. Geben Sie in den Details für den Fall eine stabile IP-Adresse an.
• Sie müssen eine Anfrage senden, um die Pipeline so konfigurieren zu lassen, dass sie mit dem in der Manifestdatei genannten Wert übereinstimmt. Beispiele sind int1 oder pipeline1. Weitere Informationen zum Attribut deploy_pipe finden Sie im Abschnitt "Manifestdatei erstellen" im Thema Automatisierte Bereitstellung auslösen.
|
Der erste Schritt des Workflows für die automatisierte Build-Bereitstellung ist die Prüfung des CCD-Pakets. Das System überprüft das CCD-Paket, um festzustellen, ob es den Richtlinien von Windchill+ entspricht. Nach der Prüfung generiert das System die Berichte und stellt sie im Speicherkonto zur Verfügung.
Die Berichte und Protokolle finden Sie unter: /data/builds/logs/<RITM Number>/. Die Syntax der generierten Berichte und Protokolldateien ist wie folgt:
• Berichtssyntax: cwave_<CustomerShortName>_<Date-Time>_<Control Label>.html. <Control Label> kann IntakeProcessor, SpotBugs, Logs usw. sein.
• Protokollsyntax: ccd_<environment>_<Date-Time>_<ant target>_Logs.zip. <ant target> kann deploy, load usw. sein. Weitere Informationen finden Sie unter Targets
|
Berichtsname
|
Implementierte Prüfungen
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Windchill+ Prüfungen (in Windchill+ zulässige Anpassung, veraltet, nicht unterstützte APIs, Sicherheit)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
Statische Codeprüfung (bewährte Vorgehensweisen für Java)
|
Beachten Sie die folgenden Punkte:
• Wenn das CCD-Paket bei einer der Prüfungen fehlschlägt, werden Sie benachrichtigt, und der Einreichungsprozess wird angehalten.
• Wenn das CCD-Paket konform ist, wird der Prozess fortgesetzt, und der Build wird auf das in der Manifestdatei definierte Ziel erhöht.
• Sobald eine Build-Bereitstellung erfolgreich ist, haben Sie sieben Tage Zeit, um die Tests abzuschließen.
|
|
Als Kunde sind Sie für den Inhalt des CCD-Pakets verantwortlich. Indem Sie einen Build einreichen, bestätigen Sie, dass die Entwicklung in Übereinstimmung mit PTC Sicherheitsrichtlinien erfolgt ist. Informationen zu den PTC Sicherheitsrichtlinien finden Sie unter Sicherheitsanpassungsrichtlinien.
|
Windchill+ Leitlinien für die Zusammensetzung von CCD-Paketen
Ihr CCD-Paket und dessen Zusammensetzung müssen einer bestimmten Verzeichnisstruktur entsprechen. Beachten Sie die Leitlinien für die Verzeichnisstruktur und den Dateiinhalt eines CCD-Pakets:
• Ein CCD-Paket darf maximal 100 MB groß sein.
• Das CCD-Paket kann die folgenden Ordner enthalten:
|
Ordner
|
Beschreibung
|
|---|---|
|
Configurations
|
keinen oder nur einen Configurations-Ordner
|
|
Generated
|
keinen oder nur einen Generated-Ordner
|
|
customlib
|
keinen oder nur einen customlib-Ordner
|
|
<custom module(s)>
|
Einen oder mehrere benutzerdefinierte Modulordner
|
|
|
Mindestens einer der vier Ordner muss im CCD-Paket vorhanden sein.
|
• Die Datei descriptor.xml muss in allen benutzerdefinierten Modulordnern Ihres CCD-Pakets vorhanden sein.
• Der Ordner Generated kann leer sein oder einen oder beide der folgenden Ordner enthalten:
◦ Ordner db – Der Ordner db kann leer sein. Andernfalls muss er die Datei db/conf/SchemaConfig.xml enthalten.
◦ Ordner BAC – Es darf nur eine gezippte BAC-Datei im Ordner BAC enthalten sein. Die BAC-Zuordnungen können in der Datei Mapping.xsl im Ordner BAC angegeben sein.
◦ Der customlib sollte IP-JAR-Dateien für Partner enthalten, sofern vorhanden.
• Die zulässigen Angebotswerte sind "plusselect" und "meddev".
• Ein CCD-Paket muss frei von blockierten oder unerwarteten Dateien sein, gemäß den folgenden Regeln:
◦ Liste der im Paket unzulässigen Dateien – .jar, .class, .exe, .ser, .sql, .ddl, .pks, .pkb, .ora, .jasper, .cs, .cpp, .so, .dll, .jnilib, .dylib, .h, .cgf, .out, .ldif, .sh,.pl, .groovy, .gwt.xml, .gwt.modules.xml
◦ Zulässige Dateien im Ordner xconf – .xconf
◦ Zulässige Dateien im Ordner conf – .xml,.ini
◦ Zulässige Dateien im Ordner resources – .tpl, .bas, .ddx, .html, .yml, .xjb, .ftl, .xml, .dtd, .xsl, .properties, .txt, .ini, .json, .js
◦ Zulässige Dateien im Ordner src – .java, .rbInfo
◦ Zulässige Dateien im Ordner jsp – .jsp, .jspf
◦ Zulässige Dateien im Ordner tags – .tag, .tagf
◦ Zulässige Dateien im Ordner tlds – .tld
◦ Unzulässige Dateien im Ordner src_web – .java
◦ Gültiger Pfad für Ordner JasperReports – module/main/resources und module/main/src_web (nicht gültig auf Konfigurationsebene)
◦ Gültige Dateien im Ordner JasperReports im Ressourcenpfad – .jrxml, .jasperProperties und .properties
◦ Gültiger Dateityp innerhalb des Ordners JasperReports unter Pfad src_web – .gif
◦ Zulässige Dateien im Ordner customlib – .jar
◦ Ordner mit dem Namen apps sind in den folgenden Ordnern nicht zulässig:
▪ configurations/resources
▪ main/resources
▪ main/src_web
Diese Leitlinien werden geprüft, wenn das Paket für die Bereitstellung eingereicht wird. Jede Nichteinhaltung wird gemeldet. Die Bereitstellungsprotokolle enthalten einen RITM-Zusammenfassungsbericht, z.B. RITM0910921.txt. Dieser Bericht informiert darüber, ob das Paket mit den Windchill+ Leitlinien im Einklang steht. So sieht ein RITM-Zusammenfassungsbericht beispielsweise aus:
Die ausführlichen RITM-Protokolle finden Sie in einem gezippten Detailbericht. Die ZIP-Datei enthält Details zur Leitlinienprüfung. Die ZIP-Datei enthält eine Protokolldatei mit Details zur Leitlinienprüfung.
Eine ZIP-Datei lautet beispielsweise RITM0910921_Reports.zip.
Eine Protokolldatei lautet beispielsweise preValidate_20240402-142645.log.
| | Obwohl diese Regeln nicht durchgesetzt werden, müssen Sie auf Abweichungen achten und diese aktiv korrigieren. PTC kann einige dieser Regeln in Zukunft erzwingen, und jede Nichteinhaltung wird das Paket danach ungültig machen. Mehr Details zu unzulässigen Anpassungen und Warnungen finden Sie unter Disallowed Customization. |
Vor dem Go-Live
Sie können Windchill+ auch ohne die Qualitätssicherungsumgebung verwenden. Sie können das erweiterte Windchill+ auch mit der QS-Umgebung verwenden. Je nach Szenario können Sie die Schritte befolgen, die in den folgenden Ansätzen beschrieben werden:
Erweitertes Windchill+ mit QS-Umgebung
Führen Sie die folgenden Schritte aus, wenn Sie das erweiterte Windchill+ mit der Qualitätssicherungsumgebung verwenden:
1. Senden Sie Ihr Paket an die Integrationsumgebung für den Integrations- und Funktionsakzeptanztestzyklus. Dieser Testzyklus kann häufig ausgelöst werden. Zum Beispiel mehrmals pro Woche.
◦ Senden Sie eine Build- und Manifestdatei mit deploy_pipe : int.
Weitere Informationen finden Sie unter Deploying Code and Configuration Package (auf Englisch).
◦ Schließen Sie den Testzyklus ab. Am Ende des Testzyklus wird die Aufgabe als abgeschlossen betrachtet und der vorherige Status der Umgebung wird wiederhergestellt.
| | Wenn dieser Schritt nicht innerhalb von sieben Tagen abgeschlossen wird, wird die Umgebung automatisch auf den vorherigen Status zurückgesetzt. |
2. Reichen Sie Ihr Paket in die QS-Umgebung für UAT ein, und erhöhen Sie das Paket dann in die Produktionsumgebung. Der UAT-Testzyklus sollte ein- oder zweimal im Monat ausgelöst werden, da dieser Prozess den Build in die Produktionsumgebung überführt.
◦ Senden Sie eine Build- und Manifestdatei mit deploy_pipe : pipeline. Weitere Informationen finden Sie unter Deploying Code and Configuration Package (auf Englisch).
◦ Schließen Sie den Testzyklus ab. Beachten Sie die folgenden Punkte:
▪ Wenn der Testzyklus erfolgreich ist, wird die Aufgabe genehmigt, und der Build wird auf die Produktionsumgebung erhöht.
▪ Wenn der Testzyklus nicht erfolgreich ist, wird die Aufgabe zurückgewiesen, und die Umgebung wird auf den vorherigen Status zurückgesetzt.
▪ Wenn der Testzyklus nicht innerhalb von sieben Tagen abgeschlossen wird, wird die Umgebung auf den vorherigen Status zurückgesetzt.
Grundlegendes Windchill+ ohne QS-Umgebung
Führen Sie die folgenden Schritte aus, wenn Sie ein grundlegendes Windchill+ Select ohne die QS-Umgebung verwenden:
1. Senden Sie eine Build- und Manifestdatei mit deploy_pipe : int. Weitere Informationen finden Sie unter Deploying Code and Configuration Package (auf Englisch).
2. Schließen Sie den Zyklus von Integrations- und Funktionsakzeptanztest ab. Am Ende des Testzyklus ist die Aufgabe abgeschlossen, und der vorherige Status der Umgebung wird wiederhergestellt.
| | Wenn dieser Schritt nicht innerhalb von sieben Tagen abgeschlossen wird, wird der vorherige Status der Umgebung wiederhergestellt. |
3. Reichen Sie denselben Build und eine aktualisierte Manifestdatei erneut mit deploy_pipe : pipeline ein. Weitere Informationen finden Sie unter Deploying Code and Configuration Package (auf Englisch).
4. Schließen Sie den Benutzerakzeptanztestzyklus in der Integrationsumgebung ab. Beachten Sie die folgenden Punkte:
◦ Wenn der Testzyklus erfolgreich ist, wird die Aufgabe genehmigt, und der Build wird auf die Produktionsumgebung erhöht.
◦ Wenn der Testzyklus nicht erfolgreich ist, wird die Aufgabe zurückgewiesen, und die Umgebung wird auf den vorherigen Status zurückgesetzt.
◦ Wenn der Testzyklus nicht innerhalb von sieben Tagen abgeschlossen wird, wird die Umgebung automatisch auf den vorherigen Status zurückgesetzt.
| | Alle Testaktivitäten verwenden nur eine Umgebung. Das System kann jeweils nur eine Testaktivität ausführen. Wenn ein Build mit deploy_pipe : int während dieses Zeitraums gesendet wird, wird er automatisch zurückgewiesen. |
Go-Live-Phase
Nachdem Sie die Go-Live-Phase bestätigt haben, ist es erforderlich, die Produktionsumgebung in den QS- und Integrationsumgebungen erneut zu hosten.
Sie müssen eine Serviceanfrage im PTC Support-Portal für diese Aktivität öffnen. Weitere Informationen finden Sie unter Serviceanfrage öffnen.
Ausführungsstatus
• Nach einem erfolgreichen Go-Live werden alle Umgebungen aus der Produktionsumgebung erneut gehostet. Daher empfiehlt PTC dringend, die Änderungen auf die Entwicklungsumgebungen zu übertragen. Der empfohlene Ansatz ist, BAC zu verwenden und ein vollständiges BAC-Paket aus der Integrationsumgebung zu exportieren. Weitere Informationen finden Sie unter BAC-Pakete mit dem CCD-Dienstprogramm importieren.
Beachten Sie die folgenden Punkte:
◦ Ein Datenmodell ist das Minimum, das Sie exportieren müssen, um Ihr System neu zu erstellen (Typ- und Attribut-Manager).
◦ Für Objekte, die von BAC nicht unterstützt werden, können Sie entweder aus der Integration aus der Benutzeroberfläche exportieren (wenn möglich) oder die Ladedatei in Ihrer Entwicklungsumgebung neu erstellen.
• Danach ähnelt der Einreichungszyklus dem Zyklus, der im Abschnitt "Vor dem Go-Live" im Thema "Paket einreichen und erhöhen" beschrieben wird.
• Nach dem Haupt-Go-Live müssen Sie Ihre Produktionsumgebung in den QS- und Integrationsumgebungen erneut hosten. Eine Serviceanfrage muss für das erneute Hosten von Aktivitäten geöffnet werden. Weitere Informationen finden Sie unter Serviceanfrage öffnen.
| | • Nach einem erfolgreichen ersten Go-Live sollten alle Umgebungen (mit Ausnahme der Entwicklung) erneut aus der Produktion gehostet werden. Dieses erneute Hosten erfolgt nicht automatisch und erfordert eine Serviceanfrage. • Das anfängliche Go-Live bezieht sich auf die erste Bereitstellung der Anwendung in der Produktionsumgebung. In dieser Phase werden alle niedrigeren Umgebungen mit der Produktion synchronisiert, um Konsistenz und Stabilität in der gesamten Bereitstellungslandschaft sicherzustellen. • Ein wesentliches Go-Live bezieht sich auf jede nachfolgende Version der Produktionsumgebung nach dem ersten Go-Live. Diese Versionen enthalten in der Regel neue Funktionen, Verbesserungen oder Fehlerbehebungen und sind Teil des fortlaufenden Entwicklungs- und Bereitstellungszyklus. |