Hoy, uno de mis colegas y yo tenemos un debate sobre "¿Deberíamos poner los documentos de especificación en un sistema de control de fuente como SVN?". En mi opinión, debería ser. Todo lo relacionado con el desarrollo del proyecto debe controlarse cuidadosamente con el sistema de control de fuente. ¿Es un concepto incorrecto en el proceso de desarrollo de software?
Respuestas:
Entonces, ¿qué pasa si la mayoría de los sistemas de control de código fuente solo los almacenan como blobs? La mayoría de las personas no le importan las diferencias entre documentos, pero si lo hace, siempre puede obtener dos versiones y usar la función del sistema de autoría para diferenciarlas.
Con espacio en el disco duro en centavos por gigabyte por mes, no hay una buena razón para no colocar documentos en el sistema de control de fuente, y es probable que sea útil. Mi preferencia personal es escribir documentos usando marcado en línea, por ejemplo, Wiki Markup o DocBook . Esto permite el uso de potentes herramientas para la comparación y revisión de documentos.
Definir versiones de documentos de especificación es definitivamente un objetivo digno
Sin embargo, ¿sus documentos de especificación son solo de texto y están en un archivo de texto plano ? Si es así, esta puede ser una buena solución.
Si no, el control de origen probablemente no sea el lugar adecuado para ellos: el control de origen es malo para los archivos binarios .
Por lo general, los archivos de texto sin formato no son tan buenos para formatear o ver rápidamente, por lo que una wiki con versiones es probablemente una mejor idea.
Todos los documentos deben estar en alguna forma de archivo (preferiblemente con controles de revisión).
Los sistemas de control de fuente son una solución. Pero, por lo general, estos sistemas están diseñados para documentos de texto sin formato. Por lo tanto, cosas como documentos de Word o RTF, etc. no encajan tan bien (especialmente cuando intenta comparar versiones diferentes).
Pero hay otras soluciones diseñadas específicamente para documentos. Se me viene a la mente SharePoint, pero estoy seguro de que hay otros.
Seguro. El problema de que los documentos se almacenan como archivos binarios (por ejemplo, documentos de Word) es molesto. Una buena solución es que si usa una de las herramientas Tortoise (he probado SVN y Mercurial) puede elegir "Visual Diff" que le permite elegir docdiff. Con docdiff puedes ver todos los cambios con colores y otras cosas :-). La principal desventaja es que cada vez que realiza un cambio, el documento completo se confirma nuevamente (no solo el cambio). Pero teniendo en cuenta que los documentos de texto no son enormes normalmente y que el espacio probablemente no sea su problema principal, esto no es un problema.
Estoy seguro de que puedes usar docdiff sin Tortoise, es solo que no lo he probado.
Hay un enfoque alternativo que debe discutir: BDD
Tenga en cuenta el desarrollo impulsado por el comportamiento con especificaciones ejecutables. Sus especificaciones se simplifican en una serie de conjuntos de instrucciones Given - When - Then que se almacenan en archivos de texto. Una herramienta BDD como Cucumber o SpecFlow convierte esos archivos de texto en pruebas ejecutables, que su herramienta de compilación puede ejecutar.
Pepino: http://cukes.info/ - BDD para Ruby
SpecFlow: http://www.specflow.org/ - BDD para .Net
Para obtener una demostración rápida del flujo de trabajo con una herramienta como SpecFlow, consulte el tutorial de Rob Conery SpecFlow: http://tekpub.com/view/concepts/5
Ahora, no solo está versionando su código, sino también sus especificaciones y su herramienta de Integración Continua (piense en TeamCity, CruiseControl, Hudson, etc.) está haciendo cumplir que todas las especificaciones sigan siendo válidas en CADA compilación ... ¿Es valioso para usted?