Eine Pipeline für Windchill sieht aus wie die Pipeline jeder anderen Unternehmensanwendung, mit zwei Unterschieden: Die Anwendung ist groß und startet langsam, und ihre Konfiguration ist genauso wichtig wie ihr Code. Hier ist der Aufbau, den wir verwenden, und die Reihenfolge, in der wir ihn umsetzen.
1. Versionskontrolle für alles
Customizing, Build-Skripte, Deployment-Skripte und so viel exportierbare Konfiguration wie möglich liegen in Git. Änderungen kommen über Pull Requests mit einem zweiten Reviewer. Was nicht in Git liegt, kann die Pipeline nicht ausrollen, und genau darum geht es.
2. Einmal bauen
Die Pipeline kompiliert das Customizing aus einem getaggten Commit und erzeugt ein einziges versioniertes Artefakt: ein Paket für virtuelle Maschinen oder ein Docker-Image für Kubernetes. Dieses Artefakt wird unverändert von Test nach Produktion weitergereicht. Wer für jede Umgebung neu baut, lädt Abweichungen ein.
3. In drei Schichten testen
- Unit-Tests für die Geschäftslogik, die in Sekunden und ohne Windchill-Server laufen.
- API-Tests, die Ihre REST-Endpunkte und Services auf einer frisch ausgerollten Instanz aufrufen.
- Smoke-Tests, die einige kritische Abläufe durchspielen: Teil anlegen, Dokument einchecken, Änderung freigeben.
Windchill startet langsam, deshalb halten wir die Teststufe auf der ausgerollten Instanz fokussiert. Eine kurze Suite, die bei jedem Merge läuft, ist mehr wert als eine lange, die einmal im Monat läuft.
4. Mit einer Entscheidung weiterreichen
Das Deployment in Produktion wartet auf eine Freigabe, und diese wird zusammen mit den von der Pipeline erzeugten Release Notes dokumentiert. Auditoren schätzen das. Engineers auch, denn die Frage, was sich geändert hat und wer zugestimmt hat, ist an einer Stelle beantwortet.
5. Verifizieren und einen Rückweg behalten
Nach dem Deployment prüft die Pipeline die Health-Endpunkte und führt die Smoke-Tests erneut aus. Ein Rollback rollt das vorherige Artefakt wieder aus. Wir testen ihn regelmäßig, denn ein Rollback, der nie gelaufen ist, ist eine Hoffnung, kein Plan.
Wo Sie anfangen sollten
Wenn Releases heute manuell laufen, beginnen Sie mit den Stufen 1 und 2: Git und ein automatisierter Build. Sie beseitigen das meiste Risiko mit dem geringsten Aufwand, und jede weitere Stufe baut darauf auf.