Developer Tool – Lou400

Das Tool ist ein Quellen- und Objektmanagementwerkzeug. Es organisiert die Tätigkeiten des Entwicklers, begleitet und unterstützt ihn von der Planung bis zur Installation einer Softwareadaption. Im Gegensatz zu anderen Source-Management-Werkzeugen die plattformunabhängig arbeiten, ist das Developer Tool auf die Eigenarten des IBM i-Systems bzw. der DB2 eingestellt und darauf abgestimmt. Demnach werden zum Beispiel nicht nur die Quellen unterstützt, sondern auch Objekte. Die Organisation von Versionen und Installationen über das Developer Tool sind auf die Entwicklung von Individualsoftware ausgelegt und unterstützen eine prompte Reaktion seitens der IT auf Fachabteilungs-, Kunden- bzw. Marktwünsche.

Definition, Protokollierungen und weitere Informationen sorgen für die nötige Nachvollziehbarkeit und Transparenz des gesamten Entwicklungsprozesses.

Abgetrennt von anderen Bereichen werden Einstellungen sowie Applikationsparameter festgelegt.

Applikationen/Ebenen/Hierarchien
Vererbungseinstellungen
Container
Element-Regeln
Standard-Befehle
Element bzw. spezifische Arten
Systeme, Stages, Partitionen, Umgebungen

Jetzt abonnieren!

Aktuell beliebt:

Zwischen Kundenbedarf und Problemlösung: Geballte Power

IBM i reloaded: Was der neue Technology Refresh 7.5 TR2 wirklich kann

iNew Suite – frischer Wind für Ihre IBM i

In vielen Unternehmen ist di...

I. Quellen und Objekte

a. Der Request
… ist ein abgekapselter Entwicklungsbereich. Sämtliche Eingriffe seitens des Entwicklers erfolgen in diesem Bereich. Abgetrennt von den Umgebungen und den Tätigkeiten anderer aber jedem Entwickler zugänglich. Der Request ist mit einem „Ticket“ eines Berichtsassistenzsystems vergleichbar. Es konzentriert sich dabei vollständig auf den Entwicklungsprozess um diesen so effizient wie möglich unterstützen zu können. Aus technologischen bzw. organisatorischen Gründen entstehen meist mehr Requets zu einem „Ticket“. Gegebenenfalls können solche Verknüpfung, Verwandtschaften und Verbindungen abgebildet und nachvollzogen werden. Aktionen innerhalb eines Requests haben den Aufbau einer individuellen Entwicklungsumgebung für diesen Request zur Folge. Sämtliche Versionen die davor oder zum selben Zeitpunkt ausgeliefert werden, werden dafür herangezogen.

Detailinformationen:

Applikationszuordnung
Freitextbeschreibung
Versionszugehörigkeit
Aktueller Entwickler
Referenzen Extern (Verbindung zu Berichtsassistenzsysteme)
Referenzen Intern (Verbindung zu anderen Requests)

Weitere Möglichkeiten eines Requests, welche den Unternehmenswünschen anpassbar sind:

Klassifizierung (z.B.: Wartung, Änderungsanforderung, Projekt)
Verrechnung (z.B.: Aufwand, Pauschal)
Aufwandserfassung (z.B.: Stundenangabe, automatische Berechnung, erzwungene Eingabe)
Organisationsinformationen (Organisator, Status, Fortschritt)
Entwicklungsstatus, verschiedene Prioritäten, Farbeinstellungen, Aktivitäten und mehr

b. Das Element
… ist frei definierbar. Unterstützt werden hierbei Quellen (Teildateien), kompilierte Objekte sowie Objekte welche auf keiner Quelle basieren (ist bis zu Streamfiles oder Datenbankeneinträge erweiterbar). Für den Entwickler auf einer Ebene dargestellt und bearbeitbar, vereinfachen die Elemente den Überblick und erhöhen die Effektivität was schließlich der Qualität zugutekommt.

Typisierung
Beschreibung
Version
Elementartspezifische Informationen

c. Die Markierung
Werden Elemente bearbeitet erfolgt dies über eine Markierung. Jede Markierung kann nur unter gewissen Voraussetzungen gesetzt werde. Diese Voraussetzungen werden, wenn es die Situation erlaubt, aufgrund eines strengen Regelwerks automatisch geschaffen um ein flüssiges Arbeiten zu gewährleisten.

*NEW Neue, dem System noch nicht bekannten, Elemente
*CHECKOUT stellt das Element für die Entwicklung zur Verfügung
*CHANGE Änderung der Element-Kopfinformationen (Beschreibung, Art)
*DELETE markiert ein Element für eine Löschung (wird zum Zeitpunkt des *CHECKINs durchgeführt)
*DISPLAY zeigt das Element an
*EDIT editieren des Elements
*FREEZE friert eine Elementversion ein; eine andere Version wird zuvor installiert
*SPRINT Elementversion wird von neuerer Version innerhalb derselben Release überschrieben
*INFO zeigt Markierungsinformationen bzw. Markierungsverlauf an
*MOVE verschiebt Element in fremde Request
*REMOVE entfernt Element aus der Entwicklung
*SHORT zeigt Kurzinformation der Markierung an
*UNDO macht Elementmarkierung rückgängig (bei *DELETE anzuwenden)

Die *CHECKIN Markierung wird zum Zeitpunkt der Installation gesetzt. Sie kann nicht vom Entwickler auf einzelne Elemente angewendet werden, dient aber der Nachvollziehbarkeit der Elementveränderung im Zuge eines Release.

Durch die *SUPPORT Markierung kann dem Werkzeug von außen eine Version zugefügt bzw. überschrieben werden. Dies dient für Schnittstellen zu anderen, ähnlich gelagerten Werkzeugen wie zum Beispiel Generatoren.

d. Der Entwicklungsstatus
Der Entwicklungsprozess wird vorrangig durch den Entwicklungsstatus auf Requestebene dargestellt. Der Status wird dem Unternehmensprozess angepasst und wie folgt gesteuert:

Eröffnet (*OPEN)
Ist außerhalb einer Version.
Arbeiten zeigen nur innerhalb dieses Requests Auswirkung.
Request wird von keiner anderen Arbeit beeinflusst.
Entwicklung (*DEVELOP)
Ist außerhalb einer Version.
Arbeiten zeigen nur innerhalb dieses Requests Auswirkung.
Request wird von anderen Arbeiten beeinflusst.
Integration (*INTEGRATE)
Ist innerhalb einer Version.
Arbeiten zeigen in allen anderen versionsübereinstimmenden Requests Auswirkung.
Sammlung (*RELEASE)
Request ist für eine Release bereit.
Betrieb (*LIVE)
Dies ist ein automatischer Status, welcher im Zuge der Installation ausgelöst und gesetzt wird.

II. Versionen und Releases
Um Planung und Nachvollziehbarkeit zu gewährleisten werden Softwareversionen mit Auslieferungszeitmarken verbunden. Um praxisnahe Reaktionen zu ermöglichen werden Releases, Patches, Fixes unterstützt sowie Sprints der Scrum-Entwicklungsmethode.

III. Rollouts und Installationen
Versionen können via Rollout-Mechanismus in die Applikation oder zu Testzwecke in davor gelagerte Bereiche installiert werden.
Es werden unterschiedliche Umgebungen unterstützt. Empfohlen werden mindestens zwei bis drei unabhängige Umgebungen für die Entwicklungs- und Testprozesse und eine, von allen anderen unabhängigen, Produktionsumgebung.
Umgebungs- bzw. Systemunabhängige Daten ermöglichen den Überblick auf alle Umgebungen und ihre installierten Versionen.
Die Bereitstellung und Installation erfolgt unter bestimmten Prozess- bzw. Status-Voraussetzungen, immer über denselben Mechanismus und mit denselben Instruktionen. Damit ist ein reibungsloser Ablauf der Installation im Produktionsbetrieb gewährleistet da sämtliche Befehle, Konvertierungen und Installationsprogramme getestet werden.

a. Umgebungen
Eine Umgebung ist ein unabhängiger Bereich, in der die Applikation läuft und arbeitet. Je nach Applikationsarchitektur und Unternehmensinfrastruktur, werden mehr Umgebungen auf einem System oder mehr Systeme existieren und unterstützt.

b. Instruktionen
Die Inbetriebnahme erfolgt Großteiles mit automatisierten Mechanismen. Allerdings können technologische Gründe es erforderlich machen bzw. aus Gründen der Kompatibilität notwendig werden spezielle Befehle, SQL-Statments oder Hilfsprogramme als Release-Instruktion ausführen zu lassen.

Release Instruktionen können…

für eine Installation im Allgemeinen,
für einen einzelnen Request oder
für ein einzelnes Element

… definiert werden. Pro Anweisung können eine Vielzahl an Einstellungen erfolgen um die Instruktionen praxisnah und effizient abzulegen (Reduktion von Befehls-Redundanz).