Vier Tipps zur DevOps-Integration mit der SAP Cloud Platform
Eine erfolgreiche DevOps-Implementierung zusammen mit der SAP Cloud Platform beginnt mit dem Verständnis verschiedener Best Practices. Vier Tipps für den Einstieg.
Unabhängig davon, ob man DevOps nur für die SAP Cloud Platform implementiert oder einen hybriden Ansatz wählt, bei dem die Plattform ein Bestandteil ist, ist es wichtig zu wissen, wie sich die einzigartigen Aspekte der SAP Cloud Platform auf eine DevOps-Strategie auswirken.
DevOps hat das Ziel, den Entwicklungsprozess agiler und effizienter zu gestalten und gleichzeitig die mit Veränderungen verbundenen Risiken zu reduzieren. Es handelt sich um eine Reihe von Prozessen, Technologien sowie Entwicklungs- und Betriebspraktiken, die in einem Großteil der Technologiebranche unterschiedlich übernommen wurden. Mittlerweile begehen viele SAP-Entwicklungsteams den DevOps-Pfad. Teams, die mit der SAP Cloud Platform arbeiten, bilden da keine Ausnahme.
Eine DevOps-Implementierung muss auf die Entwicklungs- und Betriebsplattformen zugeschnitten sein, die von den Administratoren verwendet werden. Hier sind vier Tipps zur Implementierung von DevOps für die SAP Cloud Platform.
1. Eine gemeinsame DevOps-Toolchain einsetzen
Verwenden Sie ein Enterprise-Git-Repository, falls vorhanden, und setzen Sie nicht auch die Git-Repositorys der SAP Cloud Platform. Der gleiche Rat gilt für Continuous Integration Tools wie Drone und Jenkins, Agile-Management-Tools wie Jira und Azure DevOps und Monitoring Tools.
Für Teams, die mit den im Rest des Unternehmens verwendeten Tools nicht vertraut sind, oder für Unternehmen, die diese Art von DevOps-Toolchain nicht einsetzen, ist es verlockend, einfach die Tools der SAP Cloud Platform zu verwenden.
Dies kann jedoch langfristige Kosten in Form von unnötigem Lock-in und eingeschränkten Funktionen zur Folge haben. So fehlen der Git-Repository-Infrastruktur der SAP Cloud Platform zum Beispiel die meisten Funktionen von GitHub Enterprise, Bitbucket, GitLab und Azure DevOps. Sie kann außerdem unnötig komplex sein, um von außerhalb der SAP Cloud Platform darauf zuzugreifen.
2. Externe Entwicklungssoftware zulassen
Wenn ein Schreiner zur Arbeit geht, bringt er sein eigenes Werkzeug mit. Warum also verlangen wir von qualifizierten Entwicklern, dass sie nicht ihre eigenen Tools verwenden, um die Arbeit zu erledigen? Der obligatorische Einsatz von Enterprise-Entwicklungs-Tools erzeugt reale Kosten in Bezug auf Laufzeit und Zugang. Dies sind Kosten, die IT-Profis in der SAP-Welt seit langem bezahlen, ohne nachzufragen.
Einige DevOps-Tools sollten gemeinsam genutzt werden, zum Beispiel Systeme für die Versionskontrolle, Ticketing-Systeme und Build-Systeme. Diese Tools sollten jedoch über Standardschnittstellen verfügen, die es Entwicklern ermöglichen, sich mit ihren bevorzugten Tools zu verbinden.
Eine DevOps-Implementierung muss auf die Entwicklungs- und Betriebsplattformen zugeschnitten sein, die von den Administratoren verwendet werden.
WebIDE sollte der Standard sein, erfordert aber nicht, dass Ihre Entwickler es verwenden. Erledigen Sie die Arbeit, um die Infrastruktur rund um die SAP Cloud Platform aufzubauen, damit Entwickler frei ihre Tools verwenden können. Die gute Nachricht ist, wenn Sie bereits mit der geteilten DevOps-Toolchain, wie oben vorgeschlagen, begonnen haben, sind Sie fast am Ziel.
3. Subkonten für mehrstufige Landschaften verwenden
Eine Sache, mit der viele Kunden zu kämpfen haben, ist die Frage, welche der vielen Abstraktionen für Schichtenarchitekturen zur Verfügung stehen. Sollen Entwicklungs-, QS- und Produktionsumgebungen unterschiedliche Anwendungen, unterschiedliche HANA-Bereiche oder verschiedene Unterkonten sein? Die Antwort ist, dass man separate Unterkonten für verschiedene Umgebungen verwenden sollte. Dies kann zu einer überraschenden Anzahl an Infrastrukturdoppelungen führen, denn wenn man die HANA-Datenbank verwendet, muss man möglicherweise drei separate HANA-Instanzen für eine dreistufige Landschaft ausführen.
Um diese Dopplungen zu reduzieren, überlegen Sie, ob Sie Ihre DevOps-Infrastruktur nutzen können, um eine Schicht zu entfernen. Wenn Sie beispielsweise das Cloud Application Programming Model (CAPM) verwenden, benötigen Sie wirklich noch eine Entwicklungsschicht? Oder können Entwickler lokal mit CAPM Node.js und einer SQLite-Datenbank entwickeln?
4. Proprietäre SAP-Tools nutzen, wo es angemessen ist
SAP verfügt in der Cloud Platform über viele proprietäre Tools, die einen hohen Mehrwert bieten. Sollten Sie diese nutzen oder an einer gemeinsamen Infrastruktur festhalten, die vielleicht nicht so gut für den jeweiligen Einsatz geeignet ist? Die Antwort: beides. Vielleicht ist SAP Mobile Services genau das Richtige für Offline-Anwendungen. Oder vielleicht haben Sie eine Reihe von ABAP-Entwicklern, die in einer Cloud-Umgebung etwas entwickeln, und für die die SAP Cloud Platform ABAP-Umgebung perfekt ist. Oder vielleicht sind Cloud ALM, Translation Services oder einer der vielen Leonardo Machine Learning Services genau das, was man benötigt.
Finden Sie heraus, wie Sie diese Dienste in Ihre gemeinsame DevOps-Toolchain, Prozesse und Entwicklungspraktiken so integrieren können, dass sie mit dem Rest Ihres Unternehmens funktionieren. Manchmal bedeutet dies, diese Dienste in Abstraktionsschichten zu packen, um lokale Entwicklung und Tests zu ermöglichen. Manchmal bedeutet es, dass Sie kleine Erweiterungen Ihrer DevOps-Toolchain benötigen, um diese Dienste unterzubringen. Und es kann Momente geben, in denen die Dienste gut konzipiert sind, um sie in Ihre bestehenden Praktiken zu integrieren und ohne zusätzliche Arbeit einzubinden.
Wie bei so viel anderem ist der beste Tipp, die Details zu lernen und sich dann die Zeit zu nehmen, das Gesamtbild zu betrachten, um sicherzustellen, dass die Entscheidungen, die Sie treffen, strategisch ausgerichtet sind, um langfristig Wert für Ihr Unternehmen zu schaffen.
