Des outils pour aider un petit magasin à obtenir de meilleurs résultats au « test Joel »

Question

Questions n°1 à n°4 sur le Joël Test à mon avis, tout dépend des outils de développement utilisés et du système de support en place pour les développeurs :

1. Utilisez-vous le contrôle de source ?
2. Pouvez-vous réaliser une construction en une seule étape ?
3. Faites-vous des builds quotidiennement ?
4. Avez-vous une base de données de bugs ?

Je suis simplement curieux de savoir quels outils gratuits/bon marché (mais bons) existent pour les petits ateliers de développement qui ne disposent pas de grands comptes bancaires à utiliser pour obtenir une réponse positive à ces questions.

Pour le contrôle de code source, je sais que Subversion est une excellente solution, et si vous êtes une entreprise individuelle, vous pouvez même utiliser celui de SourceGear. Sauter.

J'utilise NAnt pour mes projets plus importants, mais je n'ai pas encore configuré de script pour créer mes installateurs ni exécuter les outils d'obscurcissement en une seule étape.D'autres suggestions?

Si vous pouvez répondre oui à la construction en une seule étape, je pense que créer des builds quotidiens serait facile, mais quels outils recommanderiez-vous pour automatiser ces builds quotidiens ?

Pour une équipe d'un ou deux hommes, il a déjà été discuté sur SO que vous pouvez utiliser FogBugz On Demand, mais quelles autres solutions de suivi de bugs existent pour les petites équipes ?

Answer 1

1. contrôle des sources : Subversion ou Mercuriel ou Git
2. construire l'automatisation : NANT, MSBuild, Râteau, Maven
3. Intégration continue: CruiseControl.NET ou Continuum ou Jenkins
4. suivi des problèmes : Traçage, Bugzilla, Gémeaux (si ce doit être .NET et gratuit)

N'oubliez pas les tests automatisés avec NUnité, Ajuster, et Watin.

Answer 2

1) Subversion

2) Fourmi / Maven

3) Continuum

4) Bugzilla / Traçage

Answer 3

Ma pile préférée :

1) Subversion.Je suis intrigué par le contrôle de source distribué, mais je n'ai pas encore eu l'occasion d'en essayer avec colère.Pour une solution centralisée, SVN est solide comme le roc.

2) Fourmi.Maven est un plaisir à utiliser lorsqu'il fonctionne, mais en tant que vieux hacker de fourmis, je trouve que Maven est difficile à suivre une fois que les choses tournent mal.

3)Hudson.Cela n'a pas été mentionné jusqu'à présent mais mérite vraiment d'être étudié.Outil incroyablement utilisable et activement entretenu.Auparavant, nous avions payé pour Anthill Pro, qui semblait floconneux et pénible à réparer à chaque fois qu'il plantait.

4) Nous payons pour Jira.Pas bon marché mais beaucoup plus utilisable que les options open source que nous avons examinées et très flexibles également.

Answer 4

Ma pile d'ingénierie :

1. Git (j'adore GitHub, mais Git ne nécessite pas de solution hébergée)
2. Râteau
3. CruiseControl.rb
4. BrouillardBugz

Nul doute que ces choix sont influencés par ma pile de développement, qui comprend le plus souvent Ruby, Rails, SQLite, Firefox et OSX.

Answer 5

Vous voudrez peut-être examiner une de mes questions existantes pour trouver une alternative au Team System.Il contient également de nombreuses recommandations.

Answer 6

1. Git
2. Faire
3. Cron
4. Traçage

Je suis un homme de quelques syllabes ;-)

Assurez-vous d'utiliser une sorte de contrôle de version où les développeurs peuvent facilement créer des branches privées bon gré mal gré, puis prendre leur branche privée et la regrouper dans un seul commit sur la branche principale.De cette façon, les développeurs individuels, par opposition à l'organisation, peuvent bénéficier des avantages du contrôle de version sans polluer le code de quelqu'un d'autre (et ralentir leur travail) avec des validations rompues.

Cette fonctionnalité est ce que j’aime chez git.Je pense que ce n'est vraiment présent que dans les systèmes de contrôle de version distribués ;Cependant, l'utilisation d'un DVCS ne signifie pas que vous devez réellement effectuer un développement distribué.

Concernant la construction en une étape, make est l'outil de construction par défaut et il fonctionne plutôt bien pour la plupart des tâches.J'irais avec ça à moins que vous n'ayez une bonne raison de ne pas le faire.

Vous voulez des builds quotidiens, mettez la commande build dans votre cron.daily.Configurez un hook procmail pour gérer le courrier de cron si nécessaire.

Pour le suivi des bogues, utilisez $(apt-cache search bug tracking).Fondamentalement, tant qu'il est écrit "bug tracker" sur la boîte et que vous savez que d'autres personnes l'utilisent, cela fonctionnera probablement bien.Parmi les habitués figurent bugzilla, mantis et trac.

Answer 7

Je n'ai aucun outil à suggérer, mais j'ai une suggestion concernant les builds quotidiens.Je réponds toujours oui à cette question, même si nous n'avons pas de builds quotidiens.Au lieu de cela, nous effectuons une construction à chaque fois que quelqu'un effectue un commit.Nous détectons ainsi tout problème presque immédiatement.Si l'un de nos projets dispose de suffisamment de LOC pour que la construction prenne plus que du temps, cela se dégradera également gracieusement dans le sens d'une construction quotidienne.

Answer 8

Un bon système de suivi des problèmes relativement peu coûteux était axoSoft OnTime.Je l'ai utilisé pendant des années avant d'acquérir MS TFS.

Nant et Régulateur de vitesse sont des incontournables de mon environnement.

Answer 9

Je ne pense plus que vous ayez vraiment besoin d'obscurcissement sur .Net (voir une autre réponse)

Je ne considérerais pas Vault, SVN est vraiment le leader du marché en ce moment (et gratuit).Git semble assez prometteur, mais il s'agit actuellement d'une ligne de commande uniquement avec une courbe d'apprentissage abrupte.

MSBuild bat NAnt pour .Net 2 ou 3.5

CC.Net est excellent.

Answer 10

*4) Redmine

je recommande Bitnami pour tester différentes piles.Il contient Trac, Redmine et Subversion, ainsi que plusieurs autres sans rapport.

Answer 11

Consultez ces articles sur l'intégration continue à l'aide de MSBuild, CruiseControl.NET, FxCop, NUnit, NCover et Subversion...

Depuis les tranchées du développement logiciel

Answer 12

J'utilise actuellement SVN mais j'ai généralement eu beaucoup de problèmes avec les extractions sur un lecteur réseau sur un serveur de développement.Il y a généralement des problèmes de verrouillage qui nécessitent beaucoup de pêche pour être résolus.Il se peut que l'utilisation de la méthode d'accès WebDav réduise certains de ces problèmes, mais je n'ai pas encore expérimenté.

Bugzilla, Trac ou Fogbugz vous aideront dans votre suivi des bogues et chacun offrira une fonctionnalité d'exportation, afin que vous puissiez toujours changer d'avis plus tard.De plus, si vous parvenez à rallier pleinement votre équipe, un logiciel de gestion du temps peut également être utile pour les autopsies, etc. (si tout le monde est motivé à participer pleinement.

Answer 13

Pour l'automatisation de la construction et l'intégration continue, jetez un œil à ÉquipeCité depuis Jetbrains.

Il y a beaucoup de caractéristiques et c'est vraiment un jeu d'enfant à installer et à utiliser.

Si vous utilisez Visual Studio 2005/2008, votre solution sera construite directement sans avoir besoin de scripts supplémentaires (si une version est tout ce que vous souhaitez.)

Il exécutera également vos tests unitaires et rassemblera des statistiques sur le succès de la construction, les temps d'exécution des tests unitaires, etc.

Le meilleur de tous:L'édition Pro est gratuite pour les équipes comptant jusqu'à 20 utilisateurs et 3 agents de build.

Answer 14

1. contrôle des sources :CV
2. construire gnu faire
3. travail cron qui appelle des scripts bash
4. bugzilla