Passer à MQL5 Algo Forge (Partie 2) : Travailler avec plusieurs dépôts

Introduction

Dans le premier article, nous avons commencé la transition du stockage MQL5 Storage basé sur SVN dans MetaEditor vers une solution plus flexible et plus moderne basée sur le système de contrôle de version Git : MQL5 Algo Forge. La raison principale de cette étape était la nécessité d'exploiter pleinement les branches du dépôt tout en travaillant sur plusieurs projets ou sur différentes fonctionnalités au sein d'un même projet.

La transition a commencé par la création d'un nouveau dépôt dans MQL5 Algo Forge et la mise en place d'un environnement de développement local utilisant Visual Studio Code, ainsi que les extensions MQL5 et Git nécessaires et les outils supportés. Nous avons ensuite ajouté un fichier .gitignore au dépôt pour exclure les fichiers standards et temporaires du contrôle de version. Tous les projets existants ont été téléchargés dans une branche archive dédiée, désignée comme lieu d'archivage de tous les codes écrits précédemment. La branche main a été laissée vide et préparée pour l'organisation de nouvelles branches de projet. Nous avons ainsi jeté les bases de la distribution de différents codes de projet dans des branches distinctes du dépôt.

Cependant, depuis la publication du premier article, MetaEditor a considérablement élargi son support pour le nouveau système de dépôt. Ces changements nous incitent à reconsidérer l'approche décrite précédemment. C'est pourquoi, dans cet article, nous nous écarterons légèrement du plan initial et étudierons comment créer un projet public qui intègre d'autres projets publics comme composants. Le projet sur lequel nous allons nous concentrer est le développement d'un Expert Advisor multi-devises. Plusieurs articles ont déjà été publiés qui décrivent les approches du développement et des modifications du code pour ce projet. Nous allons maintenant tirer pleinement parti du contrôle de version Git pour organiser et rationaliser le processus de développement.

Tracer le chemin

C'est difficile à croire, mais au moment de l'article précédent, MetaEditor n'incluait pas encore les commandes dans le menu contextuel des fichiers pour travailler avec les dépôts de MQL5 Algo Forge. Par conséquent, des efforts considérables ont été nécessaires pour configurer les flux de travail à l'aide d'outils externes tels que Visual Studio Code. Comme nous ne savions pas comment MetaEditor mettrait en œuvre la prise en charge des référentiels, nous avons dû utiliser les outils disponibles à ce moment-là.

Depuis, les nouvelles versions de MetaEditor ont introduit un support intégré pour MQL5 Algo Forge. MetaQuotes a également publié un nouvel article, "Bien démarrer avec MQL5 Algo Forge", qui explique les bases et démontre les fonctionnalités clés. Mais le développement le plus important, à notre avis, est la mise en œuvre des projets partagés dans MetaEditor.

Pourquoi est-ce important ? Auparavant, nous savions que le dossier MQL5 servirait de dépôt hébergé sur les serveurs Git de MQL5 Algo Forge. Ce dépôt avait le nom fixe mql5. Cela signifiait que chaque utilisateur avait un dépôt nommé mql5 dans Algo Forge. Ce dépôt était ensuite cloné dans le dossier MQL5 après l'installation d'un nouveau terminal, la connexion à la Communauté et la connexion au dépôt. Parallèlement, MQL5 Algo Forge a toujours permis la création de dépôts supplémentaires. Plus précisément, il ne s'agit pas d'un dépôt supplémentaire, mais d'un dépôt séparé, qui n'est pas lié au dépôt mql5. Naturellement, cela a soulevé une question : comment MetaEditor gérerait-il ces autres dépôts ? 

Les utilisateurs pourraient-ils sélectionner le dépôt à utiliser dans chaque installation du terminal ? Ou non ? Seul le dépôt mql5 serait-il pris en charge, les utilisateurs étant contraints de séparer leur travail en branches pour différents projets ? Nous nous sommes d'abord préparés à ce scénario catastrophe. La gestion de plusieurs projets à travers les branches dans un seul dépôt n'est pas particulièrement pratique. Heureusement, nos inquiétudes se sont révélées infondées.

MetaQuotes a introduit une solution plus élégante qui résout efficacement deux problèmes à la fois. D'une part, nous avons le dépôt principal nommé mql5. Cela fonctionne bien pour ceux qui sont déjà habitués au stockage MQL5 Storage. Ils peuvent désormais continuer à utiliser le contrôle de version sans se soucier du système de contrôle de version sous-jacent.

En revanche, tous les autres dépôts d'utilisateurs sont désormais disponibles sous forme de dossiers dans les projets partagés. Il s'agit d'un nouveau dossier racine standard, à côté des dossiers existants (tels que MQL5, MQL5/Experts, MQL5/Include, etc.), destiné à stocker le code provenant des dépôts supplémentaires de l'utilisateur.

Prenons un exemple. Supposons que nous ayons deux dépôts distincts dans MQL5 Algo Forge, dont aucun n'est le dépôt mql5 par défaut. Le premier dépôt (Adwizard) ne contient que du code de bibliothèque, c'est-à-dire uniquement des fichiers include *.mqh, sans aucun fichier *.mq5 qui pourrait être compilé dans un Expert Advisor ou un indicateur. Le second dépôt (Simple Candles) contient des fichiers *.mq5 qui utilisent les fichiers inclus du premier dépôt. Par souci de simplicité, nous appellerons le premier dépôt le dépôt de la bibliothèque et le second le dépôt du projet.

Notre objectif est de déterminer comment utiliser le code du dépôt de la bibliothèque tout en développant dans le dépôt du projet. Ce scénario pourrait devenir de plus en plus courant si, par exemple, le code partagé dans la base de code mql5.com est également reproduit par ses auteurs dans MQL5 Algo Forge en tant que dépôts publics. Dans ce cas, lier un ou plusieurs dépôts à un projet en tant que bibliothèques externes peut être géré de la même manière que celle que nous allons explorer dans cet article.

Pour commencer

Examinons d'abord la situation du point de vue du développeur qui possède les deux dépôts. Cela signifie que nous pouvons librement apporter des modifications au code dans l'un ou l'autre des dépôts sans attendre une révision et une approbation via le mécanisme de Pull Request. Nous commençons par créer un dossier terminal propre et par copier 2 fichiers à partir d'une copie précédemment installée de MetaTrader 5 :

Pour éviter de rechercher le dossier de travail du terminal dans les profondeurs du système de fichiers, nous recommandons d'exécuter le terminal en mode Portable. Sous Windows, une façon de procéder consiste à créer un raccourci vers le fichier exécutable du terminal et à ajouter l'indicateur /portable au champ cible dans les propriétés du raccourci. 

Après avoir lancé le terminal, ouvrez un nouveau compte de démonstration au cas où, mettez à jour la dernière version, connectez-vous à la Communauté, puis lancez MetaEditor en appuyant sur F4. Connectez MQL5 Algo Forge, s'il ne s'est pas déjà connecté automatiquement.

Dans le Navigateur, nous voyons maintenant le dossier "Projets partagés", qui répertorie les dépôts que nous avons précédemment créés via l'interface web. Cependant, si nous ouvrons ce dossier dans l'explorateur, il est toujours vide. Cela signifie que les fichiers du dépôt n'ont pas encore été téléchargés sur notre ordinateur.

Pour les cloner, cliquez avec le bouton droit de la souris sur chacun des dépôts nécessaires et sélectionnez "Git Clone" dans le menu contextuel. Le journal confirme que le clonage de Adwizard et de Simple Candles a réussi. Les dossiers contenant les dépôts clonés apparaissent maintenant dans l'explorateur :

À ce stade, le code des deux projets est disponible localement et prêt à être utilisé.

Premier problème

Ouvrons SimpleCandles.mq5 et essayons de le compiler :

Comme prévu, des erreurs de compilation se produisent. Essayons de comprendre leurs raisons. Elles ne sont pas critiques, puisque nous savons que le code a été compilé avec succès auparavant. La seule chose qui a changé est l'emplacement relatif des fichiers de la bibliothèque et du projet. Les deux premières erreurs fondamentales proviennent du fait que le compilateur ne trouve pas les fichiers de la bibliothèque là où il les attend. Dans la partie 28, nous avons convenu d'utiliser la structure de dossiers suivante pour stocker la bibliothèque et les projets :

En d'autres termes, nous stockons le dépôt de la bibliothèque dans un sous-dossier du dépôt du projet. Nous disposons ainsi d'une structure prévisible pour localiser les fichiers de la bibliothèque. Cette fois-ci, cependant, nous allons changer cela. Au lieu d'utiliser un sous-dossier Include obligatoire dans le projet, nous utiliserons le dossier MQL5/Shared Projects. Idéalement, ce dossier restera stable et continuera à remplir la même fonction dans les versions futures de MetaEditor.

Pour résoudre ce problème, nous allons mettre à jour les directives #include dans deux fichiers. Mais avant de modifier le code, suivons les bonnes pratiques de développement et créons une branche séparée pour cette tâche isolée. Une fois les corrections testées, nous pouvons fusionner la branche avec la branche de développement principale.

Voyons quelles branches nous avons déjà dans le dépôt du projet. Cela peut se faire de plusieurs manières :

• Via le menu contextuel du dossier du dépôt dans MetaEditor : 

• Par l'interface web sur la page des branches du dépôt :

• Utilisation d'un outil Git externe tel que Visual Studio Code. À côté du nom du dépôt, nous voyons main, qui est le nom de la branche actuelle. En cliquant dessus, vous obtiendrez une liste des branches disponibles (et des éléments de menu pour créer de nouvelles branches) :

Actuellement, le dépôt comporte 4 branches :

• main — la branche principale. Elle est créée avec le dépôt. Dans le cas le plus simple, tout le travail peut être effectué ici sans créer de branches supplémentaires. Dans les cas plus complexes, cette branche est utilisée pour stocker les états des fichiers qui fournissent les versions stables du code. Les modifications en cours qui n'ont pas encore été achevées et testées sont effectuées dans d'autres branches.
• develop — la branche de développement. Dans des cas simples, elle peut être utilisée comme seule branche pour ajouter des modifications et mettre en œuvre de nouvelles fonctionnalités. Cette option est suffisante si les nouvelles fonctionnalités sont mises en œuvre de manière séquentielle. En d'autres termes, nous ne commençons pas à mettre en œuvre de nouvelles fonctionnalités tant que le projet n'est pas totalement fonctionnel et stable après l'ajout des fonctionnalités précédentes. Avant de commencer à travailler sur une nouvelle fonctionnalité, les branches sont fusionnées : les modifications effectuées dans la branche develop sont fusionnées dans la branche main. Si plusieurs fonctionnalités sont développées simultanément, il devient peu pratique de travailler dans une seule branche de développement. Dans ce cas, des branches supplémentaires peuvent être créées.
• Les exemples de ces branches sont article-17608-close-manager et article-17607. La première est une branche de fonctionnalité pour la logique de fermeture de position basée sur des seuils de profit/perte. Cette branche est déjà fusionnée dans develop et develop est ensuite fusionné dans main. La deuxième branche de fonctionnalités est utilisée pour améliorer l'optimisation automatisée. Elle est toujours en cours, et n'a pas encore été fusionnée avec develop ou main.

Il est important de souligner que Git n'impose pas de règles spécifiques d'utilisation des branches. Nous pouvons donc choisir l'option qui nous convient le mieux. Il existe certains flux de travail que certains développeurs ont trouvé utiles et qu'ils ont partagés avec d'autres. C'est ainsi qu'apparaissent les "meilleures pratiques". Vous êtes libre d'adopter ou d'adapter le modèle de ramification qui convient à votre projet. À titre d'exemple, examinons l'une des propositions de principes de ramification décrites dans cet article.

Revenons maintenant à notre dépôt.

Le préfixe origin/ (ou refs/remotes/origin/ comme indiqué dans MetaEditor) est un détail qui peut soulever des questions. Ce préfixe indique simplement que la branche existe dans le dépôt distant, et pas seulement localement. En règle générale, nous synchronisons les branches locales et distantes. Dans MetaEditor, l'exécution d'une commande Commit déclenche automatiquement une commande Push, et le commit est donc envoyé au dépôt distant.

Si les commits sont faits en dehors de MetaEditor, il est possible de commiter localement sans pousser. Dans ce cas, les branches locales et distantes portant le même nom peuvent être différentes. Le préfixe origin/ permet de les distinguer. Ce préfixe indique qu'il s'agit d'une branche d'un dépôt distant ; sinon, il s'agit d'une branche locale.

Création d'une nouvelle branche

Puisque les modifications prévues ne font que s'assurer que le code se compile correctement après que l'emplacement de sa partie bibliothèque a changé, nous baserons une nouvelle branche générée à partir de develop. Nous passons d'abord à origin/develop, après quoi elle apparaîtra dans la liste comme une branche locale de develop.

Nous créons ensuite une nouvelle branche (en exécutant la commande New) et saisissons le nom souhaité. Conformément à notre convention, les branches liées à un article commencent par article- plus l'identifiant unique de l'article. Il peut éventuellement être suivi d'un court suffixe décrivant le sujet de l'article. C'est pourquoi la nouvelle branche est nommée "article-17698-forge2".

Nous pourrions créer une branche d'une autre manière : en utilisant l'interface web, l'interface Visual Studio Code ou l'interface de ligne de commande. A partir de la ligne de commande dans le dossier racine du dépôt, nous pouvons exécuter :

git checkout -b article-17698-forge2 develop

Cela demande à Git de passer (checkout) à une nouvelle branche (-b) appelée article-17698-forge2, basée sur la branche develop.

Si une branche est créée en dehors de l'interface web, elle n'existera que sur notre machine locale jusqu'à la première poussée vers le dépôt distant. L'inverse est également vrai : si une branche est créée dans le dépôt distant via l'interface web, elle n'apparaîtra pas sur notre machine locale avant le premier pull du dépôt distant.

Vous pouvez apporter des modifications de cette manière :

ou comme ceci :

La commande de la console pour l'opération Push, lorsqu'elle inclut la création d'une nouvelle branche, doit contenir des paramètres supplémentaires confirmant que nous voulons vraiment que la branche soit créée dans le dépôt distant :

git push --set-upstream origin article-17698-forge2

Ensuite, la branche existe à la fois dans la copie locale du dépôt et dans le dépôt distant hébergé dans MQL5 Algo Forge. À ce stade, nous pouvons commencer à faire des modifications sans craindre de casser les fonctionnalités des autres branches.

Apporter des modifications

Les modifications nécessaires sont très simples. Dans le fichier SimpleCandles.mq5, nous mettons à jour la ligne qui inclut un fichier de la bibliothèque Adwizard. Étant donné que les dossiers racine des dépôts Simple Candles et Adwizard sont désormais situés au même niveau dans le dossier Shared Projects, le chemin vers Expert.mqh doit d'abord remonter d'un niveau (../) avant de descendre dans les sous-dossiers du dépôt de la bibliothèque :

#include "Include/Adwizard/Experts/Expert.mqh"
#include "../Adwizard/Experts/Expert.mqh"

Un ajustement similaire est nécessaire dans le fichier Strategies/SimpleCandlesStrategy.mqh :

#include "../Include/Adwizard/Virtual/VirtualStrategy.mqh"
#include "../../Adwizard/Virtual/VirtualStrategy.mqh"

Après ces modifications, SimpleCandles.mq5 se compile à nouveau avec succès. Nous pouvons maintenant valider les modifications dans le dépôt :

Comme indiqué précédemment, lors de la validation par l'interface MetaEditor, la commande Push est exécutée automatiquement, envoyant les modifications au dépôt distant dans MQL5 Algo Forge.

Lorsque l'on travaille avec les commandes de la console, on peut obtenir le même résultat de la manière suivante. Si, en plus de modifier des fichiers existants, nous en avons créé de nouveaux, nous devons d'abord les ajouter à l'index du dépôt :

git add .

Cette commande ajoute tous les nouveaux fichiers trouvés dans le dossier du dépôt. Pour n'ajouter que des fichiers spécifiques, remplacez le point (.) par leur nom. Ensuite, nous validons les modifications avec un commentaire spécifié et nous les transférons vers le dépôt distant :

git commit -m "Correction des chemins relatifs pour inclure les fichiers de Adwizard"
git push

À ce stade, les modifications de la branche article-17698-forge2 sont terminées. Elle peut être fusionnée dans la branche develop et ensuite fermée.

Deuxième problème

Nous nous heurtons ici à une surprise désagréable. MetaEditor ne dispose pas actuellement d'outils pour fusionner les branches. En d'autres termes, nous pouvons désormais créer de nouvelles branches, mais nous ne pouvons pas transférer les modifications d'une branche à l'autre ! Nous espérons que cette fonctionnalité sera ajoutée dans un avenir proche. Pour l'instant, nous devons à nouveau nous tourner vers des outils alternatifs pour effectuer des opérations de dépôt.

Il y a 2 façons principales de fusionner des branches. La première consiste à utiliser l'interface de fusion de Visual Studio Code ou des commandes de console standard. Dans notre cas, les commandes suivantes peuvent être utilisées :

git checkout develop
git pull
git merge --no-ff article-17698-forge2

Tout d'abord, nous passons à la branche develop. Ensuite, par précaution, nous le mettons à jour (au cas où des changements auraient été apportés qui n'auraient pas encore atteint notre machine locale). Enfin, la dernière commande effectue la fusion proprement dite. Les conflits de fusion sont possibles, mais dans notre scénario, ils sont peu probables, puisque nous considérons toujours le cas d'un seul développeur travaillant sur le projet. Même lorsque l'on travaille à partir de plusieurs endroits, tant que l'on met régulièrement à jour les dépôts, les conflits ne devraient pas se produire.

Mais ne nous attardons pas sur les nuances de cette méthode. Nous allons plutôt examiner de plus près la deuxième approche. Nous utilisons ici l'interface web de MQL5 Algo Forge.

Utiliser les Pull Requests pour la fusion

Comme d'autres plateformes basées sur Git (telles que GitHub, GitLab ou Bitbucket), MQL5 Algo Forge comprend également un mécanisme appelé "Pull Request" (PR).

Une Pull Request permet à un développeur de proposer que les modifications apportées à une branche soient fusionnées dans un dépôt. En d'autres termes, la création d'une PR est un moyen de notifier le propriétaire du dépôt et les autres contributeurs : "J'ai terminé le travail dans ma branche, veuillez revoir et fusionner ces changements dans la branche principale (main/master/develop)."

Une PR n'est pas une fonctionnalité de Git en soi, mais une couche supplémentaire construite au-dessus. Elle organise le processus de révision du code et de discussion avant que les changements ne soient fusionnés dans la branche principale.

Les Pull Requests permettent également de résoudre plusieurs autres tâches critiques dans le développement moderne : l'intégration continue (CI) avec des tests automatisés, le contrôle de la qualité par d'autres développeurs et la documentation des changements sous la forme de commentaires PR expliquant pourquoi certaines modifications ont été apportées. Cependant, ces pratiques sont plus pertinentes pour les projets menés en équipe, alors que les projets MQL5 sont généralement des projets individuels. Quoi qu'il en soit, le flux de travail pourrait devenir plus important à mesure que des projets collaboratifs verront le jour à l'avenir.

Cela dit, nous avons déjà reproduit le début d'un flux de travail typique pour l'ajout de nouvelles fonctionnalités ou de correctifs à l'aide de PR :

1. Récupérer (pull) les dernières modifications. Avant de commencer le travail, nous avons mis à jour la branche locale develop.

2. Créer une nouvelle branche pour la tâche. A partir de la branche develop mise à jour, nous avons créé une branche avec un nom clair article-17698-forge2.

3. Apporter des modifications à la nouvelle branche. Nous avons modifié et testé plusieurs fichiers, puis nous avons validé les changements.

Les étapes suivantes sont les suivantes.

4. Créer une Pull Request. Dans l'interface web de MQL5 Algo Forge, naviguez vers l'onglet Pull Requests et cliquez sur le gros bouton rouge 'New pull request'.

La page de sélection des branches s'ouvre. À ce stade, la PR n'a pas encore été créée ; nous devons d'abord définir où les modifications seront fusionnées. Une fois les branches sélectionnées, nous pouvons examiner la liste des modifications. Cliquez ensuite à nouveau sur "New pull request".

Une nouvelle page s'ouvre où nous pouvons fournir une description détaillée des changements. Ici, nous pouvons également désigner des réviseurs. Par défaut, la demande nous est adressée, ce qui est exactement ce dont nous avons besoin dans ce cas.

5. Revue et discussion. Comme nous travaillons seuls, nous pouvons sauter cette étape. Normalement, cette étape implique :

   • les réviseurs qui examinent le code et laissent des commentaires (généraux ou liés à des lignes spécifiques),

   • l'auteur du rapport répond aux commentaires et apporte des corrections dans la même branche,

   • et tous les nouveaux push sont automatiquement ajoutées à la PR existante.

6. Fusionner (merge). Après l'approbation des réviseurs (le cas échéant) et le passage du CI (s'il est configuré), la PR peut être fusionnée. Il existe généralement plusieurs options de fusion :

• Merger le commit : Crée un commit séparé de merge, préservant l'historique de la branche.

• Squash et merge : Combine tous les commits d’une PR en un seul commit ajouté à la branche cible. Utile pour éviter d'encombrer l'historique avec des commits mineurs comme "fixed typo".

• Rebase et merge : Réapplique les commits de la PR sur la branche cible (dans notre cas, il s'agit de develop). On obtient ainsi un historique propre et linéaire.

Dans notre cas, nous choisirons la première option, car nous voulons conserver l'historique complet des livraisons. Cliquez donc sur "Create merge commit".

Voici maintenant la dernière page des opérations de Pull Request. Ici, nous cochons l'option 'Delete branch ...' pour fermer la branche de développement temporaire. L'historique des livraisons reflétera toujours l'existence de la branche. Mais la maintenir ouverte ne sert à rien puisque nous avons atteint notre objectif. Pour les changements futurs qui résoudront d'autres tâches, nous créerons de nouvelles branches. De cette manière, la liste des branches du dépôt fournit toujours un aperçu clair du travail parallèle en cours.

Laissez les autres paramètres tels quels et cliquez sur "Create merge commit".

Le processus est maintenant terminé : la branche article-17698-forge2 a été fusionnée dans develop et supprimée :

En général, l'utilisation des Pull Requests même dans votre propre dépôt est une bonne pratique recommandée, même pour les projets solo. Avant de fusionner, vous pouvez examiner visuellement toutes les modifications, ce qui permet souvent de repérer des éléments qui n'ont pas été pris en compte lors de la validation : commentaires inutiles, fichiers non utilisés ou modifications non optimales. Il s'agit essentiellement d'une forme d'autodiscipline. De plus, l'adoption de ce flux de travail permet de prendre de bonnes habitudes (branches, revue de code, etc.). Ainsi, si vous rejoignez plus tard une équipe de développement, ce processus vous sera déjà familier.

Alors oui, soumettre des PR est non seulement possible, mais encouragé pour tout projet sérieux. Cela améliore la qualité du code et renforce la discipline. Bien sûr, pour des corrections rapides consistant en un ou deux commits, rien ne vous empêche de fusionner directement avec git merge. Mais pour les changements plus importants, il est préférable d'avoir recours à une PR.

Conclusion

Dans l'ensemble, le flux de travail avec les dépôts personnels est maintenant bien établi. Nous avons parcouru le chemin qui mène du clonage des dépôts à l'affinement d'un processus dans lequel les modifications laissent le code fonctionnel et prêt pour un développement ultérieur. Le dépôt du projet peut désormais utiliser de manière significative du code provenant d'un autre dépôt (ou de plusieurs) en tant que bibliothèques.

Cependant, nous n'avons envisagé qu'un seul scénario : lorsque le même utilisateur est propriétaire à la fois du projet et de la bibliothèque. L'autre scénario est celui où le propriétaire du projet veut utiliser les dépôts de quelqu'un d'autre comme bibliothèques. Cette affaire n'est pas aussi simple. Pourtant, ce type de flux de travail, avec la réutilisation active du code de la communauté et la collaboration, était l'un des objectifs déclarés du passage au nouveau système de dépôt. Néanmoins, les bases ont été posées.

Nous nous arrêterons là pour l'instant. Rendez-vous dans la prochaine partie !