So nutzen Sie die Vorteile von GitHub-Aktionen mit 4D

Ihr Projekt befindet sich jetzt in einem Versionskontrollsystem. Das bedeutet, dass es jetzt viel einfacher ist, mehrere Versionen Ihrer Software zu verwalten, Änderungen zu überwachen und Korrekturen oder neue Funktionen zu integrieren.

Warum nicht auch die Vorteile der kontinuierlichen Integration nutzen?

Ab 4D v19 können Sie die Kompilierung Ihres Projekts mit einem Befehl starten. Damit verfügen Sie über alle Bausteine, um Ihre Integrationskette zu automatisieren.

In diesem Blogbeitrag finden Sie ein Beispiel für die Automatisierung mit dem GitHub Manager und GitHub Actions.

Was ist eine GitHub-Aktion?

GitHub-Aktionen ermöglichen es Ihnen, Aufgaben zu automatisieren. Sie werden durch Ereignisse wie die Einreichung von Code ausgelöst.

Warum GitHub-Aktionen?

Die Automatisierung von Arbeitsabläufen ist in der heutigen Welt der Softwareentwicklung ein Muss. Entwicklungsteams verwenden CI/CD-Server, um die Prozesse der kontinuierlichen Integration und Bereitstellung (CI/CD) in ihrem Software-Lebenszyklus zu automatisieren.

Mit GitHub Actions können Benutzer ihren Code direkt von GitHub aus erstellen, testen und bereitstellen, ohne einen externen Server wie Jenkins oder TeamCity zu verwenden. GitHub hostet virtuelle Maschinen auf den Betriebssystemen Linux, Windows und macOS.

Wie verwendet man GitHub Actions?

Sie müssen einen Workflow erstellen. Ein Workflow ist ein automatisierter Vorgang, den Sie zu Ihrem Repository hinzufügen. Auf der Registerkarte „Aktion“ können Sie einen aus dem Katalog der Workflows auswählen oder einen eigenen erstellen.

In diesem Beispiel verwenden wir den von Github vorgeschlagenen „einfachen Workflow“:

Dadurch wird ein Skript im Ordner „.github/workflows“ unseres Repositorys erstellt. In diesem Skript können Sie definieren:

  • das Trigger-Ereignis: bei Push/Pull/Schedule
  • das Betriebssystem der virtuellen Maschine:runs-on

Weitere Details zu den Syntaxen und Möglichkeiten finden Sie in der GitHub-Dokumentation.

blank

Als nächstes ändern wir die Datei README.md in unserem Repository, die den Workflow auslöst. Auf der Registerkarte Aktion ist die Änderung sichtbar, der Workflow befindet sich in einer Warteschlange:

blank

Voilà! Das Skript ist ausgeführt worden.

Wir haben nun Zugriff auf die Betriebssysteminformationen und die verwendete virtuelle Maschine und können überprüfen, ob sie der von uns angeforderten Konfiguration entspricht.

Alle Protokolle unseres Skripts sind nun sichtbar:

blank

Konkretes Beispiel

Nachdem wir nun gesehen haben, wie man GitHub-Aktionen erstellt und einrichtet, sehen Sie hier einen Workflow, der von Eric Marchand erstellt wurde.

Eric ist einer unserer Entwickler im 4D for iOS Team. Er hat mehrere Git-Aktionen für seinen eigenen Gebrauch entwickelt, die er auf einem GitLab-Server für unsere privaten Repositories und auf GitHub für die öffentlichen Repositories verwendet.

Hier ist ein Beispiel dafür, wie man ein Projekt kompiliert und auf GitHub veröffentlicht:

Zunächst haben wir ein 4D Projekt mit gemeinsamem Code, das andere Projekte kompiliert, die beim Start als Parameter übergeben werden (mit einem Bash-Skript auf macOS runner). Dieses Projekt konvertiert die Kompilierungsfehler in das GitHub-Protokollformat. Es wird in einem Github-Repository gespeichert, das Aktionen wie Kompilierung, Erzeugung einer Freigabe usw. enthält. Diese Aktionen können dann in jedem anderen Projekt verwendet werden.

Zweitens müssen wir eine 4D Anwendung starten, um das Projekt auszuführen und damit eine Aktion wie das Kompilieren aufzurufen. Eine 4D Anwendung steht auf einem Server zum Download bereit. Sie muss auf GitHub-Servern installiert und ausgeführt werden. Sie müssen den Schlüssel SERVER_URL im Parameter„Action Secret“ Ihres Repositorys für jedes Projekt hinzufügen.

Schließlich erstellen Sie Workflows, die durch einen Pull-Request in Ihren Projekten ausgelöst werden, der den „Build“-Workflow Ihres „Centralized Action“-Repositorys aufruft.

Hier finden Sie das Repository mit der Basis und den verschiedenen Workflows sowie ein Beispiel für deren Integration in ein Projekt.

Teilen Sie uns Ihre Meinung mit und beteiligen Sie sich an der Diskussion im 4D Forum!

Vanessa Talbot
Product Owner - Vanessa Talbot kam im Juni 2014 zum 4D Programmteam. Als Product Owner ist sie für das Schreiben der User Stories und deren Umsetzung in funktionale Spezifikationen zuständig. Ihre Aufgabe ist es auch, sicherzustellen, dass die Implementierung der Funktionen den Anforderungen des Kunden entspricht. Seit ihrer Ankunft hat sie an der Definition der wichtigsten Funktionen in 4D gearbeitet. Sie hat an den meisten der neuen Funktionen für präemptives Multi-Threading gearbeitet und auch an einem sehr komplexen Thema: der neuen Architektur für erstellte Anwendungen. Vanessa hat einen Abschluss von der Telecom Saint-Etienne. Sie begann ihre Karriere am Criminal Research Institute als Entwicklerin für die audiovisuelle Abteilung. Sie hat auch in den Bereichen Medien und Medizin als Expertin für technischen Support, Produktion und die Dokumentation neuer Funktionen gearbeitet.