Wie man Mainframe-DevOps mit Git + BMC AMI DevX Code Pipeline supercharget

Immer mehr Mainframe-Organisationen wechseln entweder zu Git oder sprechen davon, zu Git umzusteigen. Traditionell existierte der Mainframe als separate Plattform mit eigenem Set an Tools und Prozessen, die von anderen Plattformen im Unternehmen wie Cloud, Mobile oder Web abgeschirmt waren. Mit zunehmender Einführung in DevOps beginnen diese Mauern jedoch zu fallen. Viele Organisationen nutzen verteilte Tools wie Jenkins oder GitHub Actions, um ihre Continuous Integration/Continuous Delivery (CI/CD)-Pipelines zu orchestrieren. Viele nutzen auch Tools wie SonarQube, um ihren Quellcode zu scannen, und Veracode, um Sicherheit zu gewährleisten. Es ist nur natürlich, dass Organisationen beginnen, Git, den De-facto-Standard für Versionskontrolle und Quellcodemanagement (SCM), als Quellcode zu nutzen. Aber das allein bringt keine Ergebnisse – man braucht etwas, das die restlichen DevOps-Prozesse wie Build und Deployment bewältigen kann. Um Ihr DevOps auf die nächste Stufe zu heben, müssen Sie Git mit einem erstklassigen Build- und Deployment-System wie der BMC AMI DevX Code Pipeline kombinieren, um Ihr DevOps zu beschleunigen.

Warum Git, warum gerade jetzt?

Die Wahl von Git ist einfach. Es ist das dominierende SCM-System in der Branche und es gibt viele Gründe, es zu übernehmen.

• Es wurde mit Blick auf das Entwicklererlebnis entwickelt. Egal, ob Sie natives Git oder eine der beliebten Remotes wie GitLab, GitHub oder Bitbucket verwenden – Git wurde entwickelt, um das bestmögliche Nutzererlebnis zu bieten und die tägliche Entwicklung zu erleichtern. Git bietet viele integrierte Funktionen, um das Entwicklererlebnis zu verbessern, wie Vergleich, Zusammenführen und die einfache Freigabe von Änderungen.
• Git unterstützt mehrere Sprachen und verschiedene Methodologien zum Arbeiten. So wie es verteilte Sprachen wie Java, C, Node oder Python unterstützt, kann es auch Cobol, JCL, Rexx, PL1, Assembler oder jede andere Quellsprache unterstützen, die für Großrechneranwendungen notwendig ist.
• Es bietet Verzweigungsunterstützung, um parallele Entwicklung zwischen Teams und Einzelpersonen zu ermöglichen. Git ermöglicht es einem Nutzer, eine isolierte Umgebung für Entwicklung oder F&E zu erstellen und diesen Code dann wieder in den Hauptbranch oder Trunk einzuführen.
• Git ermöglicht es Organisationen, ihre Software Delivery Lifecycle (SDLC)-Prozesse unabhängig von der Plattform zu konsolidieren. Der Mainframe wird keine isolierte Plattform mehr sein, wenn er dasselbe Tool und denselben Prozess wie der Rest der Organisation verwendet.
• Es erleichtert das Onboarding neuer Entwickler und stärkt weniger erfahrene Ingenieure auf der Mainframe-Plattform. Hochschulabsolventen und jüngere Ingenieure haben bereits Erfahrung, da sie von Anfang an auf Git-Systemen geschult wurden. Sie kommen mit einem GitHub-Konto oder einem Äquivalent und nutzen Git in ihrem Studium.
• Git-Plattformen sind offen und leicht in fast jedes System zu integrieren. Aufgrund ihrer umfangreichen Nutzung unterstützen fast alle DevOps-Tools oder -Umgebungen bereits Git, und Git-Systeme unterstützen die meisten Plattformen und Werkzeuge.

Wie funktioniert Git mit der BMC AMI DevX Code Pipeline?

Jetzt verstehen wir Git, aber wie funktioniert es mit der BMC AMI DevX Code Pipeline , um ein DevOps-System auf nächster Ebene zu schaffen? Sie fragen sich vielleicht: "Verarbeitet die BMC AMI DevX Code Pipeline nicht selbst den Quellcode?" Ja, die BMC AMI DevX Code Pipeline verarbeitet den Quellcode zusätzlich zu Geschwindigkeit, Agilität, Qualität und Geschwindigkeit in der Handhabung des Quellcodes. Aber wie oben beschrieben, gibt es viele Gründe, warum eine Organisation Git einbauen möchte, um die BMC AMI DevX Code Pipeline zu ergänzen, sodass Git das tun kann, was es am besten kann, zusätzlich zu den erstklassigen Build- und Deployment-Fähigkeiten der BMC AMI DevX Code Pipeline auf dem Großrechner. Git auf dem Großrechner zu verwenden, unterscheidet sich nicht davon, Git auf einer anderen Plattform oder mit einer anderen Codebasis zu verwenden. Ein Entwickler würde Code in eine lokale Umgebung verzweigen und mit Änderungen beginnen. Im Rahmen dieses Prozesses rufen sie die BMC AMI DevX Code Pipeline auf, um den Bau und die Ausführung von Unit-Tests in ihrer lokalen Umgebung zu übernehmen. Sobald abgeschlossen und mit den Änderungen zufrieden ist, stellt der Entwickler eine Pull Request, um die Änderungen in den Hauptzweig einzuführen. An diesem Punkt werden die Änderungen überprüft und, falls abgeschlossen, wieder in den Hauptzweig eingegliedert. Das unterscheidet sich nicht von einem verteilten Entwickler, der in Java arbeitet. Dies ist jedoch nicht die einzige Interaktion, die die BMC AMI DevX Code Pipeline mit Git hätte. Da die Änderungen nun abgeschlossen und in den Hauptzweig integriert sind, müssen sie bereitgestellt werden. Dank des Open-Borders-Ansatzes der BMC AMI DevX Code Pipeline werden alle Funktionen, die zur Förderung und Bereitstellung Ihrer Änderung notwendig sind, über die API bereitgestellt, sodass die BMC AMI DevX Code Pipeline nun auch zur Bereitstellung Ihrer Änderungen genutzt werden kann. Um dies noch einfacher zu machen, wurde ein Jenkins-Plugin entwickelt, das diese Aufgabe übernimmt und leicht von Ihrem Git-System aus ausgelöst werden kann. Falls Sie kein Jenkins haben, wurden dieselben Integrationen für andere beliebte Orchestrierungstools wie GitHub Actions und Azure DevOps entwickelt, um nur einige zu nennen. Neben einer API für alles können unsere Expertenteams Ihnen helfen, einen Deployment-Flow für Ihre Pipelines zu erstellen. Wenn dein Mainframe in denselben Prozess und CI/CD-Tools eingebettet ist, die du für die übrigen Plattformen deiner Organisation nutzt, kannst du die Bereitstellung über verschiedene Teams hinweg koordinieren, sodass Änderungen, die auf den Mainframe übertragen werden, gleichzeitig mit Änderungen in der Cloud oder anderen verteilten Systemen bereitgestellt werden können.

Muss wirklich jeder auf Git wechseln?

Die Antwort lautet einfach: "Nein." Wie bei allem ist dies keine Einheitslösung. Git hat viele Vorteile und kann in jeder Situation eingesetzt werden, aber es passt möglicherweise nicht zu jedem Team oder jeder Anwendung. Mit der BMC AMI DevX Code Pipeline kann man einen hybriden Entwicklungsansatz innerhalb der Organisation verfolgen, sodass Teams entscheiden können, ob der Wechsel zu Git das Richtige für sie ist. Schauen wir uns ein Beispiel mit zwei Teams an, Team A und Team B. Team A unterstützt eine Anwendung im Wartungsmodus, ohne wirkliche neue Entwicklung, und sie bereiten Patches und Updates nur ein- bis zweimal pro Jahr aus. Team B unterstützt eine sehr aktive App, die monatlich, wöchentlich oder vielleicht sogar täglich bereitgestellt wird. Für Team A macht der Übergang zu Git wenig Sinn, und sie würden nur begrenzte Vorteile daraus ziehen. Für Team A wäre die Verwendung der traditionellen Mainframe-Entwicklungsmethode in Ordnung. Team B möchte jedoch zu Git wechseln und würde viele Vorteile aus den Fähigkeiten von Git ziehen. Typischerweise müssten entweder Team A oder Team B den Wünschen des anderen Teams entsprechen – aber nicht mit der BMC AMI DevX Code Pipeline. Die BMC AMI DevX Code Pipeline ermöglicht einen hybriden Entwicklungsansatz, bei dem ein Team Git und das andere Team die BMC AMI DevX Code Pipeline für alle Entwicklungsbedürfnisse nutzen kann. Dies ermöglicht Flexibilität innerhalb der Organisation und bietet Wahlmöglichkeiten, damit jedes Team die beste Entscheidung für sich selbst treffen kann.

Wo sollte ich anfangen?

Nach all dem fragen Sie sich vielleicht: "Wo fange ich an? Lege ich einfach etwas Code in Git und fange an zu arbeiten?" Das geht schon, aber das ist vielleicht nicht der beste Anfang. Wie bei allem wird ein phasenbasierter Ansatz bevorzugt, um die Risiken einer größeren Transformation zu verringern. Mit einer nachgewiesenen Erfolgsbilanz hat BMC einige Schritte, um Ihnen zu helfen, erfolgreich auf Git umzusteigen und Ihr Mainframe-DevOps zu beschleunigen.

• Schritt 1: Migrieren Sie von Ihrem alten Mainframe-SCM-System auf die BMC AMI DevX Code Pipeline. Egal, ob Sie eine andere SCM-Lösung oder ein selbstentwickeltes Tool haben – der Übergang von diesem System zu einem modernen, agilitätsorientierten Tool wie der BMC AMI DevX Code Pipeline ist ein wichtiger erster Schritt, um sich auf den Erfolg vorzubereiten. Wenn Sie bereits die BMC AMI DevX Code Pipeline haben, sind Sie bereits ein Drittel des Weges. Falls nicht, können die professionellen Dienste von BMC bei der Migration aus Ihrem alten System helfen, sodass Sie sofort von den Vorteilen profitieren können.
• Schritt 2: Automatisiere alle deine Prozesse und lass deine Pipelines aufbauen. Integriere deine bestehenden DevOps-Tools mit der BMC AMI DevX Code Pipeline und beginne, alles zu automatisieren, was du kannst. Gewöhne deine Teams an Automatisierung und DevOps und beginne, deinen Prozess so effizient wie möglich zu gestalten.
• Schritt 3: Bewerten Sie alle Ihre Teams und beginnen Sie, sie bei Bedarf auf Git zu migrieren. Sie haben Ihre Pipelines bereits eingerichtet und Ihre Prozesse automatisiert, jetzt ist es an der Zeit, Ihre Teams zu bewerten und diejenigen zu übernehmen, die auf Ihr Git-Angebot umsteigen und sich in die für die BMC AMI DevX Code Pipeline definierten Pipelines einschließen wollen. Auch hier bietet BMC Professional Services Scripting, das Ihnen helfen kann, Ihren Quellcode, Ihre Historie und Metadaten auf Git zu übertragen.

Die gemeinsame Nutzung von Git und der BMC AMI DevX Code Pipeline ermöglicht es Organisationen, Mainframe-Workloads mit der Geschwindigkeit und Effizienz zu verwalten, die nur DevOps bieten kann. Dadurch wird sichergestellt, dass Code an einem Ort gepflegt wird, der parallele Entwicklung fördert und sofort verständlich ist, während gleichzeitig nahtloses und präzises Erstellen, Testen und Bereitstellen von Code ermöglicht wird. Um diese Konzepte genauer zu erkunden, laden Sie unser eBook Git für den Mainframe herunter.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.