Configuration du modèle de déploiement/déploiement SVN pour les instances de développement Web/UAT/Prod de Sage SalesLogix

Question

J'essaie de configurer l'architecture de contrôle de source de mon organisation pour notre application Web Sage SalesLogix. Nous utilisons SVN.

Nous avons 3 serveurs, un dev, deux pour les tests d'acceptation des utilisateurs, et deux pour la production. Chaque environnement a sa propre base de données.

Nous souhaitons garder les lignes réseau ordonnées, mais cela peut être difficile lors de la gestion du VFS comme SalesLogix le souhaite. Ce que je voudrais faire est ce: - Tous les développeurs utilisent l'instance d'installation DEV de SalesLogix dans App Arch. - Déployez les modifications sur les machines locales pour le test et la révision des unités locales. - Lorsque tous les travaux de développement sont terminés, créez un ensemble de tous les changements dans la révision proposée. - Un gestionnaire de build installe le bundle sur l'instance d'installation UAT. - Compilez et déployez dans les dossiers UAT. - Au moment du rejet, désinstallez le kit et réinstallez-le après les modifications. - Lors de l'acceptation, faites de même pour les serveurs de production et validez les modifications.

Bien que cela signifie que nous avons 3 VFS, cela signifie que nous n'en développons qu'un, ce qui est pour moi le chemin à parcourir.

Suis-je sur la bonne voie dans ma réflexion?

Answer 1

Pour être honnête, je n'ai pas utilisé SVN pour un modèle SalesLogix, mais j'utilise Git exclusivement avec SalesLogix. C'est parce que le fonctionnement de Git correspond mieux au fonctionnement de SalesLogix et de l'Application Architect. Dans des cas normaux, le SCM n'a pas d'importance, mais c'est le cas avec SalesLogix. Pour ne pas dire que SVN ne fonctionnera pas bien avec un modèle SalesLogix, je sais qu'il y en a qui utilisent SVN avec SLX (ça ne sera pas aussi facile qu'avec Git ou Mercurial), mais honnêtement, avec les préférences de côté, le SalesLogix VFS/model fonctionne vraiment bien avec un SCM entièrement distribué. Cela dit, ce que vous décrivez, c'est comment je travaille avec SalesLogix dans Git. Je travaille à créer une branche de développement et fais tout mon travail là-bas. Le maître reflète fondamentalement ce qui est en production afin que je puisse redéployer à la production à tout moment du maître si nécessaire. Dans la branche dev, je fais tout le développement et crée également des branches d'entités pour des fonctionnalités spécifiques. Puis fusionnez à nouveau lorsque la fonctionnalité est terminée. Travailler de cette façon vous permet de développer et de tester tout avant de l'avoir déplacé dans la branche de production. Une fois qu'il est prêt pour le déploiement, je peux facilement passer à la branche de production, puis déployer à partir de là. Si les choses sont rejetées par le contrôle qualité, il suffit de revenir à la branche de production ou de revenir en arrière si nécessaire. De plus, en travaillant de cette manière, vous n'avez besoin que d'un seul VFS ou d'un seul modèle. Pas trois séparés que vous décrivez comme tout vit sur des branches séparées et seulement fusionné dans la branche maître une fois qu'il est entièrement développé et testé. Avec tout cela, cependant, je maintiens toujours des systèmes de test différents de la production (principalement parce que je travaille en tant que partenaire SLX et non client SLX), sinon vous n'avez aucun moyen de tester les paquets pour la livraison. Dans le système de développement, j'utilise le branchement décrit ci-dessus pour me permettre de lancer des corrections en production alors que le développement de nouvelles fonctionnalités est toujours en cours.

J'aimerais avoir des informations SVN plus spécifiques pour vous, mais les concepts sont les mêmes quel que soit le SCM utilisé.