Estrategias de administración de código fuente (bifurcación, etiquetado, bifurcación, etc.) para aplicaciones web

Question

Esta publicación aquí ( ¿Cómo administra las revisiones de la base de datos en un proyecto de tamaño mediano con sucursales? ) me pregunto cuál es la mejor manera de trabajar en un proyecto web mediante la creación de sucursales y el despliegue en el desarrollo, la organización y la producción (junto con las copias locales). / p>

No tenemos " lanzamientos " per se: si una característica es lo suficientemente grande como para ser perceptible, la presionamos en vivo (después de las pruebas requeridas / etc.), de lo contrario, agrupamos algunas y, cuando se siente "cómoda", las presionamos en vivo. El objetivo es nunca tener una implementación más de una o dos veces al mes porque un sitio que cambia constantemente tiende a hacer que los usuarios se sientan un poco incómodos.

Aquí es cómo lo hacemos, y se siente algo frágil (actualmente usando svn pero considerando cambiar a git):

1. Dos " ramas " - DEV y STAGE con un lanzamiento dado de STAGE marcado como TRUNK
   • El desarrollador revisa una copia de TRUNK para cada cambio y crea una rama para ella
   • El desarrollador trabaja localmente, verificando el código con frecuencia (como si votara: temprano y con frecuencia)
   • Cuando el Desarrollador se sienta cómodo, no está totalmente dañado, fusione la sucursal con DEV y despliegue en el sitio de desarrollo.
   • Repita 3-4 según sea necesario hasta que el cambio esté " terminado "
   • Combinar rama de cambio con STAGING, implementar en el sitio de la etapa. Hacer la prueba final esperada.
   • Después de un período de tiempo, marque una revisión dada de ETAPA como TRONCO, y empuje el tronco en vivo
   • Merge TRUNK cambia de nuevo a DEV para mantenerlo sincronizado

Ahora, algunos de estos pasos tienen una complejidad significativa y son difíciles de hacer (TRUNK - > DEV siempre se rompe), así que tengo que imaginar que hay una mejor manera.

¿Pensamientos?

Answer 1

La bifurcación es útil si espera que el trabajo NO se complete a tiempo y no tiene un cuerpo de pruebas suficiente para hacer que la integración continúe. Tiendo a ver el desarrollo loco de las sucursales en las tiendas donde las tareas de programación son demasiado grandes para completarlas de manera predecible, por lo que la administración quiere esperar hasta justo antes de un lanzamiento para determinar qué características deben enviarse. Si está haciendo ese tipo de trabajo, entonces podría considerar usar el control de versión distribuido, donde CADA directorio de trabajo es una rama naturalmente y obtiene todo el registro local e historia local que puede comer sin lastimar a nadie. Incluso puede fusionar con otros desarrolladores fuera del tronco.

Mi preferencia es cuando trabajamos en un tronco inestable con sucursales para los candidatos de lanzamiento, que luego se etiquetan para el lanzamiento y que luego se convierten en la corriente de parches de emergencia. En tal sistema, rara vez tiene más de tres sucursales (último lanzamiento, candidato actual del lanzamiento, troncal inestable). Esto funciona si está haciendo TDD y tiene CI en el tronco inestable. Y si necesita que todas las tareas se desglosen para poder entregar el código con la frecuencia que desee (por lo general, una tarea debe durar solo uno o dos días y se puede liberar sin todas las demás tareas que componen su función). Así que los programadores toman el trabajo, comprueban el tronco, hacen el trabajo, se sincronizan y se registran en cualquier momento que pasan todas las pruebas. El tronco inestable siempre está disponible para ramificarse como candidato de lanzamiento (si todas las pruebas pasan) y, por lo tanto, el lanzamiento se convierte en un no evento.

En general, mejores significa: menos sucursales, tareas más cortas, menor tiempo de publicación, más pruebas.

Answer 2

Un pensamiento obvio sería más " rebase " (se fusiona con más frecuencia desde el entorno de entorno principal a entorno de niño) DEV a rama de desarrollador) para minimizar el impacto final de TRUNK- > DEV, que ya no sería necesario.

Es decir, todo lo que se haga en ETAPA, que debe entrar en producción de una sola vez (TRUNK) se debe volver a fusionar lo más pronto posible en DEV y en la rama de desarrolladores privados, de lo contrario, las fusiones posteriores a la adaptación son siempre una molestia. p>

PERO, el flujo de trabajo de combinación anterior es demasiado inconveniente, sugeriría una rama REBASE, basada en el último DEV justo después de una versión (nuevo TRUNK). La rebase TRUNK- > DEV se convertiría en TRUNK- > REBASE, donde se resuelven todos los problemas, luego se fusiona finalmente DEV- > REBASE para verificar que cualquier dev actual sea compatible con el nuevo sistema actualizado. Una finalización trivial final de REBASE a DEV (y a sucursales de desarrollo privadas) completaría el proceso. El objetivo de una rama es aislar un esfuerzo de desarrollo que no se puede realizar junto con otros esfuerzos de desarrollo actuales. Si TRUNK- > DEV es demasiado complicado para ir junto con los DEV actuales, debe estar aislado. De ahí la propuesta de la rama 'REBASE'.

Answer 3

Lea esto: http://oreilly.com/catalog/practicalperforce/chapter/ ch07.pdf

Answer 4

Usamos SVN en la tienda donde trabajo. Mientras hacemos el desarrollo de C ++, la administración de versiones es bastante universal. El siguiente es nuestro enfoque, usted puede decidir qué, si alguno de ellos, es razonable para su enfoque.

Para nosotros, TODO el desarrollo ocurre en una rama. Nos ramificamos para cada error y cada característica. Idealmente, esa rama se dedica SOLAMENTE a 1 función, pero a veces eso simplemente no está destinado a ser.

Cuando el trabajo se completa, se prueba y " está listo " fusionamos los cambios en el tronco. Nuestra regla es que en ningún momento el tronco debe tener un código roto. Si el código roto se encuentra en el tronco, corregirlo se convierte en prioridad 1.

Los lanzamientos se realizan cuando todas las características están completas y combinadas: se crea una rama para el lanzamiento al igual que una etiqueta. La etiqueta nos permite recuperar un shapshot si es necesario. La rama nos permite nuestro soporte de versiones anteriores. La corrección de errores en una versión liberada se realiza yendo a la rama de esa versión, derivando de ella. Cuando todo está bien, los cambios se fusionan de nuevo a la rama del lanzamiento y, si se desea, hasta el tronco.