Zum Hauptinhalt springen
Version: 6.1

Git Integration

Basierend auf dem PM kann für die Entwicklung in der Automic Automation mit der Git Integration noch ein weiteres wichtiges Werkzeug aus der Softwareentwicklung genutzt werden. Damit Entwickler den Stand ihrer Implementierungen jederzeit sichern und auch wieder herstellen können ist die Verwendung eines Versionskontrollsystems wie Git häufig im Einsatz. Um auch bei der Entwicklung für die Automic Automation solche Funktionalitäten nutzen zu können gibt es die Module der Git Integration. Diese stellen eine Schnittstelle zu einem GIT-Repository zur Verfügung. Damit können Implementierungsstände von Packages in Repositories gesichert und wiederhergestellt werden.

Regeln für den Abgleich​

Beim Abgleich der Objekte mit dem Git-Repository werden folgende Regeln angewendet:

  • Alle Objekte des Package, die sich im Git-Repository befinden werden mit der Version überschrieben.
  • Alle Objekte des Package, die sich in der Automic Automation Engine befinden und sich nicht im Git-Repository befinden, werden gelöscht.
  • Alle Objekte des Package, die sich im Git-Repository befinden und nicht in der Automic Automation Engine, werden zugefügt.
  • Ordner des Package, die nicht in der Automic Automation Engine existieren werden angelegt.
  • Ordner des Package, die sich nicht im Git-Repository befinden, aber in der Automic Automation Engine, werden gelöscht.

Die Regeln für Ordner treffen auch auf leere Ordner zu.

Zweige​

Um Entwicklern zu erlauben mehrere Versionen eines Package zu unterstützen, bringen die b4A Module die Möglichkeit Zweige im Git-Repository zu öffnen. Zwischen den Zweigen kann beliebig gewechselt werden und jeder Stand in einem Zweig kann mit einem Marker (Tag) versehen werden, dass zu jedem Zeitpunkt wiederhergestellt werden kann. Dies erlaubt eine hohe Flexibilität bei der Umsetzung. Im Folgenden wird ein Konzept vorgestellt wie mit Zweigen und Markern umgegangen werden kann. Es ist ausschließlich ein Beispiel und die Verwendung kann von dieser Vorgehensweise abweichen.

1. Beispiel

Es wird davon ausgegangen, dass es genau einen Zweig gibt, der alle Versionen beinhaltet, die jemals im produktiven System installiert worden sind. Entwickler können beliebig viele Zweige für Entwicklungsversionen öffnen. Sobald eine Entwicklungsversion aus einem anderen Zweig als stabil angesehen wird kann diese in den Zweig für produktive Systeme eingespielt werden und einem Tag versehen werden.

2. Beispiel

Wie im ersten Beispiel können die Entwickler beliebig viele Zweige für Entwicklungsstände eröffnen. Die produktiven Versionen werden allerdings nicht in einem einigen Zweig gehalten, sondern es wird für jeden Minor-Release ein eigener Zweig genutzt, der nach dem Muster <Major>.<Minor> genannt wird. Sollten Korrekturen für einen bestimmten Minor-Release notwendig sein, dann werden diese in dem jeweiligen Zweig des zugehörigen Minor-Releases gesichert und mit einem Tag markiert.

Repository​

Alle Module, für die Anbindung an ein Git-Repository, müssen die Adresse sowie notwendige Zugangsdaten für das Repository kennen. Dafür haben alle Module einige Konfigurationseinstellungen.

Repository URL
Die URL zu dem Git-Repository. Beispiele
Arbeitsverzeichnis
Der Pfad zu einem Verzeichnis in dem die Arbeitskopie gespeichert wird.

VCS Benutzer
Der Benutzername für den Zugang zum Repository, falls eine Authentisierung notwendig ist
VCS Passwort
Das Passwort für den Zugang zum Repository, falls eine Authentisierung notwendig ist
VCS Passwortdatei (Kommandozeile)
Auf der Kommandozeile steht als Alternative zur Option VCS Passwort auch diese Option zur Verfügung mit der das Passwort

°

Index​

In einigen Szenarien, gerade bei der Verwendung von PromptSets, kann es hilfreich sein die Liste der Git-Repositorys und deren Branches in der Automic Automation Engine zwischengespeichert zu haben, da der Zugriff darauf schneller funktioniert. Dazu kann optional ein Index aufgebaut werden, der den Zugriff auf die Package-Git-Repositorys ermöglicht.

Um den Git-Repository-Index zu nutzen, muss dieser initial einmalig mit dem Modul b4A Modul vcs.Index erzeugt werden. Anschließend aktualisieren die b4A Module vcs.BranchCreate und vcs.Push automatisch den Index. Diese Module erfordern einen exklusiven Zugriff auf die Index-Variable. Ist die Variable gerade schreibend geöffnet, dann warten diese Module bis die Variable schreibend geöffnet werden kann.

Anders als beim Package-Index gibt es hier nur die globale Variante. In der Konfigurationsdatei vcs.conf wird ein Mandant in einer Umgebung ausgewählt (Benennung einer b4A Verbindung) in dem für alle Git-Repositorys der Index geschrieben wird. Empfohlen wird hier den Entwicklungsmandanten zu nutzen. Der verwendete Key wird dabei in der Konfigurationsdatei vcs.conf festgelegt.

Konfiguration​

Die Einstellungen für die Module der Git-Integration befinden sich in der Datei vcs.conf.

Sollte sich das Git-Repository hinter einem HTTP-Proxy befinden, kann dieser in der Konfigurationsdatei conf/vcs.conf festgelegt werden.

vcs-http-proxy-host
Name des Proxy-Servers
vcs-http-proxy-port
Port auf dem der Proxy erreichbar ist
vcs-repository-pattern
Wird dieser Wert gesetzt, kann damit für alle Versionskontrollsystem-Module ein Repository vorgegeben werden. Dieser Wert ist eine b4A Expression, die den Parameter package enthalten kann.
vcs-type
Backend für den Zugriff auf ein Versionskontrollsystem. Aktuell wird ausschließlich GIT unterstützt
vcs-index-folder
Ordner in dem das Objekt des Git-Repository-Indexes gespeichert wird
vcs-index-variable
Name der XML-Variable des Git-Repository-Indexes
vcs-index-repositories-key
Key in der XML-Variable in dem der Git-Repository-Index zu finden ist
vcs-index-connection
Diese Einstellung definiert, in welcher Verbindung die XML-Variable zu finden ist.
vcs-index-exclusive-open-interval
Ein Interval in Millisekunden, das genutzt wird, um beim exklusiven Öffnen des Index, festzulegen wie lange zwischen Versuchen gewartet wird.