Personalmente me gusta Fisheye, pero tiene un entorno de desarrollo de tamaño mediano y una estrategia de desarrollo/ramificación semicompleja donde el monitoreo del estado actual del repos era bastante importante.
En mi último trabajo, nuestro producto principal era una línea de productos SaaS de Java, en caja blanca del lado del servidor, donde toda la integración de facturación y sistema se manejaba internamente. Aunque la mayoría de las personas eran hackers de Emacs/línea de comandos, todavía utilizamos Fisheye en la parte superior de todas nuestras principales líneas de productos.
Advertencias
- Esto fue con SVN, no git/hg, a fin de tomar esto con un grano de sal.
- Había otros ganchos SVN que se construyeron en Bugzilla que implica que no estoy 100% seguro de cómo funcionaban
ingenieros que trabajan en reorganizó productos que no tenían Ojo eran típicamente descontento por las siguientes razones:
Refactorizando archivos Normalmente, usted está en movimiento alrededor, cambiar el nombre, la fusión de los cambios relacionados y similares. La búsqueda de Fisheye por nombre base devolverá los archivos que se han eliminado hace mucho tiempo y se mantendrá su historial, por lo que incluso si desordena el historial en el repositorio, tendrá una idea de cuáles fueron los cambios anteriores. Para una base de código que estaba experimentando algunos dolores de crecimiento muy reales de una repentina expansión de la empresa, esto fue una gran ayuda
Código Propiedad/Revisión Incluso sin un sólido proceso de código de la propiedad/revisión, se puede optar -en cambios de proyecto/repos en particular con Fisheye. Para los líderes del equipo y similares, es una forma muy sencilla de estar al tanto de lo que otras personas están haciendo cuando cambian cosas y por qué, si desea recibir correo no deseado o configurar un feed RSS para el repositorio. Si administras varios proyectos a la vez, podría ser un gran problema. Tenía un preparado para mi primer gran proyecto para que pudiera ver cómo fue cambiando RSS, pero el beneficio real es supervisar los proyectos relacionados con API-a medida que cambian
utilizable No todos nuestros ingenieros son comandos piratas informáticos en línea. Esto es particularmente cierto para algunos de los ingenieros frontend que manejaron HTML/CSS. Tanto como algunas personas tienden a recurrir a las herramientas de línea de comandos cuando es posible, realizando los diffs de archivos comunes y "¿Quién revertió mi cambio y cuándo?" es más fácil manejar las herramientas de diferencia en el navegador que hacer 'svn culpa' y cosas por el estilo.
Dicho todo esto, he de decir que si estuviera haciendo una tienda dev desde el principio, yo no lo tocaría en absoluto a menos que necesitaba la visualización del proyecto completo en lugar de un archivo específico o dos de vez en cuando, lo que probablemente significa las siguientes cosas son ciertas:
- El tamaño de mi exitoso grupo más o menos alrededor 10+ ingenieros de fondos potencialmente no técnicos y está en necesidad o reorganización de una estrategia ad hoc
- La ramificación/etiquetado sirve a un número de necesidades particulares tanto como a las versiones generales
- Codifique la propiedad y la revisión obteniendo tracción como una idea impuesta a un mínimo en lugar de una posición dura en contra de ella debido a limitaciones de recursos
- La comunicación entre los ingenieros es un problema creciente (ya sea ruido o falta de él)) Esto incluye conversación informal a documentación directa
Ignorando cualquier análisis/integración de herramientas también. En parte porque supongo que si estás comparando Fisheye con cualquier otra cosa, también deberías estar mirando cuánto trabajo adicional sería mantener Fisheye frente a otra solución vs. wing it, pero también porque nunca he trabajado con más de un producto Atlassian a la vez.
En su situación, también vería las piezas de integración Jira/Fisheye y vería si ese conjunto de características necesita en este momento (o en absoluto) al buscar otras opciones comerciales.
¿Le gustaría compartir alguna experiencia con Crucible? –
@ ThorbjørnRavnAndersen: Estoy usando una configuración similar en el trabajo. Para nosotros, los empujones se rechazan sin una etiqueta de ticket de Jira en cada confirmación, y se envía un correo electrónico al equipo por confirmaciones de 1 hora sin revisiones del código. Como mínimo, el propietario del proyecto y el confirmador están revisando el código. Crucible tiene algunas características agradables: comentarios enhebrados, comentarios que pueden hacer referencia a líneas específicas de código mediante el clic, líneas de código a las que se hace referencia que resaltan al pasar el mouse por encima de un comentario, notificaciones por correo electrónico,% de archivos visualizados por los revisores. Sin embargo, no puedo comentar sobre el rendimiento o el mantenimiento. Nuestro equipo es pequeño (7 max). – ccoakley
@ccoakley escenario interesante: ¿funciona bien para usted? –