2008-08-18 17 views
16

las preguntas # 1 a # 4 en la Joel Test en mi opinión son todos acerca de las herramientas de desarrollo que se utiliza y el sistema de apoyo en el lugar para los desarrolladores:herramientas para ayudar a una pequeña tienda de mayor puntuación en el "Test de Joel"

  1. ¿Utiliza el control de fuente?
  2. ¿Se puede construir en un solo paso?
  3. ¿Hace compilaciones diarias?
  4. ¿Tiene una base de datos de errores?

Tengo curiosidad por saber qué herramientas gratuitas/baratas (pero buenas) existen para las pequeñas tiendas de desarrollo que no tienen grandes cuentas bancarias para usar para lograr una respuesta positiva en estas preguntas.

Para control de fuente, sé que Subversion es una gran solución, y si usted es una tienda de un solo hombre, incluso podría usar SourceGear's Vault.

Uso NAnt para mis proyectos más grandes, pero aún tengo que configurar un script para construir mis instaladores, así como ejecutar las herramientas de ofuscación todo en un solo paso. ¿Cualquier otra sugerencia?

Si puede responder sí al edificio en un solo paso, creo que crear compilaciones diarias sería fácil, pero ¿qué herramientas recomendaría para automatizar esas compilaciones diarias?

Para un equipo de uno o dos hombres, ya se ha discutido en SO que puede usar FogBugz On Demand, pero ¿qué otras soluciones de seguimiento de errores existen para los equipos pequeños?

Respuesta

0

Un rastreador de problemas que era relativamente barato era axoSoft OnTime. Lo utilicé durante años antes de obtener MS TFS.

Nant y CruiseControl son elementos básicos de mi entorno.

0

No creo que realmente necesite ofuscación en.Net más (see another response)

No consideraría Vault, SVN es realmente el líder del mercado en este momento (y gratis). Git parece bastante prometedor, pero actualmente solo tiene línea de comando con una curva de aprendizaje pronunciada.

MSBuild late de NAnt para .Net 3.5 o 2

CC.Net es excelente.

2

Mi pila de ingeniería:

  1. Git (Me encanta GitHub, pero Git no requiere una solución alojada)
  2. Rake
  3. CruiseControl.rb
  4. FogBugz

Sin duda, estas opciones están influenciadas por mi paquete de desarrollo, que a menudo incluye Ruby, Rails, SQLite, Firefox y OSX.

0

* 4) Redmine

recomiendo Bitnami para poner a prueba diferentes pilas. Tiene Trac, Redmine y Subversion, así como varios otros que no están relacionados.

2

No tengo ninguna herramienta para sugerir, pero tengo una sugerencia sobre las compilaciones diarias. Siempre respondo que sí a esa pregunta, a pesar de que no tenemos compilaciones diarias. En cambio, hacemos una compilación cada vez que alguien hace un commit. Por lo tanto, detectamos cualquier problema casi de inmediato. Si alguno de nuestros proyectos tiene suficiente LOC, esa construcción lleva más que un tiempo trivial, y esto también se degradará graciosamente en la dirección de una construcción diaria.

+0

¿Reconstruye todo lo que (de manera probable) depende del código comprometido? En algunos casos (cambio en uno de los componentes básicos) puede causar la reconstrucción de toda la aplicación.¿Cómo manejas el tiempo de construcción ~ hora para un compromiso? Gracias. – TcKs

+0

Después de una confirmación, esperamos 60 segundos para ver si llegan más confirmaciones. Esto sobre todo evita construir un árbol con solo uno de varios commits relacionados. Construimos todo lo que depende del código comprometido. Para nuestro proyecto "toolkit", puede tratarse de 10 aplicaciones. La compilación para nuestra aplicación más grande (~ 200k líneas de Java) lleva <1 min en nuestro cuadro de compilación. Aun así, los commits pueden llegar durante la compilación, en cuyo caso volveremos a compilar tan pronto como finalice la primera compilación. Si nuestras versiones se vuelven más largas, habrá más posibilidades de que esto suceda. Eventualmente, teóricamente llegaríamos a una situación en la que el cuadro de compilación siempre se está construyendo. –

0

actualmente estoy usando SVN, pero en general he tenido una mucho o problema con las transferencias a una unidad de red en un servidor de desarrollo. Suele haber problemas de bloqueo que requieren mucha pesca para solucionarlos. Puede ser que usar el método de acceso WebDav alivie algunos de estos problemas, pero aún no lo he experimentado.

Cualquiera de Bugzilla, Trac o Fogbugz lo ayudará con el seguimiento de errores, y cada uno ofrece una función de exportación, para que siempre pueda cambiar de opinión más adelante. Además, si usted puede conseguir su equipo para comprar totalmente en software de gestión de tiempo puede también ser útil para autopsias, etc (si todo el mundo está motivado para participar plenamente

3

Mi pila preferido:.

1) Subversion . Estoy intrigado por el control distribuido de la fuente, pero aún no he tenido la oportunidad de probarlo con ira. Para una solución centralizada svn es sólida como una roca.

2) Ant. Maven es un placer usarlo cuando está funcionando pero, como un viejo hacker de hormigas, creo que maven es difícil de seguir una vez que las cosas salen mal.

3) Hudson. No se ha mencionado hasta ahora, pero definitivamente vale la pena investigar.Herramienta increíblemente útil y mantenida activamente. PreviousLy pagamos por Anthill Pro, que parecía flaky y era doloroso de arreglar cada vez que se estropeaba.

4) Pagamos por jira. No es barato, pero es mucho más útil que las opciones de código abierto que vimos y muy flexible también.

0

Para la automatización de compilación y la integración continua, eche un vistazo a TeamCity desde Jetbrains.

Tiene un montón de features y es realmente muy fácil de configurar y usar.

Si utiliza Visual Studio 2005/2008 se va a construir su solución directamente sin la necesidad de secuencias de comandos adicionales (si la acumulación es todo lo que quiera.)

También ejecutará las pruebas unitarias y recopilar estadísticas sobre la acumulación éxito, tiempos de ejecución de pruebas unitarias, etc.

Lo mejor de todo: la edición Pro es gratuita para equipos con hasta 20 usuarios y 3 agentes de compilación.

2
  1. Git
  2. Hacer
  3. Cron
  4. Trac

Soy un hombre de pocas sílabas ;-)

Asegúrese de utilizar algún tipo de control de versiones, donde los desarrolladores pueden crear fácilmente sucursales privadas de cualquier forma, luego tomar su rama privada y exprimirla en una sola confirmación en la rama principal. De esta forma, los desarrolladores individuales, a diferencia de la organización, pueden obtener los beneficios del control de versiones sin contaminar el código de nadie (y ralentizar su trabajo) con compromisos fallidos.

Esta característica es lo que me gusta de git. Creo que solo está realmente presente en los sistemas de control de versiones distribuidas; Sin embargo, usar un DVCS no significa que realmente tengas que hacer un desarrollo distribuido.

En cuanto a la construcción en un solo paso, make es la herramienta de compilación predeterminada y funciona bastante bien para la mayoría de las tareas. Me iría con eso a menos que tengas una buena razón para no hacerlo.

Desea compilaciones diarias, ponga el comando de compilación en su cron.daily. Configure un gancho de procmail para manejar el correo de cron si es necesario.

Para el seguimiento de errores, use $(apt-cache search bug tracking). Básicamente, siempre y cuando indique "rastreador de errores" en la caja y sepa que otras personas lo están utilizando, probablemente funcione bien. Entre los asiduos se encuentran bugzilla, mantis y trac. Control

0
  1. fuente: cvs
  2. acumulación GNU make
  3. tarea de cron que llama scripts bash
  4. Bugzilla
Cuestiones relacionadas