Git Workflow Con Capistrano

Question

Estoy tratando de entender un buen flujo de trabajo de git usando capistrano. He encontrado un fewgoodarticles, pero o bien no entiendo completamente lo que sugieren (probable) o les falta algo.

Aquí es algo de lo que tenía en mente hasta el momento, pero quedan atrapados cuando para fusionar de nuevo en la rama principal y tratando de conectar en Capistrano para implementaciones (es decir, antes de pasar a la etapa siguiente??):

1. asegurarse de que está al corriente de todos los cambios realizados en la rama master a distancia por otros desarrolladores
   • git checkout master
   • git pull
2. Crear una nueva rama que se refiere al error en particular que estamos tratando de corregir
   • git checkout -b bug-fix-branch
3. Realice los cambios
   • git status
   • git add .
   • git commit -m "Friendly message about the commit"

Por lo tanto, esto es generalmente donde me atasco. En este punto, tengo una rama master que está sana y una nueva bug-fix-branch que contiene mis cambios (no probados - que no sean pruebas unitarias).

Si deseo pasar mis cambios al escenario (a través del cap staging deploy), tengo que fusionar mis cambios nuevamente en la rama principal (preferiría no hacerlo ya que parece que el maestro debe mantenerse libre de código no probado) ? ¿Incluso puedo implementar desde el maestro (o debería etiquetar primero una versión y luego modificar mi archivo production.rb para implementar desde esa etiqueta)? git-deployment parece abordar algunos de estos problemas de flujo de trabajo, pero parece que no puedo averiguar cómo diablos realmente se engancha en implementación de puesta a punto de tapa e implementación de producción de tapa.

¿Pensamientos? Supongo que hay una forma canónica probable para hacer esto, pero o bien no puedo encontrarlo o soy demasiado nuevo para reconocer que I tengo lo encontré.

¡Ayuda!

Answer 1

La forma en que lo hago es tener una rama de 'etapas' que se rastrea en su repositorio bendito. Querrá utilizar la gema 'capistrano-ext', que ofrece algunas opciones de configuración adicionales para las etapas (creo que ya está utilizando esto teniendo en cuenta su llamada para implementar en la puesta en escena). capistrano-ext define etapas, lo que le permite tener un archivo de implementación para cada etapa, por ejemplo, 'etapas', donde usted define la rama set :branch, "staging" única para cada etapa en la que está implementando.Usted puede hacer su flujo de trabajo anterior y añadir:

#after commiting on bug-fix branch 
git checkout staging # => tracks staging on origin 
git merge bug-fix-branch # => bring new code in 
git push origin staging # => capsitrano acts locally, it needs the code to get from origin 
cap staging deploy # => wasnt that easy? 

en un mundo ideal, también tiene una rama de producción, por lo tanto las ramas git quedar acordados por el equipo como

• amo - código de borde donde el equipo acciones entre desarrolladores
• puesta en escena - de código para ser probados por el cliente en un servidor de ensayo (avanza rápidamente en combinación maestra)
• producción - versión estable (avance rápido de la puesta en escena)

EDIT: la respuesta al comentario fue demasiado larga, así que tuve que adjuntar a la respuesta.

Tienes varias formas de lidiar con esto, puedo pensar en una de inmediato. Una solución para prod debe reflejarse en todas las sucursales lo antes posible para que sus desarrolladores trabajen en la misma base. Suponiendo que prod tiene un ancestro común directo a la estadificación y estadificación para dominar, se debe agregar una corrección en prod a una rama temática basada en HEAD de la rama prod, luego fusionar ese cambio con master y luego en staging y finalmente desplegar en producción. La idea es que la única diferencia son los compromisos para la corrección de errores, la próxima vez que aceleres la producción a la cabeza en la puesta en escena, ya tendrías el objeto que representa el cambio del error de programación que arreglaste, por lo que no hay problema (Y dado que hay buenas pruebas para el error que usted sabe que funciona, después de ejecutar el paquete en cada rama). De lo contrario, es probable que tengas que seleccionar una confirmación de maestro y aplicar para prod y puesta en escena. Eche un vistazo a progit.org para obtener flujos de trabajo más avanzados como ese.