Skip to main content

DevOps auf der IBM i

Die grundlegende Frage: Welches DevOps Tool verwenden?

Zu bedenken ist:

  • Die IT entwickelt sich sehr schnell.
  • Die Anzahl der Möglichkeiten steigt von Jahr zu Jahr.

Bei DevOps geht es darum, die einzelnen Ketten miteinander zu verbinden.

Der DevOps Ring zeigt, die Verkettung der einzelnen Bereiche von der Planung bis zum Deployment.

Für jedes dieser Bereiche gibt es Tools, die dafür verwendet werden.

Nun haben wir 2 Möglichkeiten


 

Proprietäre Lösungen

Sie setzen auf ein All-In-One Tool, welches (fast) alle diese Bereiche abdeckt.

All-In-One

Klar, alles von einem Hersteller hat den großen Vorteil alles aus einer Hand zu bekommen.
Man benötigt sich nur mit 1 Tool auseinander zu setzen und nicht 10.

Wer denk, das Setup eines Tools sei einfacher, schneller, dem muss ich widersprechen.

Einrichtung & Konfiguration

Nach eigener Erfahrung sind sowohl bei den proprietären als auch bei den modularen Lösungen ähnlich viel Aufwand erforderlich.
Abhängig von den verwendeten Tools und der Komplexität der Anwendung.

Integration in andere Systeme

Manche Tools erlauben eine “Integration” mit anderen Systemen.
Bei genauerer Betrachtung findet man jedoch sehr schnell die Grenzen.

Beispiel: Integration mit JIRA

Das Tool kann (falls überhaupt):

  • Den Status eines Tickets im JIRA setzen
  • Kommentare in das JIRA Ticket schreiben
  • Informationen aus dem JIRA Ticket auslesen

Das Tool kann nicht:

  • Schnittstellen für JIRA anbieten
    • JIRA könnte dann die Änderungen in Sourcen nach Zuordnungen zu einem Ticket finden & im JIRA anzeigen
    • JIRA könnte bei bestimmten Prozessen events im Tool auslösen
      Z.B.: Deployment, Test

Fazit:

Diese Tools haben eine sehr begrenzte Integrationsmöglichkeit zu anderen Tools.
Und die Anzahl der Tools mit denen sie sich integrieren lassen, beschränkt sich meist auf 1-2, falls überhaupt.

Die Fragen die man sich stellen muss:

  • Will ich nur die IBM i Welt abgedeckt haben?
  • Sollen auch andere Programmiersprachen oder Systeme verwaltet werden können?
  • Wie sieht die Zukunft aus?
    Wie Flexibel soll die Lösung für künftige Entwicklungen sein?
  • Was ist mein Budget?

Modulare Lösungen

Hier setzen wir auf Tools, welche sich mit anderen Verbinden lassen.

Beispiel:

  • Ticket System
    • Jira
  • Dokumentation
    • Confluence
  • Entwicklungsumgebung
    • RDi
    • Visual Studio Code
    • Notepad ++ (wer das möchte)
  • Build Systeme
    • GNU make für IBM i
    • maven für Java
  • Test & Deployment
    • Jenkins (für IBM i & Java Welt)

All diese Komponenten sind in der Kette des DevOps miteinander verbunden.

So sehe ich im (JIRA-)Ticket welche Sourcen von einem Benutzer, bezogen auf das Ticket, verändert wurden.

Oder ich kann im RDi sehen, auf Basis welchem Ticket, diese eine IF-Anweisung im Code entstanden ist.

Liste der von mir empfohlenen Tools die in einer modularen Lösung miteinander integrierbar sind:

  • Versionsverwaltung
    • Mercurial
    • GIT
    • SVN
  • Entwicklungsumgebungen (IDE)
    • Eclipse (RDi)
      • CL,  RPG & Co
      • Java, PHP
    • Visual Studio Code
      • CL,  RPG & Co
      • Java, PHP
    • Pycharm
      • Python
  • Dokumentation
    • MediaWiki
    • Confluence
  • Ticket System
    • JIRA
  • Build System
    • GNU Make – Für IBM i
    • maven – Für Java
  • Continious Integration & Deployment
    • Jenkins
Proprietäre Lösung Modulare Lösung
Eine Lawine Kosten Großteils kostenlos

Manche PlugIns kosten, sind aber sehr gering

Hoher Aufwand

Großteil muss von Anfang an eingerichtet werden

Konfiguration Hoher Aufwand

Komponenten können Step by Step (Agil) eingerichtet werden

Hersteller Support Hersteller & Community
Einfacher
da nur 1 Tool
Einschulung Einschulung für jedes Tool
Innerhalb des Tools, meist perfekt abgestimmt Kompatibilität Kompatibilitäts-Check vorher notwendig
Gesamte Lösung muss ersetzt werden Umstieg Austausch einzelner Komponenten sehr einfach
Abhängig vom Hersteller Skalierbar Neue Tools können angebunden werden
Nur sehr eingeschränkt möglich Integration in andere Systeme Meist einfach möglich
Jeder Mitarbeiter muss auf diese Lösung eingeschult werden.

Sehr geringe Wahrscheinlichkeit, für bereits vorhandene Skills.

Mitarbeiter  Sehr hohe Wahrscheinlichkeit für bereits vorhandene Skills.

Ist auf Technischen Schulen & Unis Alltag.

Meist gar nicht oder durch hohe kosten nur sehr eingeschränkt möglich Systemübergreifend Hier gibt es kaum Einschränkungen da eine sehr hohe Kompatibilität mit der IBM i.
Gibt es schon fertige Lösungen, die lediglich konfiguriert werden müssen Deployment Prozess Falls vorhanden können bestehende Skripts/Programme wiederverwendet werden.

Ansonsten müssen diese erstellt werden

Langsam

Meist nur wenige Entwickler

Weiterentwicklungs-geschwindikteit Schnell

Hinter den einzelnen Modulen stecken eine große Anzahl an Entwickler

 

 
Facebook
Facebook
XING
Twitter