Stolpersteine bei der Adaption von Verknüpfung und Collaboration Wie wird Mainframe Git weniger überwältigend?

Anbieter zum Thema

BMC Software GmbH GB Remedy

Windhoff Group

Vor nicht allzu langer Zeit waren „Mainframe“ und „Git“ Wörter, die nicht zusammenzupassen schienen. Und jetzt?

Die Beliebtheit von Git bei Entwicklern und Entwicklerinnen in der verteilten Welt ist kein Fehler. Feature-Branches, verteilte Entwicklung, Pull-Requests und eine stabile Community führen letztlich zu einem schnelleren Release-Zyklus. Diese Funktionen erleichtern einen agilen Arbeitsablauf, bei dem die Developer ermutigt werden, kleinere Änderungen häufiger auszutauschen. Im Gegenzug werden Änderungen schneller in die Bereitstellungspipeline eingespeist als die monolithischen Releases, die bei zentralisierten Versionskontrollsystemen üblich sind.

Und die umfangreichen Collaboration-Funktionen von Git ermöglichen es, dass Änderungen von mehreren Personen geprüft und in einer Quelle zusammengeführt werden können. In Verbindung mit neueren Entwicklern, die bereits mit der Verwendung von Git vertraut sind, ist Git eine überzeugende Lösung für die Quellcodeverwaltung (SCM).

Die Übertragung des Ansatzes auf den Mainframe

Die Verknüpfung von Techniken zwischen verschiedenen Plattformen kann eine Herausforderung sein, muss es aber nicht. So kann der Erfolg von Git bei der verteilten Entwicklung auf dem Mainframe dupliziert werden, wenn er richtig geplant wird. Die Verwendung von Git als Mainframe-SCM bietet Gemeinsamkeiten und bricht Silos auf, mit dem Vorteil, dass alle Assets an einem Ort gespeichert werden.

Bei der Planung der Einführung von Git ist es wichtig zu bedenken, dass Git nur ein SCM ist und keine Build- und Deployment-Prozesse abwickelt. Ein bestehendes Mainframe-SCM-System kann diese Aufgaben übernehmen. Es wäre also ratsam, Git für diese Aufgaben zu integrieren, anstatt es zu ersetzen.

Was wie eine einfache Kompilierung aussieht, ist in Wirklichkeit komplex, da die richtigen Copybooks und zugehörigen Programme benötigt werden. Darüber hinaus muss berücksichtigt werden, wie sich die Änderungen auf verwandte Programme auswirken, und es muss ein Weg gefunden werden, sie zuverlässig in die Produktion zu überführen und gleichzeitig mit den entsprechenden verteilten Anwendungen zu koordinieren.

Was sollten diejenigen, die Git auf dem Mainframe einsetzen wollen, sonst noch tun?

Die Gründe erläutern – ein Teil der Planung für Git besteht darin, die Gründe zu nennen. Warum sollten Teams den Wechsel zu Git in Erwägung ziehen? Es ist wichtig, dass die Entwicklerinnen und Entwickler die Probleme und Vorteile verstehen, damit sie eine fundierte Entscheidung für ihre Teams treffen können.

Schrittweise Umstellung – nach dem Zeitplan arbeiten. Teams können auf Git umsteigen, wenn sie bereit sind (und manche Teams werden vielleicht nie auf Git umsteigen – ein wichtiger Punkt). Widerstände sind verständlich, wenn alle Anwendungen auf einmal umgestellt werden müssen, was zu Störungen führen kann. Stattdessen empfiehlt sich ein schrittweiser Ansatz, bei dem die Anwendungen auf Git umgestellt werden, wenn die Teammitglieder dazu bereit sind.

Automatisierte Builds – Sie sollten sicherstellen, dass sie über ein automatisiertes Verfahren verfügen, mit dem sie die für ihre Builds erforderlichen Beziehungen herstellen und sicherstellen können, dass alle Kompilierungsparameter und Auswirkungen genutzt werden können. Der Build sollte auch mit ihrer Bereitstellungsstrategie integriert werden.

Bereitstellungskonfigurationen verwalten – Sie sollten Bereitstellungsunterbrechungen vermeiden, indem sie sicherstellen, dass ihre Mainframe-Bereitstellungen für die Zusammenarbeit mit Digital.ai, Cloudbees Flow und HCL Launch konfiguriert und verfügbar sind.

Zugehörige Tools verwenden – Einer der Gründe für den Wechsel zu Git als SCM ist die Nutzung des zugehörigen Lösungs-Ökosystems, zum Beispiel fortschrittliche Code-Review-Tools, mit denen Development-Teams Pipelines zur Automatisierung ihrer Aufgaben erstellen können.

(ID:50008265)