Git Integration

../_images/vcs.png

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.

    ../_images/vcs-advanced.png
  • 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

    ../_images/vcs-user.png

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