Déploiements et TFS, questions générales

Question

SOX exige que nous ayons un groupe distinct pour déployer notre site web ASP.NET en production.

Actuellement, ce groupe a accès à notre référentiel de code actuel dans VSS et utilise VSS pour déployer le code qui a été vérifié dans VSS.

Comment les déploiements sont-ils généralement effectués pour les applications Web? En tant que développeur, j'ai utilisé la fonction Deploy dans Visual Studio pour déployer du code sur un partage réseau qui correspond à un dossier virtuel IS, mais je ne pense pas que nous puissions nous attendre à ce que le groupe de déploiement achète une copie de Visual Studio juste pour faire des déploiements.

Nous pourrions vérifier le code dans TFS, mais quel est le logiciel minimum dont ce groupe aurait besoin pour effectuer le déploiement? Un accès au client Team Explorer serait-il suffisant? Je suis conscient que Team System a des fonctionnalités pour automatiser la construction d'une application. Les personnes se déploient-elles généralement vers la production en copiant les fichiers aspx et dlls de l'environnement de contrôle qualité vers la production ou déployez-vous normalement à partir de TFS ou même VS directement? Il me semble que l'approche préférée serait de déployer à partir de l'environnement de QA, puisque c'est l'environnement qui doit avoir été approuvé pour la publication ou que ces fichiers doivent être vérifiés dans TFS et déployé à partir de TFS, en supposant que vous pouvez déployer à partir de TFS . Ce qui me déroute, c'est de savoir si les fichiers bin (binaires) qui sont locaux dans le projet vont-ils dans TFS? Est-ce le cas, cela ne crée-t-il pas de problèmes pour les autres développeurs en ce que seulement 1 développeurs (celui avec le binaire vérifié) peut effectivement déboguer car le débogage nécessite un accès en écriture aux binaires? Cela signifie-t-il que les binaires ne doivent pas être vérifiés dans TFS? Mais finalement, si vous déployez à partir de TFS, les binaires doivent être ajoutés à TFS. Sont-ils ajoutés en tant que noeud d'application séparé (compilé)? Si c'est le cas, cela semble vraiment moche. Je suppose que non. Comment s'assurer que les binaires correspondent au code source que nous marquons avec un numéro de version particulier?

De toute évidence, je suis désemparé. Quelqu'un peut-il me donner une idée générale de la façon dont vous gérez le contrôle de version et les déploiements en particulier en utilisant TFS?

Answer 1

Une possibilité minimale (c'est-à-dire relativement simple et utilisant un logiciel libre) utilise des scripts Powershell pour compiler en utilisant MSBuild. Pour travailler avec votre contrôle de source, you can use Subversion, qui peut également être scriptée.

Je vous suggère de faire des recherches sur les scénarios d'intégration continue pour en savoir plus sur ce que vous demandez.

Answer 2

On dirait que vous demandez quelles sont les meilleures pratiques pour utiliser TFS pour les déploiements. Ce book de l'équipe TFS devrait répondre à la plupart de vos questions. La grande différence d'état d'esprit entre TFS & VSS est, par défaut, les extractions TFS ne "verrouillent" pas un fichier d'être édité par un autre développeur. TFS a une capacité de fusion assez décente pour gérer les modifications apportées au même fichier. Les livres TFS expliquent cela de manière beaucoup plus détaillée et pourquoi c'est une bonne chose. En ce qui concerne le traitement des binaires de vos applications, ils devraient normalement être générés par le processus de construction et déployés automatiquement dans l'environnement cible (dev, qa, staging). Les fichiers binaires tiers dont dépend votre code seront archivés avec votre code source pour garantir que le processus de construction dispose de tous les assemblages requis.

Comme vous l'avez mentionné, les déploiements en production doivent être déclenchés manuellement à partir d'un environnement qa ou de mise en attente inaccessible aux développeurs pour se conformer aux règles SOX.Jaxidian fait un bon point sur la recherche de l'intégration continue. TFS prend en charge le déclenchement des générations lors de l'archivage, ce qui rend le CI possible.