Outils de gestion du contrôle de version | Mendix Guide d'évaluation

Comment La Mendix Soutenir le développement multi-utilisateur ?

Mendix Studio Pro combine le développement multi-utilisateurs pour différents niveaux de compétence. Vous trouverez plus d'informations dans Développement App.

Au début d'un projet, tous les membres de l'équipe peuvent travailler ensemble sur la ligne principale du référentiel de contrôle de version. Mendix Les utilisateurs de Studio Pro peuvent partager les mises à jour de l'application avec le reste de l'équipe en utilisant le modèle de mise à jour et de validation via le référentiel de contrôle de version.

Comment fonctionne le contrôle de version dans Mendix?

Mendix prend en charge l'utilisation d'un référentiel de contrôle de version centralisé basé sur Git, qui est le Mendix Serveur d'équipe. Chaque projet construit à l'aide de Mendix La plateforme est livrée avec le système de contrôle de version Team Server. Le Team Server utilise la technologie Git et permet à plusieurs développeurs de travailler sur le même projet, en fusionnant en permanence les modifications du modèle dans les révisions conservées dans le référentiel de contrôle de version. Pour les applications basées sur Mendix 9 ans et moins, Mendix prend également en charge les référentiels basés sur Subversion (SVN).

Ce diagramme présente les Mendix architecture de contrôle de version :

Les développeurs peuvent gérer les révisions et les conflits ainsi que créer des branches, qui peuvent être fusionnées dans une branche principale si nécessaire. Chaque modification de la plateforme est enregistrée et comparée aux autres révisions pour détecter les conflits et gérer les mises à jour. Les utilisateurs sont invités à participer à des projets d'application via le Mendix Portail et des rôles de sécurité attribués, qui leur permettent d'accéder aux droits d'accès appropriés aux modèles détenus dans Team Server.

Comment puis-je croiser les user stories et les commits de modification d'application ?

Mendix fournit une expérience de développement intégrée entre le référentiel de versionnage Team Server, le tableau de bord du projet d'application et Mendix Studio Pro. L'intégration de la Mendix Référentiel de versions Team Server avec l'application Project Dashboard et Mendix Studio Pro présente les avantages significatifs suivants :

• Il offre aux membres de l'équipe un méthode intégrée pour suivre les exigences tout au long du cycle de développement et de livraison. Lorsque vous commencez à travailler sur votre application, il vous suffit d'ouvrir Mendix Studio Pro pour voir les user stories prévues pour le Sprint en cours et commencer à travailler dessus.
• Lorsque les membres de l'équipe valident les modifications du modèle d'application sur le serveur d'équipe à partir de Mendix Studio Pro, ils peuvent sélectionner les user stories sur lesquelles ils ont travaillé. Le Team Server créera automatiquement des liens entre les user stories et les modifications de modèle apportées, offrant ainsi un moyen de naviguer des commits aux exigences associées.
• Les utilisateurs finaux peuvent fournir commentaires directement depuis l'interface utilisateur de l'application, et ce feedback peut être transféré dans une user story. En tant que développeur, vous pouvez accéder directement au formulaire mentionné dans les métadonnées du feedback et implémenter le changement demandé.
• Les membres de l'équipe peuvent commencer discussions dans l'application Buzz sur les fonctionnalités implémentées (par exemple, sur une page de tableau de bord ou une logique métier dans un microflow). À partir de ces discussions, de nouvelles user stories peuvent être créées et implémentées dans Mendix Studio Pro. Lorsque les commits du modèle sont liés à l'histoire de l'utilisateur, le cycle de rétroaction complet est prêt et également référencé.

Comment puis-je utiliser mon propre référentiel au lieu de Mendix Serveur d'équipe ?

À côté de la centrale par défaut Mendix Référentiel de gestion des versions de Team Server, vous pouvez choisir de configurer votre propre référentiel Git sur site comme référentiel de gestion des versions pour vos applications. Mendix 8 et 9, nous prenons également en charge les référentiels SVN sur site.

Pour plus de détails sur la configuration, voir Travailler avec le serveur de contrôle de version sur site Git dans le Mendix Guide de Studio Pro.

Comment La Mendix Prise en charge de la ramification et de la fusion ?

Un projet de développement commence toujours par une seule ligne de développement, appelée ligne principale. C'est cette ligne de développement qui va guider le processus de développement.

Un déploiement à partir de la ligne principale doit contenir toutes les fonctions (publiées) de l'application. En plus de la ligne principale, un projet peut avoir plusieurs lignes de branche. Les branches sont créées à partir d'une validation (révision) spécifique vers la ligne principale ou une ligne de branche. La création d'une branche signifie qu'une copie est effectuée de la révision sélectionnée qui sera utilisée comme révision de départ pour la nouvelle ligne de développement. Cela permet au développeur de modifier le modèle dans une ligne isolée. Dans la plupart des cas, une ligne de branche est utilisée pour résoudre les problèmes dans une version publiée de l'application en même temps que le développement en cours se poursuit dans la ligne principale. Cela permet un nouveau développement dans la ligne principale sans la publication de fonctionnalités qui n'ont pas été finalisées ou testées. Après avoir créé une branche et résolu le problème (ou créé une nouvelle fonctionnalité importante), il est possible de fusionner ces modifications avec la ligne principale.

Grâce au MendixDans l'approche de développement pilotée par modèle de , la fusion des modèles s'effectue avec un niveau de précision plus élevé que la fusion du code. C'est parce que Mendix comprend la sémantique des modèles. Cela entraîne moins de conflits et, si des conflits surviennent, ils peuvent être résolus de manière Mendix Studio Pro grâce aux mécanismes de vérification de cohérence décrits ci-dessus.

Mendix prend en charge la création et la fusion de branches dans le Mendix Référentiel de gestion des versions de Team Server. En plus de cela, il est possible d'étiqueter des révisions spécifiques avec une étiquette de version. Cela permet aux équipes d'utiliser des modèles sectoriels, comme des branches de version et des branches de fonctionnalités. Par défaut, le Mendix Les pipelines de déploiement utilisent également le balisage de révision pour étiqueter les révisions de version avec des moments spécifiques du pipeline de déploiement. Cela peut être utilisé à des fins d'audit et de restauration de version.

Quelles API de référentiel de versions sont disponibles pour les intégrations de versionnage personnalisées ?

Mendix la fonctionnalité de contrôle de version est exposée via un API dans le référentiel Team Server afin qu'il puisse être appelé par d'autres services de la plateforme ou des applications externes. Par exemple, un obtenir le dernier commit l'appel à l'API du référentiel de gestion des versions de Team Server pour un projet d'application renverra la dernière révision des artefacts du projet.

Comment puis-je consulter les modifications apportées par d’autres développeurs après avoir effectué une mise à jour ?

Lors de la récupération de nouvelles mises à jour à partir du Mendix Serveur d'équipe dans Mendix Studio Pro, le développeur a un contrôle total sur les modifications à accepter ou à annuler. Après la mise à jour, toutes les modifications sont fusionnées dans le modèle local. Lorsqu'il existe un conflit de fusion entre les modifications apportées par le développeur et la mise à jour du Mendix Team Server permet au développeur d'obtenir un aperçu de tous les conflits de fusion. Ces informations peuvent être utilisées pour déterminer si la modification locale ou la modification du Team Server doit être utilisée.

À tout moment, le développeur contrôle les modifications et les conflits de fusion acceptés. Les modifications peuvent être rétablies dans la version d'origine avant de valider à nouveau la version finale sur Team Server.

Comment La Mendix Prise en charge des différences de versions et de la résolution des conflits ?

Mendix Studio Pro intègre une fonction de comparaison sur le modèle d'application. Cela signifie que lorsque le développeur récupère les modifications du référentiel de contrôle de version pour tous les documents de l'application (comme les pages, les microflux et les intégrations), les deux versions sont comparées. Mendix Studio Pro vérifie qu'il n'existe pas de modifications conflictuelles, puis fusionne automatiquement les deux versions. Les modifications résultantes peuvent toujours être examinées avant de valider à nouveau la dernière version dans le référentiel de contrôle de version. Le développeur a le contrôle total du processus.

Quelles sont les capacités de résolution des conflits dans Mendix Studio Pro ?

Lorsque les modifications entraînent un conflit (par exemple, vous modifiez une page qui avait été supprimée par un autre développeur), Mendix Studio Pro vous indiquera que ce conflit doit d'abord être résolu.

Mendix Studio Pro permet de résoudre les conflits en affichant des informations détaillées sur les différences entre deux versions d'un document (par exemple, lorsque vous modifiez une liste sur une page, puis qu'un autre membre de l'équipe supprime la liste de cette page). Lorsqu'un document est marqué comme étant en conflit, vous pouvez voir les raisons détaillées du conflit et utiliser un mécanisme de résolution de version précis. Vous n'avez pas à choisir entre des documents entiers. Au lieu de cela, vous pouvez résoudre les conflits au niveau des éléments individuels à l'intérieur des documents (tels que les widgets, les entités, les attributs ou les actions de microflux). Toutes les modifications non conflictuelles des deux côtés sont acceptées automatiquement. Pour plus d'informations sur l'utilisation de la résolution des conflits, voir Nouvel algorithme de fusion avec résolution de conflit à granularité fine dans le Guide de Studio Pro.

Mendix Studio Pro peut également gérer les conflits au niveau d'une application. Vous pouvez résoudre un conflit d'application en choisissant « ma version » ou en supprimant les documents ou dossiers concernés.

Voici deux exemples:

• Un développeur supprime un document et un autre apporte une modification à l'intérieur de ce document
• Les deux développeurs déplacent un document, mais ils le déplacent vers des endroits différents dans l'arborescence

Si un dossier (ou un module) entier a été supprimé et qu'un autre développeur modifie un document à l'intérieur de ce dossier, le dossier est restauré localement et également marqué comme étant en conflit. De cette façon, vous savez que l'intention était de supprimer ce dossier, mais qu'il a été restauré pour montrer le contexte du document modifié.

Comment puis-je résoudre les conflits dans les fichiers externes tels que les classes Java, les widgets et les images ?

Par défaut, Mendix Studio Pro effectue une comparaison différentielle sur des fichiers externes comme des classes Java. Lorsqu'il existe de nouvelles versions ou que des fichiers ont été supprimés, cela est directement géré par Mendix Studio Pro lui-même.

Pour une résolution supplémentaire des différences ou des conflits sur des fichiers externes, des outils visuels et de ligne de commande externes pour Git et SVN peuvent être utilisés.