Umstellung auf MQL5 Algo Forge (Teil 4): Arbeiten mit Versionen und Releases

Einführung

Unser Übergang zu MQL5 Algo Forge geht weiter. Wir haben unseren Arbeitsablauf mit persönlichen Repositories eingerichtet und haben uns einem der Hauptgründe für diesen Schritt zugewandt - der Möglichkeit, von der Gemeinschaft bereitgestellten Code einfach zu nutzen. In Teil 3 haben wir uns damit beschäftigt, wie wir eine öffentliche Bibliothek aus einem anderen Repository zu unserem eigenen Projekt hinzufügen können.

Das Experiment, die SmartATR-Bibliothek mit dem SimpleCandles Expert Advisor zu verbinden, hat deutlich gezeigt, dass einfaches Klonen nicht immer zweckmäßig ist, insbesondere wenn der Code Änderungen erfordert. Wir folgten stattdessen dem korrekten Arbeitsablauf: Wir erstellten einen Fork, der zu unserer persönlichen Kopie des Repositorys eines anderen wurde, um Fehler zu beheben und Änderungen vorzunehmen, wobei wir uns die Möglichkeit offen hielten, dem Autor diese Änderungen später über einen Pull Request vorzuschlagen.

Trotz gewisser Einschränkungen, auf die wir in der MetaEditor-Oberfläche gestoßen sind, konnten wir durch die Kombination mit der MQL5 Algo Forge-Webschnittstelle die gesamte Aktionskette vom Klonen über die Übergabe der Änderungen bis hin zur Verknüpfung des Projekts mit einer externen Bibliothek erfolgreich abschließen. So haben wir eine spezifische Aufgabe gelöst und eine universelle Vorlage für die Integration beliebiger Komponenten von Drittanbietern untersucht.

Im heutigen Artikel werden wir die Phase der Veröffentlichung der im Repository vorgenommenen Änderungen näher betrachten. Dabei handelt es sich um einen bestimmten Satz von Änderungen, die eine vollständige Lösung bilden, sei es das Hinzufügen neuer Funktionen zu einem Projekt oder das Beheben eines entdeckten Problems. Dabei handelt es sich um den Prozess der Übergabe oder Freigabe einer neuen Produktversion. Wir werden sehen, wie man diesen Prozess organisiert und welche Möglichkeiten MQL5 Algo Forge dafür bietet.

Suche nach einem Zweig (branch)

In früheren Teilen haben wir empfohlen, einen separaten Repository-Zweig zu verwenden, um eine Reihe von Änderungen vorzunehmen, die eine bestimmte Aufgabe betreffen. Nach Abschluss der Arbeit an einem solchen Zweig ist es jedoch am besten, ihn mit einem anderen Zweig (main) zusammenzuführen und ihn dann zu löschen. Andernfalls kann sich das Depot schnell in ein dichtes Dickicht verwandeln, in dem sich selbst der Besitzer leicht verirren könnte. Daher sollten veraltete Zweige entfernt werden. Manchmal müssen Sie jedoch den Code in den Zustand zurückversetzen, in dem er sich kurz vor dem Löschen eines bestimmten Zweigs befand. Wie kann man das tun?

Zunächst sei klargestellt, dass ein Zweig einfach eine Abfolge von Commits (Übertragungen) in chronologischer Reihenfolge ist. Technisch gesehen ist ein Zweig ein Verweis auf einen Commit, der als der letzte in einer Kette von aufeinanderfolgenden Commits gilt. Daher werden beim Löschen eines Zweigs nicht die Commits selbst gelöscht. Schlimmstenfalls werden sie einem anderen Zweig zugewiesen oder sogar in einem einzigen zusammenfassenden Commit zusammengeführt; in jedem Fall aber bleiben sie im Repository bestehen (mit seltenen Ausnahmen). Zu dem Zustand „vor dem Löschen eines Zweigs“ zurückzukehren, bedeutet also im Wesentlichen, zu einem der Commits zurückzukehren, die in einem Zweig existieren. Die Frage ist dann: Wie finden wir diese Commits?

Schauen wir uns den Zustand des Repositorys von SimpleCandles an, nachdem die in Teil 3 erwähnten Änderungen vorgenommen worden sind:

Auf der linken Seite sehen wir die Historie der Commits und eine farbige Visualisierung der Beziehungen zwischen den Zweigen. Jeder Commit wird durch seinen Hash (oder genauer gesagt, einen Teil davon) identifiziert, d.h. durch eine große eindeutige Zahl, die ihn von allen anderen unterscheidet. Um die Darstellung zu verkürzen, wird der Hash in hexadezimaler Form angezeigt (z. B. b04ebd1257). 

Ein solcher Commit-Baum kann für jedes Repository auf einer speziellen Seite der MQL5 Algo Forge-Webschnittstelle angezeigt werden. Der gezeigte Screenshot wurde vor einiger Zeit aufgenommen. Wenn Sie diese Seite jetzt besuchen, werden Sie ein leicht verändertes Bild sehen: neue Commits werden im Baum aufgetaucht sein, und die Verflechtung der Zweige wird sich aufgrund zusätzlicher Merge-Commits verändert haben.

Wir können auch die Namen der Zweige neben einigen Commits sehen. Diese werden für die neuesten Commits in jedem Zweig angezeigt. Auf dem Screenshot sind sechs verschiedene Zweige zu sehen: main, develop, convert-to-utf8, article-17608-close-manager, article-17607 und article-19436-forge3. Der letzte ist der Zweig, der für die Änderungen beim Schreiben von Teil 3 verwendet wird. Bei der Arbeit an Teil 2 haben wir aber auch einen eigenen Zweig für die geplanten Änderungen angelegt. Er trug den Namen article-17698-forge2 und wurde inzwischen gelöscht, weshalb kein Commit mehr diesen Zweignamen trägt. Wo können wir ihn also finden?

Wenn wir uns die vollständige Commit-Nachricht für 58beccf233 ansehen, wird dieser Zweigname erwähnt und es wird angegeben, dass er in die Entwicklungsumgebung eingefügt wurde.

Wir haben also die gewünschte Übergabe gefunden, aber es ist nicht einfach, sie auf diese Weise zu finden. Hätten wir außerdem Zweige manuell mit Konsolenbefehlen wie „git merge“ statt über einen Pull Request zusammengeführt, hätten wir jeden beliebigen Kommentar für den Merge-Commit schreiben können. In diesem Fall wäre es noch schwieriger gewesen, den richtigen Commit zu finden, da der Name des Zweigs möglicherweise gar nicht in der Nachricht enthalten gewesen wäre.

Nun, da wir den gewünschten Commit gefunden haben, können wir zu ihm wechseln und unser lokales Repository in den Zustand zurückversetzen, in dem es sich unmittelbar nach diesem Commit befand. Zu diesem Zweck können wir den Commit-Hash im Befehl „git checkout“ verwenden. Allerdings gibt es hier einige Nuancen. Wenn wir versuchen, zu diesem Commit in MetaEditor zu wechseln, indem wir ihn aus der Historie auswählen, die über die Kontextmenüoption „Git Log“ des Projekts geöffnet wird:

... erhalten wir eine Fehlermeldung:

Vielleicht gibt es dafür einen Grund. Schauen wir uns genauer an, was hier vor sich geht. Wir beginnen mit der Einführung der neuen Konzepte „tag“ und „HEAD pointer“.

Tags

Ein Tag im Git-Versionskontrollsystem ist ein zusätzlicher Name, der einem bestimmten Commit zugewiesen wird. Man kann sich ein Tag auch als einen Zeiger oder Verweis auf eine bestimmte Version des Codes im Repository vorstellen, da es direkt auf einen bestimmten Commit verweist. Die Verwendung eines Tags ermöglicht es Ihnen, jederzeit zu dem genauen Zustand des Codes zurückzukehren, der dem getaggten Commit entspricht. Tags sind hilfreich, um wichtige Meilensteine in der Projektentwicklung zu markieren, z. B. Versionsfreigaben, Fertigstellungsphasen oder stabile Builds. In der MQL5 Algo Forge-Webschnittstelle können Sie alle Tags eines ausgewählten Repositorys auf einer separaten Seite anzeigen.

Es gibt zwei Arten von Tags in Git: leichtgewichtige und kommentierte. Leichtgewichtige Tags enthalten nur einen Namen, während kommentierte Tags zusätzliche Informationen wie den Autor, das Datum, Kommentare und sogar eine Signatur enthalten können. In den meisten Fällen werden leichte Tags verwendet.

Um eine Markierung über die Weboberfläche zu erstellen, können Sie die Seite eines beliebigen Commits öffnen (z. B. diese hier), auf die Schaltfläche „Operations“ klicken und „Create tag“ wählen.

Wir werden jedoch etwas später auf die Erstellung von Tags zurückkommen.

Um ein Tag über Git-Konsolenbefehle zu erstellen, verwenden Sie den Befehl „git tag“. Um ein leichtgewichtiges Tag zu erstellen, geben Sie einfach den Namen des Tags an:

git tag <tag-name>

# Beispiel
git tag v1.0

Um ein kommentiertes Tag zu erstellen, müssen Sie einige zusätzliche Parameter hinzufügen:

git tag -a <Tag-Name> -m „Tag-Beschreibung“

# Beispiel:
git tag -a v1.0 -m „Version 1.0 release“

Neben der Kennzeichnung von Codeversionen, die zur Veröffentlichung oder Bereitstellung (Releases) bestimmt sind, können Tags auch verwendet werden, um CI/CD-Pipelines zu signalisieren, dass vordefinierte Aktionen ausgelöst werden, wenn ein Commit mit einem bestimmten Tag auftaucht, oder um wichtige Entwicklungsmeilensteine zu markieren, wie z. B. die Fertigstellung wichtiger Funktionen oder die Behebung kritischer Bugs, auch wenn sie keine neue Version darstellen.

Der Zeiger HEAD

Nachdem wir über Tags gesprochen haben, sollten wir ein weiteres wichtiges Konzept erwähnen – den Zeiger HEAD. Es verhält sich ähnlich wie ein Tag mit festem Namen HEAD, das automatisch zum letzten Commit im aktuell ausgecheckten Zweig wechselt. HEAD wird oft als „Markierung des aktuellen Zweigs“ oder „Zeiger auf den aktiven Zweig“ bezeichnet. Sie beantwortet im Wesentlichen die Frage: „Wo befinden wir uns gerade im Repository?“ Technisch gesehen handelt es sich jedoch nicht um ein „tag“.

Physisch wird dieser Zeiger in der Datei .git/HEAD im Repository gespeichert. Der Inhalt von HEAD kann entweder einen symbolischen Verweis (einen Tag oder Zweignamen) oder einen Commit-Hash enthalten. Wenn Sie zwischen Zweigen wechseln, wird HEAD automatisch aktualisiert und zeigt auf das letzte Commit im aktuellen Zweig. Wenn ein neuer Commit hinzugefügt wird, erstellt Git nicht nur das Commit-Objekt, sondern verschiebt auch HEAD dorthin.

So kann der Name HEAD in Git-Konsolenbefehlen anstelle des Hashs des letzten Commits oder des aktuellen Zweignamens verwendet werden. Mit den Sonderzeichen ~ und ^ können Sie auf Commits verweisen, die vor dem letzten liegen. Zum Beispiel bezieht sich HEAD~2 auf den Commit zwei Schritte vor dem letzten Commit. Wir werden diese Details jetzt nicht näher erläutern.

Für die weitere Diskussion sollten wir auch die beiden möglichen Zustände erwähnen, in denen sich ein Endlager befinden kann. Der normale Zustand, der als „angehängter HEAD“ bezeichnet wird, bedeutet, dass neue Commits vor der letzten Übertragung im aktuellen Zweig erscheinen. In diesem Zustand werden alle Bearbeitungen dem Zweig nacheinander und ohne Konflikte hinzugefügt.

Der andere Zustand, bekannt als „detached HEAD“, tritt auf, wenn der HEAD-Zeiger auf einen Commit verweist, der nicht der neueste in irgendeinem Zweig ist. Dies kann zum Beispiel der Fall sein, wenn: 

• das Repository auf ein bestimmtes früheres Commit umgestellt wird (z. B. mit „git checkout <commit-hash>“),
• auf einem Tag-Namen umgeschaltet wird (z. B. „git checkout tags/<tag-name>“),
• zu einem Zweig gewechselt wurde, der im entfernten Repository noch existiert, aber aus dem lokalen Repository entfernt wurde (z. B. „git checkout origin/<Zweigname>“).

Dieser Zustand sollte nach Möglichkeit vermieden werden, da alle Änderungen in diesem Zustand, die mit keinem Zweig verbunden sind, beim Wechsel zu einem anderen Zweig verloren gehen können. Wenn Sie jedoch in diesem Zustand keine Änderungen vornehmen wollen, ist es in Ordnung, ihn zu haben.

Noch keine Tags

Kehren wir nun zu unserem Versuch zurück, unser lokales Repository auf einen bestimmten Commit umzustellen, der einst der letzte im gelöschten Zweig article-17698-forge2 war.

Das Wechseln eines Repositorys zu einem bestimmten früheren Commit ist nichts, was Entwickler normalerweise in alltäglichen Git-Arbeitsabläufen tun. Unter normalen Umständen werden Sie eine solche Operation nur selten durchführen müssen. Wenn Sie sich jedoch dafür entscheiden, wird das Repository in den so genannten Zustand „detached HEAD“ versetzt. In diesem Fall gehört dieser Commit zum develop branch (Entwicklungszweig), auf den bereits neuere Commits folgen, er ist also nicht mehr der neueste im Zweig.

Wenn wir jedoch die Befehlszeilenschnittstelle von Git verwenden, um diesen Wechsel vorzunehmen, wird der Vorgang erfolgreich abgeschlossen. Git warnt jedoch deutlich vor dem Status „detached HEAD”:

 

Aufmerksamen Lesern wird auffallen, dass wir im letzten Screenshot zu einem Commit mit dem Hash 58beccf233 gewechselt haben, aber Git meldet, dass der HEAD-Zeiger jetzt auf 58beccf steht. Wo sind die letzten drei Ziffern geblieben? Es ist alles in Ordnung. Sie sind nicht verschwunden. Git erlaubt einfach die Verwendung von verkürzten Commit-Hashes, solange sie innerhalb des Repositorys eindeutig bleiben. Je nach Schnittstelle werden die Hashes auf 4 bis 10 Zeichen gekürzt.

Wenn Sie jemals den vollständigen Commit-Hash sehen wollen, können Sie den Befehl „git log“ ausführen. Jeder vollständige Commit-Hash enthält 40 Ziffern.

Da jeder Hash zufällig und eindeutig generiert wird, sind selbst die ersten paar Ziffern innerhalb eines Repositorys fast garantiert eindeutig. Aus diesem Grund reicht es in der Regel aus, nur ein kurzes Präfix des Hashes anzugeben, damit Git genau erkennt, auf welchen Commit Sie sich in Ihren Befehlen beziehen.

UTF-8-Kodierung verwenden

Hier ist ein weiterer interessanter Aspekt. In früheren Versionen verwendete MetaEditor die Kodierung UTF-16LE, um Quellcodedateien zu speichern. Aus irgendeinem Grund wurden Dateien, die in dieser Kodierung gespeichert wurden, von Git jedoch als Binärdateien und nicht als Textdateien behandelt. Daher war es nicht möglich, die genauen Codezeilen anzuzeigen, die in einem Commit geändert worden waren (obwohl dies in Visual Studio Code problemlos funktionierte). Die einzige Information, die angezeigt wurde, war die Dateigröße vor und nach den Änderungen im Rahmen eines Commits.

So sieht es in der Webschnittstelle von MQL5 Algo Forge aus:

Neue Dateien, die in MetaEditor erstellt werden, werden jetzt in UTF-8-Kodierung gespeichert, und selbst die Verwendung von Zeichen des nationalen Alphabets führt nicht mehr zu einem automatischen Wechsel zu UTF-16LE. Daher ist es sinnvoll, ältere Dateien, die von früheren Projekten in das neue Repository übernommen wurden, in UTF-8 zu konvertieren. Nachdem Sie eine solche Konvertierung durchgeführt haben, können Sie ab dem nächsten Commit genau sehen, welche Zeilen und Zeichen geändert wurden. In der Webschnittstelle von MQL5 Algo Forge könnte es zum Beispiel so aussehen:

Aber das war nur ein kurzer Exkurs. Kehren wir zu der Frage zurück, wie eine neue Version des Codes im Repository veröffentlicht wird.

Zurück zur Hauptaufgabe

Unter den Zweigen in unserem Repository sollten wir uns also diese beiden ansehen: article-17608-close-manager und article-17607. Die in diesen Zweigen vorgenommenen Änderungen wurden noch nicht in develop zusammengeführt, da die mit ihnen verbundenen Aufgaben noch in Arbeit sind. Diese Zweige werden sich weiter entwickeln, daher ist es zu früh, sie in develop zusammenzuführen. Wir werden die Arbeit an einem von ihnen (article-17607) fortsetzen, ihn zu einem logischen Abschluss bringen und ihn dann mit develop zusammenführen. Der resultierende Zustand des Codes wird mit einer Versionsnummer versehen.

Dazu müssen wir zunächst den ausgewählten Zweig für weitere Bearbeitungen vorbereiten, denn während er existierte, haben andere Zweige ebenfalls Änderungen vorgenommen. Diese Änderungen sind bereits in die Entwicklung eingeflossen. Daher müssen wir sicherstellen, dass diese Aktualisierungen von develop auch in den von uns gewählten Zweig übernommen werden.

Es gibt mehrere Möglichkeiten, Änderungen aus develop in article-17607 einzubringen. Wir könnten zum Beispiel einen Pull Request über die Weboberfläche erstellen und den im vorherigen Teil beschriebenen Zusammenführungsprozess wiederholen. Dieser Ansatz eignet sich jedoch am besten, wenn Sie neuen, ungetesteten Code in einen Zweig mit stabilem, getesteten Code einbinden wollen. In unserem Fall ist die Situation umgekehrt: Wir wollen stabile, geprüfte Aktualisierungen aus dem Entwicklungszweig in einen Zweig bringen, der noch neuen, ungeprüften Code enthält. Daher ist es völlig in Ordnung, die Zusammenführung mit Git-Konsolenbefehlen durchzuführen. Wir werden die Konsole verwenden und den Prozess in Visual Studio Code überwachen.

Überprüfen wir zunächst den aktuellen Zustand des Repositorys. In der Versionsverwaltung können wir die Commit-Historie mit den Namen der Zweige sehen. Der aktuelle Zweig ist article-19436-forge3, wo die letzten Änderungen vorgenommen wurden. Auf der rechten Seite des Terminals wird die Ausgabe des Befehls „git status“ angezeigt:

Der Befehl bestätigt, dass sich unser Repository derzeit im Zweig article-19436-forge3 befindet und dass sein Status mit dem entsprechenden Zweig im entfernten Repository synchronisiert ist.

Als Nächstes wechseln wir mit dem Befehl „git checkout article-17607“ zum Zweig article-17607:

Führen Sie es dann mit „git merge develop“ mit develop zusammen:

Da die externen Änderungen Teile des Codes betrafen, die wir bei der Arbeit an article-17607 nicht verändert hatten, traten bei der Zusammenführung keine Konflikte auf. Daraufhin hat Git einen neuen, zusammenführenden, eiinen Merge-Commit erstellt.

Jetzt führen wir „git push“ aus, um die aktualisierten Informationen an das entfernte Repository zu senden:

Wenn wir das MQL5 Algo Forge Repository überprüfen, werden wir sehen, dass unsere Merge-Schritte erfolgreich in das entfernte Repository übernommen wurden:

Der letzte Commit im Screenshot ist der Merge-Commit zwischen develop und article-17607. 

Beachten Sie auch das freie Ende des Zweigs article-19436-forge3, der noch mit keinem anderen Zweig verbunden ist. Die Änderungen aus diesem Zweig sind noch nicht in den Entwicklungszweig eingeflossen, da die Arbeit dort noch nicht abgeschlossen ist. Wir belassen es vorerst dabei. Wenn die Zeit reif ist, werden wir darauf zurückkommen.

Damit sind die Vorbereitungen für die Weiterentwicklung von article-17607 abgeschlossen, und wir können nun mit der eigentlichen Codierungsarbeit beginnen. Die Lösung für die mit diesem Zweig verbundene Aufgabe wird in einem anderen Artikel beschrieben. Deshalb werde ich sie hier nicht wiederholen. Stattdessen wollen wir nun beschreiben, wie man den Code nach Abschluss der Aufgabe fertigstellt und den erreichten Zustand festhält.

Durchführen der Zusammenführung

Bevor wir einen bestimmten Stand des Codes veröffentlichen, müssen wir ihn zunächst in den Hauptzweig einbinden. Unsere Primärzweig ist main. Alle Aktualisierungen aus dem Entwicklungszweig werden schließlich in den main einfließen. Änderungen aus einzelnen Task-Zweigen werden in develop zusammengeführt. Im Moment sind wir noch nicht bereit, neuen Code in main einzubinden, also beschränken wir uns darauf, Updates in develop einzubinden. Um diesen Mechanismus zu demonstrieren, ist die Wahl des des einen oder anderen Zweigs, der die Hauptrolle spielt, nicht so wichtig.

Schauen wir uns den Zustand des SimpleCandles-Repositorys nach Abschluss der Arbeit an der ausgewählten Aufgabe an:

Wie gezeigt, wurde der letzte Commit im Zweig article-17607 vorgenommen. Mit Hilfe der Weboberfläche von MQL5 Algo Forge erstellen wir einen Pull Request, um diesen Zweig in die Entwicklung einzubinden, wie zuvor beschrieben.

Überprüfen wir, ob alles wie erwartet funktioniert hat. Wir öffnen die Commit-Historienseite erneut mit der Zweigbaumansicht:

Wir können sehen, dass der Commit mit dem Hash 432d8a0fd7 nicht mehr als der neueste in article-17607 markiert ist. Stattdessen erscheint ein neuer Commit mit dem Hash 001d35b4a7 als der neueste in develop. Da dieser Commit die Zusammenführung von zwei Zweigen aufzeichnet, nennen wir ihn den Merge-Commit.

Als Nächstes öffnen Sie die Seite merge commit und erstellen ein neues Tag. Zu Beginn des Artikels haben wir gezeigt, wie man das macht, und jetzt ist es an der Zeit, es tatsächlich zu tun:

Geben Sie im Pop-up-Fenster den Tag-Namen „v0.1“ ein, da dies noch lange nicht die endgültige Version ist. Wir wissen noch nicht, wie viele weitere Ergänzungen zu dem Projekt hinzukommen werden, aber hoffentlich eine ganze Menge. Daher dient eine so kleine Versionsnummer dazu, uns daran zu erinnern, dass wir noch viel Arbeit vor uns haben. Im Übrigen sieht es nicht so aus, als ob die Weboberfläche derzeit die Erstellung von kommentierten Tags unterstützt.

Das Tag wurde nun erfolgreich erstellt, und Sie können das Ergebnis auf der folgenden Seite sehen:

 oder auf der speziellen Seite des Repositorys tags.

Wenn wir unser lokales Repository mit „git pull“ aktualisieren, wird das neu erstellte Tag auch dort erscheinen. Da MetaEditor derzeit jedoch keine Repository-Tags anzeigt, sollten wir prüfen, wie sie in Visual Studio Code aussehen. Wenn Sie den Mauszeiger über die gewünschte Übergabe im Übergabebaum bewegen, wird eine farbige Kennzeichnung mit dem zugehörigen Namen des Tags in der QuickInfo angezeigt:

Nun, da das Tag erstellt ist, können wir entweder hier aufhören und seinen Namen in einem „git checkout“-Befehl verwenden, um zu genau diesem Code-Status zu wechseln, oder wir gehen weiter und erstellen eine Veröffentlichung auf der Grundlage dieses Tags. 

Erstellen einer Freigabe, eines Release

Ein Release ist ein Mechanismus zur Kennzeichnung und Verteilung bestimmter Versionen von Software, unabhängig von der verwendeten Programmiersprache. Commits und Branches repräsentieren den Entwicklungsablauf, während Releases die offiziellen Ergebnisse sind, d.h. die Versionen, die wir veröffentlichen wollen. Die Hauptgründe für die Verwendung von Releases sind die folgenden:

• Versionierung. Wir kennzeichnen bestimmte Zustände des Codes im Repository Code als stabil, d. h. sie sind frei von kritischen Fehlern (zumindest scheinbaren) und haben eine verifizierte Funktionalität. Andere Nutzer können diese speziellen Versionen verwenden.
  
  
• Verteilen von Binärdateien. Releases können kompilierte oder gepackte Dateien (z. B. .ex5, .dll oder .zip) enthalten, sodass die Nutzer das Projekt nicht selbst kompilieren müssen.
  
  
• Kommunikation mit dem Nutzer. Eine Version sollte eine Beschreibung enthalten, die in der Regel Änderungen, neue Funktionen, behobene Fehler und andere relevante Informationen über diese Version auflistet. Das Hauptziel dieser Beschreibung ist es, den Nutzern bei der Entscheidung zu helfen, ob sie das Programm aktualisieren sollten.

Es ist erwähnenswert, dass CI/CD-Systeme, einschließlich MQL5 Algo Forge, automatisch Releases erstellen können, wenn ein Zweig mit dem Zweig main zusammengeführt wird, automatische Builds durchführen und Binärdateien veröffentlichen. Eine solche Automatisierung erfordert jedoch eine vorherige Einrichtung und die Konfiguration von Skripten für die Ereignisbehandlung. Dies sind fortgeschrittenere (wenn auch nicht unerlässliche) Funktionen, die wir daher vorerst beiseite lassen wollen.
Eine Freigabe kann auf der Grundlage einer bestehenden Kennzeichnung erstellt werden, oder es kann eine neue Kennzeichnung während des Erstellungsprozesses der Freigabe erzeugt werden. Da wir bereits ein Tag haben, erstellen wir eine neue Version mit diesem „tag“. Gehen Sie dazu auf die Seite mit den Repository-Tags und klicken Sie neben dem gewünschten Tag auf „Neue Version“:

Im Formular zur Erstellung einer Freigabe können Sie mehrere grundlegende Eigenschaften angeben:

• Freigabename, Zielzweig und Tag (entweder ein vorhandener oder ein neu zu erstellender),
• Versionshinweise, d. h. eine Zusammenfassung der Neuerungen, der Fehlerbehebungen und der bekannten Probleme,
• angehängte Dateien, z. B. kompilierte Programme, Dokumentation oder Links zu externen Ressourcen.

So sieht es in der Webschnittstelle von MQL5 Algo Forge aus:

Sie können ein Release als Entwurf speichern und die Details später aktualisieren oder sie sofort veröffentlichen. Auch wenn Sie sie jetzt veröffentlichen, können Sie später noch Änderungen vornehmen: So können Sie beispielsweise die Beschreibung der Veröffentlichung nachträglich noch anpassen. Nach der Veröffentlichung erscheint die Version auf der Repositorys-Seite der Releases und ist für andere Nutzer sichtbar:

Das war's! Die neue Version ist jetzt live und einsatzbereit. Wenig später aktualisierten wir den Versionsnamen (der nicht mit dem Tag-Namen übereinstimmen muss) und fügten einen Link zu dem oben erwähnten Artikel hinzu, der die implementierte Lösung beschreibt.

Schlussfolgerung

Lassen Sie uns einen Moment innehalten und über die Fortschritte nachdenken, die wir gemacht haben. Wir haben uns nicht nur mit den technischen Aspekten der Versionskontrolle befasst. Wir haben eine vollständige Umstellung vollzogen und sind von verstreuten Bearbeitungen zu einem strukturierten, kohärenten Workflow für die Verwaltung von Code übergegangen. Der wichtigste Meilenstein, den wir erreicht haben, ist der letzte Schritt: die Freigabe der fertigen Arbeit als offizielle Produktversion für die Endnutzer. Unser aktuelles Repository ist zwar noch kein voll ausgereiftes Projekt, aber wir haben alle Voraussetzungen geschaffen, um dieses Niveau zu erreichen.

Dieser Ansatz verändert unsere Wahrnehmung des Projekts grundlegend. Was einst eine lose Sammlung von Quelldateien war, ist jetzt ein organisiertes System mit einer klaren Historie der Änderungen und klar definierten Kontrollpunkten, die es uns ermöglichen, jederzeit zu einem stabilen Zustand zurückzukehren. Davon profitieren alle: sowohl die Entwickler als auch die Nutzer der fertigen Lösungen.

Durch die Beherrschung dieser Tools haben wir unsere Arbeit mit dem MQL5 Algo Forge Repository auf ein neues Niveau gehoben, was uns die Tür zu komplexeren und umfangreicheren Projekten in der Zukunft öffnet.

Vielen Dank für Ihre Aufmerksamkeit! Bis zum nächsten Mal!