Développement du site en équipe

Je viens de terminer une application Web ASP.NET substantielle (projet de 6 mois) qui a été développée avec 4 autres personnes utilisant Visual Studio 2008, Team Foundation Server et SQL Server 2008 et j’ai été très satisfaite du combo.

Avant Team Foundation Server, nous utilisions Visual Source Safe pour le contrôle des sources. Je ne peux pas vous dire quelle amélioration de TFS était sur VSS.

Certaines de mes fonctionnalités préférées sont:

• Intégration transparente avec Visual Studio
• Contrôle des documents
• Des solutions de gestion de projet comme la fonctionnalité “éléments de travail”
• Capacité de “mettre à l’écart” ce sur quoi vous travaillez pour expérimenter différentes idées

Mis à part les trois, nous n’avons pas eu besoin d’ autres logiciels. Nous mettons en place deux instances de la firebase database, l’une pour le développement et l’autre pour les tests de production. Notre firebase database a été développée en tant que projet de firebase database dans Visual Studio, ce qui la rendait très facile à déployer lorsque nous étions prêts pour un test de production. Cela facilitait également les comparaisons de schémas et les mises à jour entre les deux bases de données de test.

En ce qui concerne le matériel, nous avions un serveur pour TFS et un serveur pour le test des applications. Je suis sûr que vous pourriez combiner les deux.

Pour Embarcadero Developer Network ( http://edn.embarcadero.com ), qui repose sur un budget extrêmement réduit, nous utilisons nos propres PC pour l’environnement de développement. Il y a actuellement 3 développeurs principaux, y compris moi-même.

Étant donné que les membres de mon équipe sont distants, nous avons également des machines virtuelles pour le développement et le débogage qui se trouvent dans le même centre de données que nos serveurs actifs. La communication est essentielle et nous nous appuyons fortement sur Skype ( http://www.skype.com/ ) pour cela.

Pour la gestion du code source, nous utilisons le logiciel gratuit Open Source http://subversion.tigris.org/ . Un bon client Windows à usage général pour SVN est TortoiseSVN ( http://tortoisesvn.net/ ). Un excellent plug-in Visual Studio pour SVN est http://ankhsvn.open.collab.net/ .

Pour les tests unitaires, nous utilisons NUnit ( http://nunit.com ) pour nos tests .NET. Nous utilisons DUnit ( http://dunit.sourceforge.net/ ) pour nos tests de code Delphi.

Avant de vous déployer, il est très important d’avoir un serveur de transfert / test qui n’est PAS une machine de développement pour déployer ce que vous avez l’intention de faire vivre avant de le déployer en direct. C’est le seul moyen fiable de vous assurer que tout ce dont vous avez besoin est déployé sur le serveur en direct.

Pour un déploiement dans un environnement à charge équilibrée, Robocopy (voir http://en.wikipedia.org/wiki/Robocopy pour plus d’informations) est un outil très utile pour garantir que vos serveurs en direct reflètent votre serveur “intermédiaire”. Nous avons un fichier batch “tout faire” qui 1) extrait la dernière version de Subversion, 2) fusionne et minimise nos CSS et JavaScript (avec un outil que j’ai écrit, je le publierai un jour, et un outil de compression JS des fckeditor folks), 3) déploie la dernière version de nos templates, css, images, scripts, etc. sur les serveurs live.

En ce qui concerne nos serveurs, nous utilisons Windows Server 2003. L’édition Standard peut suffire à vos besoins. La plupart de nos serveurs Web fonctionnent bien avec 2 Go de RAM, bien que nous ayons des millions d’utilisateurs. Nos serveurs les plus lourds ont 4 Go de RAM. Presque chaque application Web est équilibrée sur au moins 2 serveurs identiques. Nos serveurs d’applications Web sont principalement des machines virtuelles, mais nos serveurs de bases de données sont toujours des boîtes dédiées avec des exigences de mémoire vive variables. Les machines virtuelles ne vous donnent pas les performances dont vous avez besoin pour les bases de données.

Nous utilisons également principalement InterBase ( http://www.embarcadero.com/products/interbase/ ) et Blackfish SQL ( http://www.embarcadero.com/products/blackfish_sql/ ) comme bases de données, mais la plupart des magasins spécialisés en MS préférerait une certaine saveur de MS SQL.

Nous avons écrit notre propre solution de surveillance pour surveiller les bases de données, les réponses Web et les services Web qui composent EDN, mais vous pouvez trouver quelque chose comme Nagios ( http://www.nagios.org/ ) pour surveiller vos serveurs en direct.

Ensuite, vous avez également besoin d’un système de suivi des problèmes comme Jira ( http://www.atlassian.com/software/jira/ ) FogBugz ( http://www.fogcreek.com/FogBUGZ/ ), BugZilla ( http: // www .bugzilla.org / ), Trac ( http://trac.edgewall.org/ ), qui peut être utilisé avec Subversion, ou autre chose. L’équipe EDN utilise QualityCentral ( http://qc.embarcadero.com ), mais c’est une solution locale non disponible pour les autres.

HTH

Vous aurez besoin d’une forme de contrôle de source qui peut être stockée sur l’un de ces bureaux (pas idéal) ou sur un autre serveur.

En dehors de cela, un tel développement permettra à chaque développeur de répliquer l’environnement sur ses propres machines.

À un moment donné, il serait idéal de pouvoir mettre ce code sur un serveur et le construire à des fins de test et de validation. Cela pourrait être l’un des bureaux si vous n’avez pas le matériel.

Je fais principalement du développement ASP.NET avec une équipe située en Nouvelle-Zélande, au Canada, aux États-Unis d’Amérique et en Israël. Je possède donc une grande expérience du travail en équipe. Sur la base de cette expérience, voici ma liste de must pour le développement d’équipe:

• Un système de contrôle de version vous permettant de stocker et de gérer plusieurs révisions du code source. Pour cela, nous utilisons Subversion , mais tout VCS décent devrait suffire. En plus du code source, nous l’utilisons également pour la documentation partagée et les outils et bibliothèques utilisés par nos applications.
• Un moyen efficace de communiquer avec votre équipe. En raison de notre large répartition géographique, nous nous appuyons fortement sur Skype pour ce faire, en utilisant à la fois des discussions de groupe et des conférences téléphoniques.
• Un processus de construction permettant de créer facilement toutes les bibliothèques et applications partagées. Idéalement, cela devrait être automatisé avec des exécutions programmées vérifiant l’intégrité de la source dans votre VCS. Il existe de nombreux outils pour vous aider (par exemple, MSBuild , NAnt ). Comme nos projets couvrent de nombreux environnements et langages de développement différents (y compris Visual Studio, Delphi, Java, PHP), nous constatons que l’utilisation d’un fichier de commandes pour contrôler ce processus convient parfaitement à nos besoins. Si vous utilisez une approche de développement pilotée par les tests (en suivant TDD à la lettre ou en utilisant une variante adaptée à votre style de développement), il est également recommandé d’exécuter vos tests unitaires au cours de ce processus de génération planifié.
• Un système de gestion de projet, de suivi des tâches et des problèmes. Nous utilisons actuellement Jira pour cela.
• Un référentiel facile à mettre à jour pour le partage d’informations, tel qu’un wiki interne. Nous utilisons pour cela un système de gestion de contenu écrit interne (le même que celui qui anime Embarcadero Developer Network :-)).

En ce qui concerne les exigences matérielles, cela dépendrait beaucoup de vos besoins de développement et de votre budget. Je recommanderais probablement au minimum d’avoir un serveur dédié pour votre VCS. Vous pourriez également probablement le doubler en tant que votre machine de génération, bien que vous souhaitiez peut-être en dédier une autre.

Il peut également être souhaitable d’avoir une machine de test dédiée ou six et un ou plusieurs serveurs de firebase database, mais en fonction du budget, ces fonctions peuvent être partagées comme il convient. La virtualisation peut également constituer un moyen efficace de minimiser les dépenses matérielles tout en maintenant une bonne séparation des fonctionnalités.

Utilisez-vous Visual Studio Team System?

Je recommanderais une sorte de référentiel de code source et très probablement un serveur de génération (fonctionnalités fournies par VSTS).

Bien sûr, il existe d’autres options que les solutions VSTS, y compris des solutions libres et open source.

Pour les équipes de moins de cinq personnes, si vous possédez une licence MSDN, vous pouvez librement bénéficier de l’édition Team Foundation Server Workgroup 🙂

Ce que vous décrivez ne ressemble pas à un problème résolu par le matériel, mais plutôt par la communication et la procédure définie ( le développement de logiciels Agile est une méthodologie). Des logiciels de gestion de code source tels que bazaar , git , mercurial ou subversion peuvent être utiles.

Si quelqu’un dispose d’une boîte supplémentaire, je recommanderais SubVersion … Cela faciliterait la tâche de faire vos commits, check-ins, etc.