Développement de sites web en équipe

Question

Je travaille sur un site web Asp.net avec 4 autres personnes. Le problème que nous rencontrons est le suivant : de quel type de configuration matérielle avons-nous besoin pour permettre le développement en équipe ? Nous avons quatre ordinateurs de bureau individuels, de quel autre matériel aurions-nous besoin ? Quel autre logiciel de développement serait idéal pour ce type de développement ?

Answer 1

Pour l'Embarcadero Developer Network ( http://edn.embarcadero.com ), qui est construit avec 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, dont moi-même.

Comme les membres de mon équipe travaillent à distance, nous disposons également de machines virtuelles pour le développement et le débogage, qui se trouvent dans le même centre de données que nos serveurs réels. La communication est essentielle, et nous nous appuyons fortement sur Skype ( http://www.skype.com/ ).

Pour la gestion du code source, nous utilisons le logiciel gratuit Open Source http://subversion.tigris.org/ . Un bon client Windows polyvalent 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 procéder au déploiement, il est très important de disposer d'un serveur de préparation/test qui n'est PAS une machine de développement pour déployer ce que vous avez l'intention de mettre en production avant de le déployer en production. C'est le seul moyen fiable de s'assurer que tout ce dont vous avez besoin est déployé sur le serveur live.

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 s'assurer que vos serveurs live reflètent votre serveur "staging". Nous avons un fichier batch qui 1) extrait la dernière version de Subversion, 2) fusionne et minimise nos CSS et JavaScript (avec un outil que j'ai écrit et que je publierai un jour, et un outil d'empaquetage JS des gens de fckeditor), 3) déploie la dernière version de nos templates, css, images, scripts, et ainsi de suite, 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 utilisés disposent de 4 Go de RAM. Presque toutes les applications web sont réparties sur au moins deux serveurs identiques. Nos serveurs d'applications web sont pour la plupart des machines virtuelles, mais nos serveurs de bases de données sont toujours des boîtes dédiées dont les besoins en mémoire vive varient. Les machines virtuelles n'offrent pas les performances nécessaires pour les bases de données.

Nous utilisons aussi principalement InterBase ( http://www.embarcadero.com/products/interbase/ ) et Blackfish SQL ( http://www.embarcadero.com/products/blackfish_sql/ ) comme base de données, mais la plupart des entreprises centrées sur MS préfèrent une variante de MS SQL.

Nous avons écrit notre propre solution de surveillance pour contrôler les bases de données, les réponses web et les services web qui constituent EDN, mais vous pouvez trouver quelque chose comme Nagios ( http://www.nagios.org/ ) pratique 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. L'équipe de l'EDN utilise QualityCentral ( http://qc.embarcadero.com ), mais il s'agit d'une solution interne qui n'est pas disponible pour d'autres.

HTH

Answer 2

Vous aurez besoin d'une forme de contrôle des sources qui peut être stockée sur l'un de ces bureaux (ce qui n'est pas idéal) ou sur un autre serveur.

En outre, dans le cadre d'un tel développement, chaque développeur reproduit l'environnement sur sa propre machine.

À un moment donné, l'idéal serait de pouvoir placer ce code sur un serveur et de le construire à des fins de test et de validation. Il pourrait s'agir d'un des ordinateurs de bureau si vous ne disposez pas du matériel nécessaire.

Answer 3

Je développe principalement des applications ASP.NET avec une équipe située en Nouvelle-Zélande, au Canada, aux États-Unis et en Israël, et j'ai donc une grande expérience du travail efficace en équipe. Sur la base de cette expérience, voici ma liste des outils indispensables au développement en équipe :

• Un système de contrôle des versions permettant de stocker et de gérer plusieurs révisions du code source. Pour ce faire, nous utilisons Subversion mais n'importe quel VCS digne de ce nom devrait suffire. Outre le 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 distribution géographique, nous nous appuyons fortement sur les services suivants Skype pour cela, en utilisant à la fois les chats de groupe et les conférences téléphoniques.
• Un processus de construction permettant à toutes les bibliothèques et applications partagées d'être facilement construites. Idéalement, ce processus devrait être automatisé, avec des exécutions de construction programmées vérifiant l'intégrité de la source dans votre VCS. Il existe de nombreux outils pour vous aider dans cette tâche (par ex. MSBuild , NAnt ). Comme nos projets couvrent de nombreux environnements de développement et langages différents (y compris Visual Studio, Delphi, Java, PHP), nous trouvons que l'utilisation d'un fichier batch pour contrôler ce processus répond bien à nos besoins. Si vous utilisez une approche de développement pilotée par les tests (soit en suivant le TDD à la lettre, soit en employant une variante qui convient à votre style de développement), il est également recommandé d'exécuter vos tests unitaires au cours de ce processus de construction programmé.
• 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 facilement actualisable pour le partage d'informations, tel qu'un wiki interne. Nous utilisons pour cela un système de gestion de contenu écrit en interne (le même que celui qui gère le site web de Réseau de développeurs Embarcadero en fait :-)).

En ce qui concerne les exigences matérielles, cela dépend beaucoup de vos besoins réels en matière de développement et de votre budget. Je recommanderais probablement d'avoir au minimum un serveur dédié pour votre VCS. Vous pourriez également doubler ce serveur pour votre machine de construction, bien que vous puissiez vouloir un serveur dédié pour cela aussi.

Il peut également être souhaitable de disposer d'une ou de six machines de test dédiées et d'un ou de plusieurs serveurs de base de données, mais en fonction du budget, ces fonctions peuvent être partagées le cas échéant. La virtualisation peut également être un moyen efficace de minimiser les dépenses en matériel tout en maintenant une bonne séparation des fonctionnalités.

Answer 4

Ce que vous décrivez ne ressemble pas à un problème résolu par le matériel, mais plutôt par la communication et une procédure définie ( Développement de logiciels agiles est une méthodologie). Logiciel de gestion du code source tel que bazar , git , mercuriale ou subversion peut s'avérer utile.

Answer 5

Utilisez-vous Visual Studio Team System ?

Je recommanderais une sorte de dépôt de code source et très probablement un serveur de construction (fonctionnalités fournies par VSTS).

Bien entendu, il existe d'autres options que VSTS, notamment des solutions gratuites et open source.