SVN y flujo de trabajo de implementación

Tratando de mantenerlo simple, pero casi sin experiencia en el control de versiones, esto es lo que se me ocurrió para la versión y el flujo de trabajo de implementación para una aplicación de Facebook que ya está en vivo:

Desarrollo:

  1. twig del tronco

  2. comprobación y configuration del entorno de desarrollo (creación automática de database, proyecto de Netbeans, aplicación de Facebook, file de configuration);

Puesta en escena (lo mismo que la twig de desarrollo):

  1. ejecutar testings (manualmente);

  2. si está bien – svn confirma y fusiona la twig de desarrollo / estadificación con el tronco

  3. Gancho post-commit para implementar el proyecto en el server en vivo y actualizar la database de producción si es necesario.

Sincronice diferentes twigs de desarrollo: si una twig de desarrollo se graduó para producción, fusiónela con la otra twig (s) aún en desarrollo.

¿Hay errores a todo volumen con este flujo de trabajo? O cualquier sugerencia sobre cómo mejorarlo.

PD: soy el único desarrollador por ahora.

Imagen para ilustrar lo anterior.

Suena un poco complicado.

¿Por qué necesitas twigs para organizar? Si está utilizando un tipo de flujo de trabajo de twig de desarrollador, tan pronto como vuelva a fusionarse en el enlace troncal, esto puede ser lo que implemente.

Especialmente dado que usted es el único desarrollador por ahora, esto suena como una excesiva ramificación y fusión para Subversion. Intentaría simplificarte la vida y tratar de mantener uno de los patrones de ramificación comunes .

Para un desarrollador no es necesario, simplemente desarrolle en su twig de etapas e incorpórese al tronco cuando esté listo.

Ramas de funciones (su flujo de trabajo propuesto): funcionan bien en grandes bases de código donde los proyectos / lanzamientos deben desarrollarse en paralelo.

Las sucursales de publicación funcionan bien para bases de código pequeñas donde los proyectos / lanzamientos siguen un ciclo de desarrollo iterativo.