Suggestions de déploiement

Question

Je me demande si quelqu'un peut fournir des commentaires constructifs sur la procédure de déploiement que nous utilisons actuellement où je travaille:

• Nous avons trois exemplaires du code séparés dépots Mercurial: Dev, PP (Pre -Production) et Live. Les changements sont effectués sur Dev, poussés sur PP pour les tests d'acceptation utilisateur, puis envoyés sur Live une fois acceptés.
• Les builds sont réalisés en utilisant TeamCity pour créer une version précompilée, les changements ne sont pas faits à la main (tout doit aller dans le contrôle de la source). Les versions sont fournies sous forme d'archives zip sous forme d'artefacts dans TeamCity. Les bibliothèques de classes sont construites à la demande et liées à la construction principale en tant que dépendances, les fichiers Bin sont uniquement conservés dans le contrôle source où nous n'avons pas de code source.
• Les builds sont copiés à la main dans des environnements Live à l'aide de RemoteDesktop et décompressés. Les fichiers web.config sont conservés de la compilation pour être édités manuellement (les mots de passe en direct, etc. ne sont pas conservés dans le contrôle de la source)

Les choses qui me manquent actuellement sont les tests d'unité et d'intégration (idéalement en utilisant NUnit et quelque chose comme le sélénium), mais j'aimerais voir ce que la communauté pense.

Answer 1

Vous pouvez condenser ceci en une instance de contrôle de source unique avec TFS et branchez votre code pour les versions de version. De là, les builds peuvent être auto-animés pour exécuter, tester et déployer pour "tester" chaque nuit/semaine. Votre équipe QA (Quality Assurance) testera ensuite la construction (test supplémentaire en plus des tests automatisés) et approuvera ou rejettera la construction. Si la qualité de construction est appropriée, l'équipe de contrôle qualité peut définir une qualité de construction via Visual Studio ou l'application Barre d'outils de notification de construction ou directement dans le portail TFS. Lorsqu'une construction de qualité appropriée est identifiée, le serveur TFS peut également être configuré pour effectuer une poussée directe depuis son référentiel sur la construction marquée marquée. Le côté positif de tout cela est que l'équipe de développement utilise le même référentiel que l'équipe de contrôle qualité et peut donc directement leur envoyer des "tâches"/rapports de bogues, mais le serveur supprime tout ce qui est déployé manuellement. dans votre architecture. MSBuild comprend également MStest qui, à mon avis, n'est pas si mauvais pour les tests automatisés, car il rapporte (à nouveau à l'équipe de développement et) au gestionnaire de projet des informations sur les bugs et les tâches, il sort aussi de la boîte Agile prêt.

le côté négatif ... peu complexe et fiddly à installer si vous n'êtes pas confiant avec msbuild, mais ce n'est pas une courbe d'apprentissage massive si vous êtes habitué à un environnement MS.

...

Les développeurs ont généralement leur propre « copie » en cours d'exécution sur leur PC de la solution à moins que la solution est extrêmement complexe dans ce cas, un environnement de dev virtualisé complet sur un domaine distinct qui relie la principale domainssource serveur de contrôle peut être le chemin à parcourir.

dépend de la complexité de la solution.