Bereitstellungsprozess für einen Windchill Navigate Build
Der Bereitstellungsprozess umfasst das Einreichen und Erhöhen von Paketen in verschiedenen Umgebungen. Das Ziel ist es, sicherzustellen, dass das Paket in jeder Phase gründlich getestet und validiert wird, bevor die endgültige Bereitstellungsumgebung erreicht wird.
Der Bereitstellungsprozess für Navigate umfasst die folgenden Schritte:
1. Die anfängliche Bereitstellung in einer niedrigeren Umgebung
2. Reifekurvenphase
3. Die endgültige Bereitstellung in der Produktionsumgebung
Stellen Sie sich folgendes Szenario vor: Ihr Team wählt anhand der aktuellen Anforderungen einen Anwendungsfall aus und integriert den Anwendungsfall dann in den Sprint-Zyklus. Der Prozess umfasst das Einreichen und Erhöhen Ihres Pakets durch verschiedene Phasen. Stellen Sie das Paket zunächst in einer niedrigeren Umgebung bereit, indem Sie es einreichen. Ihr Paket wird in der Reifekurvenphase erhöht. Die endgültige Erhöhung erfolgt in der letzten Bereitstellungsphase.
Detaillierte Prozessbeschreibung
1. Erste/ursprüngliche Build-Bereitstellung – Die erste Build-Bereitstellung, die PTC vom Kunden erhält, wird vom PTC Team gründlich geprüft. Zu den erforderlichen Artefakten für diese Prüfung gehören:
◦ Ausgefüllter Fragebogen: Ein detaillierter Fragebogen, der vom Kunden ausgefüllt wird.
◦ Build-Paket: Ein gezipptes Paket, das von Kunden/Systemintegratoren eingereicht wird.
 | Der ursprüngliche Build wird nur dann zum nächsten Schritt weitergeleitet, wenn das PTC Team ihn genehmigt und sicherstellt, dass er den erforderlichen Richtlinien entspricht. |
2. Reifekurvenphase – Diese Phase erfordert keine Genehmigung durch das PTC Team. Während dieser Phase durchläuft der Build eine Reifekurve, die die folgenden Aufgaben umfasst:
◦ Fehlerbehebungen: Probleme identifizieren und beheben
◦ Logikänderungen: Funktionalität des Builds verfeinern
◦ Benutzerakzeptanztests (User Acceptance Testing, UAT): Sicherstellen, dass der Build die Benutzeranforderungen erfüllt.
◦ Kosmetische Änderungen: Benutzeroberfläche und Benutzererlebnis anpassen
Die ursprüngliche Bereitstellung erfolgt in einer Nicht-Produktionsumgebung. Ein Kunde oder Systemintegrator ist für eine umfassende Dokumentation aller Änderungen verantwortlich, die am Build vorgenommen werden.
| | Es ist entscheidend, dass die vom Build-Paket adressierten Anforderungen und die Build-Abhängigkeiten (von Drittanbieterbibliotheken) während dieses Prozesses unverändert bleiben. Wenn Änderungen auftreten, müssen Sie den Bereitstellungsprozess neu starten. |
3. Endgültige Build-Bereitstellung in der Produktionsumgebung – Die endgültige Bereitstellung auf dem Produktserver wird vom PTC Team einer gründlichen und umfassenden Prüfung unterzogen. Diese Prüfung stellt sicher, dass alle Aspekte des Builds den höchsten Standards in Bezug auf Qualität, Funktionalität und Konformität entsprechen, bevor er in der Produktionsumgebung freigegeben wird. Zu den Artefakten, die für diese Prüfung benötigt werden, gehören:
◦ Ausgefüllter Fragebogen: Ein detaillierter Fragebogen, der vom Kunden ausgefüllt wird.
◦ Build-Paket: Ein gezipptes Paket, das von Kunden/Systemintegratoren eingereicht wird.
◦ Ausführliche Dokumentation: Umfassende Dokumentation aller Änderungen, die während der Reifephase am Build vorgenommen wurden. Weitere Informationen finden Sie im Abschnitt "Vollständige Dokumentation erstellen: Wichtige Richtlinien".
| | Diese Phase muss vom PTC Team genehmigt werden. |
Richtlinien für Kunden
• Konsistenz der Anforderungen – Der erste Build, den Sie hochladen, muss alle wichtigen Inhalte enthalten. Für den Systemintegrator ist es von entscheidender Bedeutung, dass während der beiden Bereitstellungsphasen – erste und dritte Phase – keine signifikanten Änderungen der Anforderungen oder Abhängigkeiten (insbesondere von Drittanbieterbibliotheken) eingeführt werden.
• Gründliche Dokumentation – Sie müssen alle am Build vorgenommenen Änderungen umfassend dokumentieren.
• Prüfung durch das PTC Team – Das PTC Team prüft alle Ihre Änderungen, bevor der Build für die endgültige Bereitstellung in der Produktionsumgebung erhöht wird.
Wenn Sie sich an diese Richtlinien halten, können Sie einen sicheren und stabilen Bereitstellungsprozess für Ihren Windchill Navigate Build sicherstellen.
Wie oft muss der Bereitstellungsprozess wiederholt werden?
Wenn Sie eine Anpassung in Betracht ziehen, haben Sie einen bestimmten Anwendungsfall im Sinn und ein Entwicklungsteam, das in Sprint-Zyklen arbeitet. Ihr Team greift einen Anwendungsfall auf, bei dem es sich um eine Anforderung oder einen Satz von Anforderungen handeln kann, und beginnt mit der Entwicklung in Sprint-Zyklen. Manchmal sind mehrere Sprint-Zyklen erforderlich, um den Build vorzubereiten.
In einem sechsmonatigen Release-Zyklus mit fünf Sprints werden beispielsweise Anforderungen ausgewählt und innerhalb dieser Sprints entwickelt. Möglicherweise haben Sie unterschiedliche Zeitachsen, z.B. 20-Tage-Sprints mit Entwicklungs-, Qualitätssicherungs- und Bereitstellungsphasen. Wenn sich die Anforderungen während des Zyklus erheblich ändern, muss der Prozess neu gestartet werden, und es sind Genehmigungen erforderlich.
Die Häufigkeit des Bereitstellungsprozesses hängt von der Anzahl der Anwendungsfälle und Sprint-Zyklen ab. Wenn Sie beispielsweise 10 Anwendungsfälle in 10 Sprint-Zyklen entwickeln, wird der Prozess 10 Mal durchlaufen. Wenn Sie 5 Anwendungsfälle in einem Sprint-Zyklus entwickeln, wird der Prozess zweimal durchlaufen.
Weitere Beispiele:
1. Beispiel 1: Kürzere Sprint-Zyklen
◦ Sie haben einen 2-wöchigen Sprint-Zyklus. Sie wählen eine Anforderung aus, entwickeln sie 10 Tage lang, wenden 2 Tage für die Qualitätssicherung auf, und stellen sie dann bereit. Wenn Sie 6 Anforderungen haben, durchlaufen Sie den Prozess 6 Mal in 12 Wochen.
2. Beispiel 2: Überlappende Anforderungen
◦ Sie haben überlappende Anforderungen, die sich über mehrere Sprints erstrecken. Beispielsweise durchläuft eine Anforderung, die 3 Sprints benötigt, den Prozess für jeden Sprint einmal, um eine kontinuierliche Integration und ein kontinuierliches Testen zu gewährleisten.
3. Beispiel 3: Wesentliche Änderungen in der Mitte des Zyklus
◦ Wenn Sie eine wichtige Änderung an einer Anforderung in der Mitte des Zyklus vornehmen, z.B. am Datenmodell, müssen Sie den Prozess neu starten. Dadurch wird sichergestellt, dass alle Abhängigkeiten neu ausgewertet und Genehmigungen eingeholt werden.
4. Beispiel 4: Häufige Bereitstellungen
◦ Sie bevorzugen häufige Bereitstellungen und haben einen 1-wöchigen Sprint-Zyklus. Sie entwickeln 4 Tage lang, machen die Qualitätssicherung 1 Tag lang und nehmen am letzten Tag die Bereitstellung vor. Mit 8 Anforderungen durchlaufen Sie den Prozess 8 Mal in 8 Wochen.
5. Beispiel 5: Benutzerdefinierte Zeitachsen
◦ Sie legen benutzerdefinierte Zeitachsen fest, die auf Ihren Projektanforderungen basieren. Sie haben beispielsweise einen 30-tägigen Sprint-Zyklus mit 20 Tagen Entwicklung, 5 Tagen Qualitätssicherung und 5 Tagen Bereitstellung. Sie passen die Prozesshäufigkeit basierend auf der Anzahl der Anforderungen und deren Komplexität an.
Welche Informationen sind im Fragebogen enthalten?
Während des Bereitstellungsprozesses müssen Sie zwei Fragebögen ausfüllen:
1. Fragebogen zur ursprünglichen Bereitstellung – Dieser Fragebogen ist für die erste Bereitstellung in einer niedrigeren Umgebung erforderlich. So wird sichergestellt, dass alle vorläufigen Prüfungen und Konfigurationen vorhanden sind, bevor Sie fortfahren.
2. Fragebogen zur endgültigen Bereitstellung – Dieser Fragebogen ist für die endgültige Bereitstellung in einer niedrigeren Umgebung erforderlich. So wird überprüft, ob alle kritischen Aspekte geprüft und genehmigt wurden, um eine reibungslose und erfolgreiche Bereitstellung zu gewährleisten.
Ein Beispiel für einen Fragebogen sieht folgendermaßen aus:
Frage | Antwort | |
|---|---|---|
Allgemeine Details | Ihr Kundenkontoname | |
Ihre Windchill Version | ||
Ihre Windchill Navigate Version | ||
Ihr geplantes Bereitstellungsdatum | ||
Ihre geplante Bereitstellungsumgebung | ||
Paketdetails | Haben Sie dieses Paket in niedrigeren Umgebungen getestet? (Wenn ja, benennen Sie die Umgebung.) | |
Welche Arten von Anpassungen haben Sie implementiert? | ||
Werden Drittanbieterbibliotheken in diesem Paket verwendet? | ||
Verwenden Sie die Standardauthentifizierungsmethode, oder basiert dieses Paket auf Anwendungsschlüsseln? | ||
Welcher Geschäftsanwendungsfall oder welches Ziel soll mit dieser Anpassung erreicht werden? | ||
Haben Sie sichergestellt, dass kein Teil der Anpassung die Leitlinien verletzt? | ||
Worin unterscheiden sich das alte Paket und das neue Paket (falls vorhanden)? |
| | In diesem Fragebogen müssen Sie alle Unterschiede zwischen dem alten und dem neuen Paket beschreiben. Sie können z.B. erklären, ob neue Funktionen hinzugefügt, Fehler behoben oder Änderungen bei der Versionsnummer vorgenommen wurden. Diese Unterschiede sind wichtig, da sie dazu beitragen, dass alle am Bereitstellungsprozess Beteiligten verstehen, was sich geändert hat. Dies kann Probleme verhindern, Kompatibilität sicherstellen und gewährleisten, dass das neue Paket alle Anforderungen erfüllt. |
Vollständige Dokumentation erstellen: Wichtige Richtlinien
Wenn Sie den endgültigen Build zur Bereitstellung in der Produktionsumgebung einreichen, ist es wichtig, eine umfassende Dokumentation aller Änderungen einzuschließen, die während der Reifephase vorgenommen wurden. In dieser Dokumentation sollten alle Aktualisierungen, Funktionserweiterungen, Fehlerkorrekturen und Revisionen, die während des Entwicklungsprozesses aufgetreten sind, detailliert beschrieben werden.
Mit einer umfassenden Dokumentation stellen Sie sicher, dass alle Beteiligten über die Änderungen informiert sind, was bei der Problembehandlung, Aufrechterhaltung der Konsistenz und Überprüfung, ob der Build alle Anforderungen erfüllt, hilfreich ist. Dieser Schritt ist für eine reibungslose und erfolgreiche Bereitstellung unerlässlich, da das Fehlerrisiko minimiert und dadurch sichergestellt wird, dass die Produktionsumgebung vollständig auf den neuen Build vorbereitet ist.
Betrachten Sie das folgende Szenario:
In der Regel beginnen Sie einen Build-Zyklus mit Version 1.0. Wenn Sie den Build in den nachfolgenden Phasen überarbeiten, aktualisieren Sie ihn u.U. auf Versionen wie 1.1, 1.2 usw. Wenn der Build für die Bereitstellung auf dem Produktionsserver bereit ist, wurde er bis zur endgültigen Version, beispielsweise 1.7 möglicherweise mehrmals überarbeitet.
Sie sollten die Änderungen, die während jeder Revision vorgenommen werden, detailliert protokollieren. Wenn Sie beispielsweise 5 Elemente ändern, dokumentieren Sie diese Änderungen deutlich. Diese Dokumentation kann in Form von Versionshinweisen erfolgen, die je nach Produkt unterschiedlich groß sind.
Die Dokumentation kann z.B. Folgendes enthalten:
• Version 1.4.6: Es wurde eine Fehlerbehebung für ein bestimmtes Problem hinzugefügt.
• Version 1.4.5: Implementierung einer neuen Funktion.
• Version 1.4.4: Verbesserte Leistung für eine bestimmte Funktion.
Mit diesem Dokumentationstyp lässt sich der Verlauf des Builds von Version 1.0 bis 1.7 nachvollziehen. Sie können Screenshots oder ein anderes Format verwenden, das die relevanten Informationen am besten vermittelt. Entscheidend ist, dass eine umfassende Änderungsverfolgung sichergestellt wird. Sie entwickeln das Format nach Ihren Bedürfnissen, sei es ein Word-Dokument, ein Excel-Blatt oder eine andere Methode.
Es folgen Beispiele für ein Änderungsprotokoll:
Beispiel 1 – Kurzes Änderungsprotokoll: einzeilige Zusammenfassung zur Schnellreferenz
Beispiel 2 – Detailliertes Änderungsprotokoll: umfassende Liste der Aktualisierungen
Beispiel 3 – Umfassendes Änderungsprotokoll: eine umfassende Zusammenstellung von Aktualisierungen, Fehlerbehebungen und Verbesserungen
