version-control - tool - like jira open source

¿Qué tan importante es una herramienta de seguimiento de errores para un desarrollador solitario, y cuál junto con un VCS debería ver? (10)

Esta podría ser una pregunta estúpida, pero si soy un desarrollador solitario y solo estoy trabajando en mi computadora portátil de desarrollo, ¿qué tan importante es el uso del software de seguimiento de errores? Actualmente estoy debatiendo entre utilizar Subversion o SourceGear Vault como mi VCS de elección, y SourceGear tiene un rastreador de fallas integrado (Fortress) mientras que el mundo de Subversion tiende a usar algo como Trac.

Ahora, voy a usar mi computadora portátil para proyectos domésticos y de trabajo (tengo una suscripción de MSDN para mí, y dado que el trabajo es demasiado barato para comprarme cualquier cosa, voy a escribir su software en mi computadora portátil para usarlo; tenemos esto especificado en mi contrato que poseo todo el código que escribo como si fuera un consultor, aunque soy un FTE), y en el trabajo voy a configurar Subversion porque es gratis y no hay presupuesto (por lo que Supongo que eso significa que debería usar SVN en casa también). Un rastreador de errores podría ser beneficioso en el trabajo para realizar un seguimiento de las cosas una vez que el software está hecho, pero ¿qué pasa para uso personal?

Recuerda, mi computadora portátil solo será para desarrollo, así que me temo que si pongo SVN (tengo que mantener ese repositorio separado del trabajo, después de todo) y luego Trac o alguna otra cosa, voy a convertirlo en un mini servidor, o eso es algo bueno? Y ni siquiera he analizado una solución de CI todavía, pero sinceramente, no veo el sentido de la IC si solo va a utilizar una sola máquina. Eso puede cambiar para el futuro, pero por ahora todo mi trabajo se va a hacer en esta computadora portátil.

¿Alguna sugerencia?

Creo que deberías ir con FogBugz . Está en línea, es gratuito para 2 desarrolladores, se integra con su control de origen. Creo que el seguimiento de errores es secundario al control de la fuente en términos de gestión de proyectos, especialmente para un único desarrollador. Debe poder saber cuándo ha solucionado todos los errores informados para poder predecir una fecha de envío en una función, etc. etc.

Un proceso de compilación automatizado le quitará una enorme carga para poder crear su software bajo demanda (en caso de borrado, etc.). Un proceso de CI puede ser un poco exagerado, pero la regla de construcciones automatizadas.

Si está preocupado por ponerlo en su computadora portátil pero aún desea imprimir el suyo, puede ir a slicehost y obtener en línea una caja de ubuntu para una solución de subversión / trac por 20 dólares al mes. Lo hago para algunos de mis proyectos personales ...

El verdadero valor de un rastreador de errores es que no pierde la pista de nada que deba corregirse. Esto es probablemente más importante si solo hay uno de ustedes como si hubiera más porque no hay nadie más que le recuerde lo que ha olvidado. Puedo recordar un proyecto en el pasado donde teníamos un simple error tipográfico y solo un desarrollador de aplicaciones (yo era el desarrollador de db) y no tenía tiempo para hacerlo el día que el CEO lo planteó y un par de meses más tarde, cuando el CEO se dio cuenta de que todavía estaba allí, se volvió loco. Cuando haces malabares con un montón de tareas y posibles errores, es muy fácil perder de vista algo (especialmente algo que consideras trivial). Ese incidente nos permitió obtener un rastreador de errores y poner todas las tareas, no solo errores, y fue una de las mejores cosas que hicimos. Solo poder decirle al cliente cuando quiere algo nuevo, "Bueno, aquí está mi lista actual de tareas. ¿Qué tan importante es en comparación con estas cosas?" hace que valga la pena su peso en oro, especialmente cuando eres la única persona. Le ayudará a estimar el tiempo y le dará un lugar para documentar las discusiones y decisiones sobre la tarea para que nadie pueda volver más tarde y decir que no sabía que lo haría.

Estoy de acuerdo con JPunyon en que debes usar Fogbugz para el seguimiento de errores. Lo uso para mis cosas personales y es brillante. Si bien un rastreador de errores no es esencial (aunque útil) si está solo, el control de código fuente es esencial. Mi producto de elección ahora es Perforce, que proporciona una copia de 2 usuarios completamente funcional que puede descargar y usar. Requiere muy pocos recursos y es fácilmente transferible cuando actualiza las máquinas. Hay un poco de una curva de aprendizaje, pero vale la pena.

Se menciona que tiene una suscripción msdn. Aunque no es mi sistema favorito de control de versiones, Sourceafe es muy fácil de configurar y usar, y no es una mala solución si es el único que lo usa (lo que parece).

Y sí, quiere usar algo para rastrear errores, incluso si se trata de una simple lista en Excel (o) para que pueda hacer un seguimiento de lo que todavía está roto y lo que está arreglado. Lo he hecho antes en pequeños proyectos en los que he trabajado.

Subversion y Trac no ocupan gran parte de los recursos de su sistema, especialmente cuando están sentados allí esperando que los use.

Estoy trabajando en un proyecto pequeño, solo dos desarrolladores a tiempo completo, pero me parece que uso nuestro software de seguimiento de errores (Jira en nuestro caso, similar a Bugzilla), incluso para hacer un seguimiento de mis propios errores y problemas. Es más fácil que tratar de recordar los detalles de un error cuando tienes tiempo para trabajar en él más adelante, y hay una sensación muy satisfactoria de verificar los problemas después de que los hayas resuelto.

Me quedaría con algo simple en su caso, incluso una simple lista de tareas pendientes en Outlook probablemente sería suficiente si no desea gastar demasiado tiempo de desarrollo configurando un sistema dedicado. Lo importante es tener una forma de saber con certeza que ha resuelto todos los errores que se informaron.

Un VCS es importante ya sea que trabaje solo o no.

En realidad, debería estar ahí para esos momentos en los que te das cuenta de que has cometido un error y quieres retroceder a lo que tenías ayer o esta mañana, o tal vez acabas de tomar una decisión diferente en la implementación y quieres dividirte para que puede probar cosas sin afectar el núcleo de lo que has escrito hasta ahora.

En general, es algo bueno tener. Y es mejor que estés a salvo que lamentarlo.

En cuanto al rastreador de errores, esa es más su preferencia personal. Me gusta Redmine, que se integra con SVN, git, etc. Otros prefieren Trac. Pero de cualquier manera, podrán ejecutarse en su computadora portátil mientras toman una cantidad mínima de recursos. Especialmente cuando consideras que eres el único que los usa.

Revisaría http://bitnami.org/ que ofrecen Bug Trackers empaquetados que acaba de ejecutar y que comenzará su pequeño servidor propio en el puerto de su elección, y puede detenerlo cuando no lo esté usando.

Aunque no es un rastreador de errores explícito, puede usar tiddlywiki, que es una gran wiki en un archivo HTML autónomo, lo que facilita tenerlo bajo control de versiones.

La razón por la que menciono esto es porque tarde o temprano querrás tomar notas además de las listas de errores.

Espero que esto ayude

Si desarrolla en su computadora portátil, es probable que trabaje fuera de línea a menudo (lo hago). Considere usar el rastreador de errores que no requiere conexión a Internet para funcionar. Puede verificar Artifacts : simple, funciona sin conexión y tiene integración con Visual Studio.

Deberías echarle un vistazo a Fossil . Es un sistema moderno de control de versiones distribuidas (código abierto) que se ejecuta en Windows, Linux y Mac. También tiene un Bug Tracker y Wiki integrados. Fue creado por el Dr. D. Richard Hipp, el mismo tipo que creó SQLite . Y, de hecho, utiliza SQLite como el sistema de almacenamiento subyacente para el sistema de control de versiones, el rastreador de errores y Wiki.

Fossil fue diseñado específicamente para satisfacer las necesidades del pequeño equipo de desarrollo o desarrollador individual, y hace un excelente trabajo. Sin embargo, dependiendo de los detalles, también puede funcionar bastante bien para un equipo de desarrollo más grande (por ejemplo, se está utilizando para el desarrollo de SQLite).

(Sé que esta es una vieja pregunta, pero me encontré con Fossil hace unos seis meses, y me he convertido en un gran admirador de ella (viniendo de CVS -> SVN -> Hg -> Bzr -> Git en los últimos 15 años) para mi propio trabajo, y para el equipo en el trabajo.)

Es posible que desee considerar un repositorio en línea y / o un rastreador / planificador además de uno local. Es otra etapa de la administración de riesgos y si, en el futuro, alguien más se une a su equipo, puede escalar simplemente concediéndoles acceso.

Algunas opciones:

Control de fuente (en línea):

Assembla - La fuente pública es gratuita, los repositorios privados se pagan
Source Forge - Solo fuente abierta
Código de Google : solo de código abierto
Git Hub - La fuente pública es gratuita, los repositorios privados se pagan
Bit Bucket : repositorios privados ilimitados con hasta 5 colaboradores, u 8 si invitas a amigos

Seguimiento de errores / Gestión de proyectos

LightHouse : proyectos privados de código abierto y pagos ilimitados
FogBugz - La versión completa es gratuita para hasta dos desarrolladores
BaseCamp : solo pago
Trac - No alojado (aunque Assembla lo aloja), código abierto - Python
Bugzilla - No alojado, código abierto - Perl
Mantis - No alojado, código abierto - PHP