Proponiendo una estrategia de control de versiones para SVN

9

Fuera del reloj voy a tratar de idear una estrategia para el control de versiones para mi empresa; actualmente usamos SVN pero no hay estructura, básicamente solo tenemos un enlace troncal y solo nos comprometemos a eso. Recientemente, el gerente de desarrollo comenzó un segundo repositorio que actúa como nuestra "etiqueta", pero debe fusionarse manualmente con el "tronco", ya que no es parte del mismo repositorio, sino uno completamente separado. En efecto, solo hay una carpeta, llamada "Dev" (en realidad hay diferentes carpetas "Dev" en diferentes fechas pero solo "Dev" es la principal) y debajo de eso está todo lo demás; Todos los demás proyectos. No está organizado por proyecto en absoluto, no tiene ningún concepto de ramas / etiquetas / troncales ni nada. La persona que lo configuró inicialmente (hace mucho tiempo, por supuesto) parecía no saber cómo configurar SVN en absoluto, y desde entonces nadie se ha molestado en aprender a hacer las cosas correctamente por miedo a romper algo. No usamos ningún tipo de CI (o pruebas automatizadas, desafortunadamente).

Primero, ¿deberíamos separarlo por proyecto? Por ejemplo, tenemos: dos sitios web ASP.NET (no aplicaciones web, sitios web), un servicio web, una carpeta de implementación para todos los scripts de tabla y procedimientos almacenados, dos clientes de línea de comandos para proyectos externos que son llamados por el Sitios web y una carpeta compartida que tiene objetos comerciales comunes y similares. Si cada uno de estos es su propio proyecto con una configuración de ramas / etiquetas / troncales, o debería ser así:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

y tiene todas las ramas y todo tiene una copia de la carpeta Dev completa? Ese enfoque podría ser más fácil de aceptar, ya que a menudo tenemos situaciones en las que necesitamos hacer cambios en la biblioteca de códigos compartidos y al menos uno (generalmente ambos) de los sitios web también.

En segundo lugar, hacemos lanzamientos regulares ("empuje" en nuestro lenguaje) a nuestro servidor de desarrollo y servidor en vivo. Por lo que he leído, la mejor manera de manejar esto sería que todo el desarrollo vaya al tronco /, las ramas son "temporales" y se usan para agregar una nueva característica que podría afectar el tronco, y las etiquetas son para lanzamientos. Entonces, presionamos cada mes, digamos, y estoy trabajando en un nuevo módulo. Yo bifurcaría el tronco y usaría esa rama para mi código, escribirlo y probarlo y lo que sea. Cuando el módulo esté terminado, lo fusionaría nuevamente en el tronco (y tal vez eliminaría la rama), y cuando estemos listos para implementar lo etiquetaríamos ("May2011", digamos). Si tenemos una corrección de errores después de que se active, se corregirá en la etiqueta de mayo de 2011 y se fusionará con el tronco (para que el tronco también obtenga la solución), y luego mayo2011 sería expulsado nuevamente con la solución? ¿Es esta la intención de etiquetar?

version-control svn Wayne Molina
fuente
55
Estrategia fuera de la caja: cambiar a git.
Rein Henrichs
Si esa fuera una opción, lo haría (o Mercurial, ya que somos una tienda de Windows). Creo que me enfrentaría a una resistencia aún mayor al intentar pasar a un sistema de control de fuente totalmente nuevo que al menos tratar de configurar un entorno adecuado con SVN.
Wayne Molina
2
Aunque estoy entusiasmado con DVCS, Subversion es una buena herramienta. CVS u otra solución sin versiones de carpeta sería peor.
Matthew Rodatus
2
@Wayne M: es posible que sea al revés. Puede ser más fácil lograr que las personas se registren en una estructura de entorno más sensible si al hacerlo les brinda todas las ventajas de usar un DVCS. Como transición, es posible que desee considerar obtener gente para probar el acceso local de ramificación / repositorio barato usando gitsvn o hgsubversion. Una vez que están enganchados y acostumbrados a las herramientas, puede haber un deseo de todo el grupo de pasar a un DVCS para los repositorios principales.
Mark Booth

Respuestas:

5

Si desea un proceso de compilación unificado, asegúrese de colocar ramas / etiquetas / troncales en la raíz, de esta manera:

branches/
tags/
trunk/
  dev/
    ...

Si no necesita un proceso de compilación unificado, puede colocar ramas / etiquetas / troncales dentro de cada proyecto si lo desea. Sin embargo, puede ser difícil migrar a una compilación unificada después de haberlos colocado dentro de cada proyecto. Una compilación unificada tiene ventajas, como la eliminación de la necesidad de publicar componentes compartidos entre proyectos: todos son parte de la compilación.

Personalmente, me gusta un proceso de construcción unificado. Además, no creo que deba tener un proyecto "dev". Debería tener proyectos directamente debajo del tronco, y luego bifurcar el tronco en una rama de desarrollo. Use etiquetas para lanzamientos. Por ejemplo, lo haría así:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/
Matthew Rodatus
fuente
1
Una compilación unificada tiene ventajas, como la eliminación de la necesidad de publicar componentes compartidos entre proyectos: todos son parte de la compilación.
Matthew Rodatus
2
Si necesita múltiples compilaciones unificadas, cree directorios bajo el tronco para cada uno. Pero, no nombraría a un "desarrollador", eso se logra mejor con una rama. Por ejemplo, puede tener dos organizaciones de desarrollo principales: una que funciona con controladores de dispositivo y otra que funciona en el sitio web de la empresa. Probablemente desee dos compilaciones unificadas separadas.
Matthew Rodatus
1
  1. En cuanto a la estructura del código dentro de svn, esta es una elección realmente personal.

Sugeriría que si los proyectos están relacionados o comparten código, entonces quieren una troncal común. Si son independientes, entonces quieren troncales separadas o incluso repositorios separados. Si alguna vez necesita proporcionarle a un tercero una copia del historial de svn para un proyecto, entonces es mucho más fácil si está en un repositorio separado.

Entonces, en su caso, parece que el diseño que bosquejó anteriormente sería razonable, ya que ha compartido el código y desea que las ramas / etiquetas incluyan ese código compartido.

  1. Su descripción del uso de etiquetas y ramificaciones suena eminentemente sensible y es como esperaría que se usara svn. De hecho, esa es la intención de etiquetar tal como lo entiendo. Por cierto, las etiquetas y ramas svn son en realidad la misma cosa, pero la terminología se aplica como la ha aplicado.

Personalmente, también agregaría la advertencia de que cualquier cosa comprometida con el tronco debe construirse, debe ser atómica y no debe romper ninguna prueba unitaria. Las ramas son para trabajos inacabados en progreso. Esperaría que la troncal sea un posible candidato de liberación en cualquier momento.

Luke Graham
fuente
¿Estás diciendo que solo el código probado y listo para producción debe estar en el tronco? Creo que cualquier código comprometido debería compilarse y probablemente pasar las pruebas, y el código troncal debería pasar las pruebas. Pero parece que el propósito de SVN es poder seguir el historial de desarrollo, y eso es más fácil si no se divide en varias ramas. ¿Tal vez debería haber una rama en la que fusiona troncal cuando la troncal está en un estado probado y listo para la producción?
Sr. Jefferson
0

La siguiente es la mejor manera de diseñar un repositorio de Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

De esta manera, puede consultar proyectos individuales por sí mismos.

Si desea verificar los 3 proyectos y hacer una compilación unificada con un script / sistema de compilación monolítico, investigue utilizando un módulo maestro con svn: externos mapeando todos los otros proyectos en el maestro trunk .

Esto es más complicado a primera vista, pero es la forma más fácil e idiomática de resolver este problema con Subversion.


fuente
2
Estoy totalmente en desacuerdo. El repositorio hace más que solo almacenar código; comunica la estructura organizacional y la relación entre componentes; Es un canal de comunicación vital, aunque implícito. Si divide cada proyecto por separado, entonces está introduciendo barreras artificiales e innecesarias para la comunicación.
William Payne