Git Integration
Basierend auf dem Package Management 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 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 Automation Engine, werden zugefügt.
Ordner des Package, die nicht in der Automation Engine existieren werden angelegt.
Ordner des Package, die sich nicht im Git-Repository befinden, aber in der 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 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 Repositorys: Index erzeugt werden. Anschließend aktualisieren die Module Versionskontrolle: Zweige anlegen und Versionskontrolle: Check-In 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.
globaler Git-Repository-Index
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.