¿Dónde poner qué al usar CVS, Wiki, gestión documental?

En nuestra compañía, actualmente estamos usando CVS para documentos de proyectos, informes de estado, etc., carpetas compartidas para documentation de installables / productos, etc. y algunos equipos usan Wiki (¿no sé para qué?). Ahora, estoy confundido en cuanto a dónde poner qué. Sería genial si pudieras describir qué herramientas usas en tu configuration y con qué propósito.

EDITAR: Esto es lo que obtengo de sus respuestas, corrija si me equivoco.

Use el sistema de control de versiones para el código fuente (principalmente), para todo lo demás use Wiki.

¿Dónde saveías los files instalados para herramientas y utilidades, packages de software dependientes, etc.? ¿Tiene un sistema de gestión de documentos / contenido separado o lo conserva en wiki también (ya que los wikis admiten la carga de documentos / imágenes / cualquier tipo de files).

considere eso:

  • CVS (o cualquier sistema de gestión de control de fuente):
    Conjunto coherente de file que necesita para tener un estado estable (label) o varias versiones parralel (twig)

  • Wiki: documentation dinámica (puede ser modificada por muchos autores), generalmente viene con su propio sistema de historización

De acuerdo con esos criterios, puede orderar sus diversos files entre esos dos referenceles.

Por ejemplo, si un informe de estado no está vinculado al ciclo de vida del desarrollo de un proyecto (que es administrado por CVS), sino al de la versión en producción , Wiki es más adecuado para mostrarlo, ya que la producción es muy secuencial (al mismo time, solo tiene una ejecución de prod, no es necesaria una twig).

Si sus herramientas y utilidades son parte del mismo process de implementación que las entregas comstackdas desde su código fuente de control, también las pondré en la herramienta SCM, no en la wiki:

  • necesitan una label global para administrar todas sus aplicaciones (fuente + herramientas compartidas / utilidades)
  • pueden existir en varias versiones, administradas en su propia twig.

Sugeriría ponerlos en el mismo SCM que tu código, pero algunos prefieren usar un tercer referencel (! Después de SCM y Wiki), con un repository maven …

Diría que la principal ventaja de almacenar documentation en un sistema de control de fuente en lugar de una wiki sería si tiene múltiples versiones de los mismos documentos, como por ejemplo para las twigs de desarrollo y publicación de un proyecto. Allí podrías usar la fusión y tal.

De lo contrario, recomendaría una wiki, ya que normalmente ya tienen historial / errores para corregir los errores. Piénselo de esta manera: ya es difícil hacer que las personas mantengan los documentos actualizados. Desea que sea lo más fácil posible para las personas alimentar los documentos. Tener documentos incorrectos u obsoletos puede ser más frustrante que no tener ninguno.

No es que sea difícil mantener los documentos en el control de versión adecuado. Es solo que los wikis lo hacen más fácil.

También debe pensar en la audiencia objective cada vez que almacene cosas relacionadas con el proyecto: ¿Quién obtiene qué ?: Gerente de proyecto, Desarrollador, Probador, Usuario final, …

Como mi enfoque es tener ayuda en línea para aplicaciones web en una wiki también, terminas con 2 wikis: una para documentation de desarrollador, y otra para ayuda en línea.

En cuanto a su pregunta editada sobre installables: también deberían estar en el VCS. Los desarrolladores deben tener bibliotecas, etc., de los que dependen sus proyectos en el VCS. Para fines de installation, los ejecutables y las dependencies se guardan en un repository separado.

Extraño el seguimiento de errores aquí: si un proyecto obtiene una especificación de una nueva característica, esta especificación también entra en el seguimiento de errores. Cualquier "problema" de desarrollo (mejoras, correcciones, etc.) se almacenará como errores dependientes. Más tarde queda claro qué pasos se han tomado para implementar la function. Al labelr adecuadamente los errores de características, puede consultar fácilmente qué características ya están implementadas (y marcadas como "cerrado", "verificado", etc.) y cuáles no.

Use el sistema de control de versiones para todo el código fuente y todo lo que necesite controlarse.

  • Toda fuente de todo tipo. Todo lo que se requiere para build la aplicación. Además de todas las testings unitarias. Además de todos los files de configuration necesarios para instalar y administrar. Incluso nuestros files Apache app.conf están aquí.
  • Documentos de requisitos. Utilizamos el marcado RST , por lo que nuestros documentos son text sin formatting. No los guardamos en la wiki porque estos son documentos controlados que establecen el scope de otros trabajos.
  • Instaladores para todos los componentes de código abierto y packages de software dependientes. Estos son grandes y binarys, pero nunca se actualizan. La próxima versión siempre tiene un nombre de file diferente. Como no hay cambios, no hay comparación de cambio ni logging de cambios. (Los instaladores propietarios suelen ser demasiado grandes y complejos, y las restricciones de licencia a veces lo impiden).

Para todo lo demás, su sistema de gestión de documentos / contenidos es el Wiki.

  • Planes del proyecto Atrasos Otra información de gestión. Estos son documentos de trabajo y cambian todo el time.
  • Documentos de layout. Texto más diagtwigs UML. Estos son documentos de trabajo que evolucionan y crecen.
  • Otra architecture y notas de implementación. Estos son documentos de trabajo que se centran en una versión específica.