Stratégies avancées de ramification et de fusion (partie 1 sur 2)

Mendix
21 octobre 2016
lecture minute

Dans cette série de blogs en deux parties, je décrirai des stratégies avancées de ramification et de fusion pour des environnements opérationnels complexes. Ces stratégies sont basées sur mon expérience personnelle auprès de clients actuels et passés avec plusieurs projets et une maintenance continue en parallèle les uns des autres.

Dans la première partie, je vais donner une brève description d'une stratégie de base, car je suppose que c'est celle que la plupart des gens utilisent. C'est la stratégie par défaut pour Mendix projets et est directement basé sur les précédents Mendix blogs et la documentation sur les concepts de contrôle de version. Ensuite, j'expliquerai une version de stratégies avancées pour la ramification et la fusion qui adhère au principe « Pas de déchets dans le tronc ». Une deuxième stratégie sera présentée dans le prochain blog.

Je pars du principe que les lecteurs ont une bonne compréhension des bases de la ramification et de la fusion, de Subversion (SVN) et Mendix, comme décrit dans le Mendix documentation sur les concepts de contrôle de version. Cependant, je vais expliquer brièvement comment réaliser la ramification et la fusion dans le modeleur.

Stratégie de base (par défaut) : mettre en avant la ligne principale

Cette stratégie de base est suivie dans la plupart des Mendix projets car il s'agit du point de départ par défaut de chaque projet. Cette approche est souvent poursuivie lorsque le projet est devenu plus important et est déjà en ligne. Dans cette stratégie, la Main Line est utilisée pour presque tous les types de développement : toutes les modifications sont validées sur la Main Line et les déploiements ne sont effectués qu'à l'aide de la Main Line. Les modifications sont validées les unes après les autres, sont généralement mélangées, et les corrections de bogues sont validées par-dessus. Par conséquent, les modifications ne peuvent être livrées que sous forme de « package » – à prendre ou à laisser.

Une fois qu'une version est déployée, les options pour corriger un mauvais déploiement sont limitées. Par exemple, 1) revenir à un package de modèle précédent, 2) annuler les derniers commits (et perdre votre travail) et générer un nouveau package, ou 3) poursuivre le développement et apporter une correction à la partie défectueuse. Cette dernière option est la plus couramment suivie d'après mon expérience jusqu'à présent. Notez qu'une restauration des derniers commits est une option risquée en soi, après quoi il est toujours nécessaire de tester et de valider le nouveau modèle.

Un conseil général bien intentionné : abandonnez cette stratégie de base le plus tôt possible. Par exemple, dès qu'une version stable est déployée dans l'un des environnements de test, ou au plus tard lorsque la première version est réalisée dans l'environnement de production. Bien sûr, vous pouvez vous demander à juste titre : quelle est l'alternative ? Que peut-on faire de mieux ? Où peut-on faire mieux ?

Tout d’abord, vous devez adopter le principe «Pas de déchets dans le coffre.« En général, cela signifie :

TOUS les développements se déroulent dans les succursales (et JAMAIS sur la ligne principale)
La ligne principale est le point de départ général des nouvelles branches
Seules les modifications entièrement testées sont fusionnées dans la ligne principale
Après une fusion vers la branche principale, une fusion vers toutes les branches actives est nécessaire. Il faut également effectuer une fusion vers la branche source si le développement sur la branche se poursuit. Cela est nécessaire pour s'assurer que toutes les branches restent synchronisées.

Stratégie de maintenance et de projets

L’application du principe « Pas de déchets dans le coffre » nous conduit à la stratégie 1 : une stratégie de maintenance et de projets en parallèle. Dans cette stratégie, on distingue les branches suivantes :

Main Line
Une branche de maintenance continue, appelée par exemple Entretien or Business As Usual (BAU)
En option un Projet branche ou branche de fonctionnalité pour les changements majeurs
De plus, il peut y avoir des branches de correctifs pour un petit patch de production

Avec cette stratégie, les changements ne sont effectués que sur les branches : principalement dans le Entretien et Projet branches. Le déploiement dans un environnement de test est effectué sur un package généré à partir de la branche concernée. Une fois les tests terminés avec succès, les modifications sont fusionnées dans la branche principale. Après cela, les commits doivent être fusionnés à nouveau dans toutes les branches actives pour que tout reste synchronisé. Un déploiement en production est effectué à partir d'un package versionné de la branche principale, et parfois à partir d'une ligne de correctifs testée.

Consultez l'illustration ci-dessous pour une représentation visuelle des principales activités de cette stratégie. Le temps s'écoulant de gauche à droite, les trois branches sont représentées par des lignes horizontales : la branche Maintenance, la ligne principale et une branche Projet. Chaque modification validée sur une branche est représentée par un cercle sur cette ligne. Deux séries de modifications ont été effectuées sur la ligne de branche Maintenance et validées (1 et 2). Ces modifications sont initialement testées avec un package de déploiement généré directement à partir de cette ligne. Une fois les tests terminés et acceptés, les modifications sont fusionnées avec la ligne principale. Dans l'illustration, les fusions sont représentées par des flèches. Après la fusion, les modifications sont validées (3), puis fusionnées avec la ligne de branche Projet (4). Enfin, les modifications validées au numéro 3 sont fusionnées à nouveau avec la ligne de branche Maintenance (5) pour s'assurer que toutes les lignes sont synchronisées.

Tableau de ramification et de fusion de projets

Comment effectuer des ramifications et des fusions dans le Mendix modeleur

Pour commencer à utiliser les branches, une condition préalable à tout projet est d'avoir Team Server activé. Le moyen le plus simple de le faire est de démarrer n'importe quel projet à l'aide de Team Server. Faites-le, c'est gratuit de toute façon. Alternativement, cela peut être fait ultérieurement en utilisant l'option Télécharger sur le serveur d'équipe… dans le TEAM menu.

Branchement

Une configuration initiale unique doit être effectuée pour la ligne Maintenance. De nouvelles branches pour les projets seront nécessaires au fur et à mesure que les projets arrivent et partent. N'oubliez pas de nettoyer les anciennes branches de projet. Vous aurez également besoin d'une nouvelle branche pour le développement de fonctionnalités ou les correctifs. Les branches peuvent être créées à l'aide de l'option de menu Gérer les lignes secondaires… du TEAM élément du menu.

Dans le cas d'une nouvelle branche pour la Maintenance ou le Projet, l'origine choisie doit généralement être la dernière version de la Ligne Principale. Dans le cas d'une branche de fonctionnalité ou de correctif, cela dépend de son objet. Une telle branche peut être autonome ou être une sous-branche de la Maintenance ou des Projets.

Quoi qu'il en soit, chaque branche devra fournir ses modifications et au moins la maintenance et le projet. Les branches devront également rester synchronisées, c'est là qu'intervient la fusion. Parfois, les branches de fonctionnalités existent pendant une période plus longue et vous devrez peut-être également les maintenir synchronisées. Si vous ne synchronisez pas les branches, vous rencontrerez tôt ou tard des conflits de versions complexes.

Fusion

La fusion se fait à l'aide de la Fusionner les modifications ici… option dans la TEAM menu. Être confronté à trois options d'emblée peut être intimidant au début. Cependant, lisez attentivement (en fait, vous ne pouvez pas vous tromper ici car les options non valides seront désactivées).

Fenêtre de fusion

La fusion des modifications d'une ligne secondaire vers la ligne principale à partir de la branche Projet ou Maintenance peut souvent être effectuée à l'aide de la Correction du port or Fusionner la branche de fonctionnalités options. Avec le Porter un correctif option, vous pouvez toujours choisir de fusionner une ou plusieurs révisions. Branche de fonctionnalité du port L'option ne le permettra pas et fusionnera toutes les révisions qui n'ont pas été fusionnées auparavant.

Correction du port fenêtre

Branche de fonctionnalité du port fenêtre

En utilisant le modeleur avec l'une des lignes secondaires ouvertes, vous n'aurez pas les deux premières options, ce qui ne laisse que la Fusion avancée option. Là, vous devrez sélectionner la branche à partir de laquelle fusionner, ainsi que la révision de début et de fin qui doivent être incluses dans la fusion. La sélection des révisions est très utile car vous ne souhaitez pas nécessairement tout inclure dans une fusion.

Enfin, notez que toutes les fusions (et toutes les autres actions Subversion) peuvent être effectuées dans le client Tortoise SVN pour Windows. Tortoise SVN facilite également la fusion de réintégration ou la fusion inverse avec une option spéciale. Sachez que toutes les versions ne sont pas compatibles avec le client Tortoise SVN pour Windows. Mendix Configuration SVN. Vérifiez le Mendix Guide de référence pour la version correcte si vous souhaitez utiliser Tortoise.

Personnellement, j'aime faire toutes mes ramifications et fusions dans le Mendix Modeleur. J'ai installé Tortoise pour les icônes qui sont visibles dans l'Explorateur Windows afin de pouvoir voir directement l'état d'un dossier de projet. De plus, Tortoise fournit un visualiseur de fichiers qui peut être déclenché à partir de l'Explorateur Windows. Mendix Modélisateur où vous pouvez comparer différentes versions (en conflit) de fichiers Java, ce qui a été très utile dans certaines occasions.

Conclusion

Quelle est mon expérience avec cette stratégie jusqu'à présent ? Je dois dire qu'elle fonctionne bien et qu'elle constitue un pas en avant vers la maîtrise des changements et des versions. C'est un bon modèle, il est simple et fournit ce qui est nécessaire. Cependant, cette stratégie pose un certain nombre de défis au fil du temps :

Les modifications apportées aux fonctionnalités et aux correctifs peuvent s'accumuler dans une branche de développement et aboutir à un package tout ou rien (plus d'informations à ce sujet dans le prochain blog)
Combiner des branches pour le déploiement dans un environnement de test avec des modifications provenant à la fois d'un projet et des branches de maintenance est difficile, et parfois impossible (lorsque de nombreux conflits surviennent)

Pour conclure, passons en revue l'applicabilité de ces stratégies et les leçons apprises au cours de la période où nous les avons utilisées. La stratégie ci-dessus est utile dans les situations suivantes :

Lorsque vous souhaitez séparer les efforts de maintenance et de projets
Pour les versions comportant plusieurs fonctionnalités et correctifs qui doivent être développés séparément
Pour les pistes de changement à haut risque par rapport à celles à faible risque

Le verdict final concernant la stratégie présentée est qu'il s'agit d'un bon modèle. Il fonctionne bien dans la pratique et est compréhensible. Nous avons utilisé cette stratégie avec succès pendant plus d'un an jusqu'à ce que nous rencontrions de sérieux problèmes en raison de ses limites. Plus d'informations à ce sujet dans la deuxième partie de ce blog.

Lire la partie 2 ici

Merci

Merci à Richard d'avoir planté les graines et de m'avoir fait réfléchir à l'amélioration de la ramification et de la fusion, et de m'avoir également poussé à continuer à m'améliorer. Merci à Reinout, à mes collègues de Sogeti Edzo et Louis, et à l' Mendix Merci aux relecteurs pour leurs commentaires constructifs. Le résultat final n'aurait pas été le même sans eux.

À propos de David de Groot

Travaillant désormais chez Sogeti, David a travaillé avec Mendix David est un développeur certifié depuis de nombreuses années. Il a travaillé dans diverses entreprises néerlandaises et internationales, principalement en tant que consultant en maintenance et en support, mais il est également impliqué par intermittence dans des projets et de nouvelles versions. David a une formation en développement Oracle et PL/SQL et est titulaire d'une maîtrise en intelligence artificielle.