Cela fait un moment que je n'ai pas publié d'article sur Embedded Git sur la Communauté des développeurs, et j'aimerais faire le point sur l'énorme quantité de travail que nous avons accompli cette année et sur la direction que nous allons prendre ensuite.

Contexte

Si vous créez des solutions sur IRIS et que vous souhaitez utiliser Git, c'est parfait ! Utilisez simplement VSCode avec un dépôt git local et transmettez vos modifications sur le serveur : c'est aussi simple que cela.

Mais que se passe-t-il si :

• Vous collaborez avec d'autres développeurs sur un environnement de développement partagé et distant et que vous souhaitez éviter de vous marcher sur les pieds en modifiant le même fichier en même temps.
• Vous utilisez des éditeurs basés sur le portail de gestion pour l'interopérabilité ou la veille économique et vous souhaitez un contrôle de source simple pour votre travail, même dans un conteneur local.
• Vous utilisez toujours Studio pour certaines choses et/ou revenez occasionnellement à cet endroit depuis VSCode ; ou votre équipe n'a pas encore complètement adopté VSCode, et certains membres de l'équipe veulent toujours utiliser Studio tandis que d'autres utilisent VSCode.
• Vous travaillez sur un ensemble de projets distincts en même temps dans le même espace de noms - par exemple, plusieurs packages définis à l'aide du gestionnaire de packages InterSystems - et vous souhaitez simplement travailler avec tous à partir d'une seule vue d'édition isfs (plutôt qu'avec un ensemble de projets distincts) avec les modifications suivies automatiquement dans le dépôt git local approprié.

Dans tous ces cas, vous avez vraiment besoin d'un contrôle de source intégré. Vous avez peut-être entendu parler de « contrôle de source côté serveur » ou de « crochets de contrôle de source » - c'est la même chose, et cela signifie qu'il existe un comportement de contrôle de source cohérent dans tous les éditeurs, à la fois IDE et éditeurs graphiques, sur une instance IRIS. Tout cela fonctionne avec un référentiel de contrôle de source colocalisé avec votre instance IRIS, qui peut se trouver sur un serveur distant, votre propre machine ou même dans un conteneur.

Si vous souhaitez vous lancer dans le contrôle de source intégré à l'aide de Git, Embedded Git (https://github.com/intersystems/git-source-control) est l'endroit idéal pour commencer. Ce produit n'est pas pris en charge par InterSystems, mais il bénéficie d'un soutien important de la part de mon équipe (Application Services) au sein d'InterSystems et d'une large communauté d'utilisateurs. Les PR et les problèmes GitHub sont toujours les bienvenus, et nous surveillons l'activité de la communauté des développeurs (en particulier à l'aide de la balise relativement nouvelle « Embedded Git »).

Embedded Git en 2024

Au début de l'année, j'aurais recommandé Embedded Git aux utilisateurs plus techniques déjà à l'aise avec Git et prêts à entrer dans les détails en cas de besoin. Maintenant, je le recommande sans réserve à tout le monde. Pour vous donner une idée des efforts que nous avons déployés pour l'outil et des progrès fous que nous avons constatés en 2024, voici un graphique de notre volume de validation au cours des dernières années :

Si vous voulez voir ce que nous avons fait, vous pouvez consulter les versions ou notre journal des modifications, mais voici un résumé des points forts :

• En juillet, nous avons ajouté un « mode de base » décrit ici avec une opération « Sync » qui simplifie un flux de travail pull/commit/rebase/push que nous recommandons en général, mais surtout pour les personnes moins familiarisées avec Git.
• Dans plusieurs versions, nous avons fait en sorte que les opérations git pull et checkout - en fait, tout ce qui modifie l'état du dépôt Git - se synchronisent de manière transparente dans IRIS afin que tout soit maintenu à jour sans avoir à recharger de force toute la base de code.
• Notre version de septembre a rendu très facile la configuration d'une connexion isfs en téléchargeant un fichier d'espace de travail VSCode à partir du portail de gestion.
• Notre version de novembre a permis de configurer bien plus de choses via la page des paramètres de l'extension plutôt que de devoir exécuter des commandes dans le terminal et a ajouté une résolution intelligente des conflits de fusion pour les deux cas d'utilisation les plus courants (quasi garantis) dans un contexte d'interopérabilité.
• En plus de tout cela, nous avons résolu des dizaines de bugs mineurs et de problèmes d'utilisabilité, simplifié la navigation via le portail de gestion et ajouté de nombreuses fonctionnalités plus petites pour rationaliser les cas d'utilisation d'interopérabilité et la collaboration entre plusieurs espaces de noms spécifiques aux développeurs sur une instance distante partagée (ce que nous considérons et recommandons comme une approche courante).

À venir

Notre prochaine version (2.8.0), attendue dans les deux prochaines semaines, inclura une fonctionnalité sur laquelle nous travaillons depuis des mois : la « décomposition de la production ». La production d'interopérabilité est généralement contrôlée à la source sous forme de fichier unique, ce qui entraîne des problèmes de concurrence car une seule personne peut modifier la production à la fois. Il existe également des conflits de fusion quasi garantis dans les environnements de développement partagés, et bien que nous puissions les résoudre de manière intelligente, ils continueront probablement à se produire dans certains flux de travail de branche. Avec la décomposition de la production, chaque hôte métier (service, processus ou opération) est représenté dans le contrôle de source sous forme de fichier unique. Si vous souhaitez essayer cela, faites-le nous savoir !

Nous allons maintenir la dynamique d'Embedded Git jusqu'en 2025, en nous concentrant sur des méthodes d'authentification supplémentaires et sur la prise en charge d'autres modèles de déploiement courants. Vous pouvez voir le plan approximatif dans notre jalon H1 2025 (qui comprendra quelques versions ; nous publions généralement des versions mineures tous les mois et des versions correctives selon les besoins pour les corrections de bogues clés).

Si vous souhaitez en savoir plus ou suivre le développement au fur et à mesure, nous organisons une réunion hebdomadaire des parties prenantes le vendredi à laquelle vous serez le bienvenu. Cela sert également en quelque sorte de « heures de bureau » pour Embedded Git en général. N'hésitez pas à m'envoyer un message avec votre adresse e-mail et je vous inviterai.