Git Workflow con Capistrano

Estoy tratando de entender un buen flujo de trabajo de git usando capistrano. He encontrado algunos buenos artículos , pero o bien no entiendo completamente lo que sugieren (probable) o están algo faltos.

Esto es lo que tenía en mente hasta ahora, pero me veo atrapado cuando me vuelvo a fusionar con la twig principal (es decir, antes de pasar al escenario? Después?) Y trato de engancharlo en capistrano para las implementaciones:

  1. Asegúrese de estar actualizado con todos los cambios realizados en la twig principal remota por otros desarrolladores
    • git checkout master
    • git pull
  2. Crea una nueva twig que pertenezca al error en particular que estás tratando de corregir
    • git checkout -b bug-fix-branch
  3. Haz tus cambios
    • git status
    • git add .
    • git commit -m "Friendly message about the commit"

Por lo tanto, esto es generalmente donde me quedo atascado. En este punto, tengo una twig principal que es saludable y una nueva twig de corrección de errores que contiene mis cambios (no probados, aparte de las testings unitarias).

Si deseo llevar mis cambios al escenario (a través de la cap staging deploy ), ¿debo fusionar mis cambios nuevamente en la twig principal (preferiría no hacerlo ya que parece que el maestro debería mantenerse libre de código no probado)? ¿Incluso puedo implementar desde el maestro (o debería labelr primero una versión y luego modificar mi file production.rb para implementar desde esa label)? 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 de hacerlo, pero o no puedo encontrarlo o soy demasiado nuevo para reconocer que lo he encontrado.

¡Ayuda!

Solutions Collecting From Web of "Git Workflow con Capistrano"

La forma en que lo hago es tener una twig de 'etapas' que se rastrea en tu repository bendito. Querrá utilizar la gem 'capistrano-ext' que proporciona algunas opciones de configuration adicionales para las etapas (creo que ya está utilizando esto teniendo en count su llamada para implementar en la etapa). capistrano-ext define etapas, lo que le permite tener un file de deployment para cada etapa, por ejemplo, 'puesta en escena' donde define el set :branch, "staging" único para cada etapa en la que se está implementando. Puede hacer su flujo de trabajo arriba y agregar:

 #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 tienes una twig de producción, por lo tanto, las twigs de git son acordadas por el equipo como

  • código de borde maestro donde el equipo comparte entre desarrolladores
  • puesta en escena: código que debe probar el cliente en un server de transición (avance rápido en la combinación maestra)
  • producción – lanzamiento estable (avance rápido de la puesta en escena)

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

Tienes varias forms 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 twig temática basada en HEAD de la twig 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 object que representa el cambio del error de progtwigción que arreglaste, por lo que no hay problema (Y dado que hay buenas testings para el error que usted sabe que funciona, después de ejecutar el package en cada twig). 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 get flujos de trabajo más avanzados como ese.