Usar ramas de prueba en Git

Tenemos a alguien (llamémoslo Ted) que es responsable de probar nuevas funciones y correcciones de errores.

Estamos usando Git y GitHub . masterdebe / siempre se puede implementar y developmentes donde comprometemos / fusionamos nuevas características o correcciones de errores, pero solo después de que Ted las haya probado.

El proyecto está en PHP.

Me gustaría que el proceso de prueba sea así:

1. Un desarrollador quiere trabajar en una nueva característica (digamos que la característica / error # 123 como Ted documentó en el rastreador de problemas), por lo que recurre origin/developmenta developmentsu repositorio local y crea una nueva rama (digamos issue-123) a partir de ahí.
2. Una vez que está contento con su trabajo, se compromete y empuja a su nueva sucursal origin.
3. Ted se conecta test.ourproject.com/choose-branchy ve una lista de las ramas encendidas originy elige encenderlas issue-123(debería ser posible a través de la página web). Luego continúa test.ourproject.com, pone a prueba la aplicación web (es realmente despiadado) y después de un rato con el desarrollador, está contento con la función.
4. Ted le dice al desarrollador que puede fusionar issue-123en developmentel origin.
5. Enjuague y repita.

Para el tercer paso, podría hackear algo que hace el trabajo (mostrar y cambiar ramas de una página específica), pero siento que lo que he descrito es un patrón muy común.

Entonces mi pregunta es: ¿Es este un flujo de trabajo bueno / sostenible / mantenible para la ramificación? ¿Puede respaldar su respuesta citando algunos ejemplos de otros proyectos que siguen este flujo de trabajo?

El flujo de trabajo de la rama se parece mucho a gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow y hay herramientas de soporte a su alrededor. Es muy recomendable

Si solo hay un probador, su flujo de trabajo de prueba suena bien, pero si hay varias personas, entonces el desarrollo podría moverse entre el inicio y el final, y, por supuesto, las pruebas deberían realizarse completamente después de cualquier fusión. ¡Aquí es donde las pruebas automatizadas realmente pueden ayudar o un probador lento (completo) nunca podría terminar!

Otro problema es que con muchas características y ramas se vuelve tentador mezclar y combinar características en una versión (o elegir desalojar después de la aceptación y fusión) o tal vez si las características dependen unas de otras. El problema es si comienza a moderarlo para reescribir el historial (volver a crear / eliminar una confirmación o fusión) en una rama PUBLICADA, es decir, una que se ha enviado a un repositorio multidev. Esto está reescribiendo la historia pública. Se puede hacer para bien o para mal e incluso si se hace para bien puede causar problemas a los incautos, y la mejor práctica es evitarlo para que la pregunta nunca surja. Sin embargo, algunos flujos de trabajo de la rama de integración hacen que esto sea muy tentador, por lo que si tiene una fuerte protección en dichas ramas (por ejemplo, restricciones de rama de gitolite por usuario) y la gente espera dicha actividad, siempre debe cambiar su código en dicha rama, ¡proceda con precaución!

También me gustaría recomendar leer http://sethrobertson.github.com/GitBestPractices/ que discute todos estos asuntos y tiene muchas buenas referencias.

No estoy seguro de que la página de cambio sea un patrón común. La mayoría de los proyectos probablemente simplemente hagan que el probador lo revise con el comando git.

El enfoque general definitivamente suena razonable.

Google incluso escribió Gerrit para apoyar un estilo similar; se trata más de revisar el código, pero aprobar la integración normalmente implica tanto revisión como prueba. Por lo general, también está interconectado con un servidor de integración continua que construye todas las presentaciones primero (no estoy seguro de si usan Jenkins en Google, pero creo que he visto conectores apropiados en alguna parte).

Git en sí usa una ligera variación sobre el tema. Su responsable de mantenimiento tiene un script que combina todos los envíos pendientes en una rama llamada pu(presumiblemente para "actualizaciones propuestas"; la rama se elimina y se vuelve a crear cada vez ya que los envíos pendientes a menudo se vuelven a redactar). Esto es más que probado por varias personas. Si está bien, entonces los envíos que se consideran completos se fusionan next(es lo mismo que tu development). Si no, entonces alguien prueba las presentaciones individuales para ver cuál está roto. Esto lo hace un poco más fácil para el probador ya que no tienen que cambiar de rama la mayor parte del tiempo; simplemente informan si la integración de prueba funciona.

Si su prueba se realiza automáticamente en lugar de hacerlo manualmente, creo que Travis (un sistema de CI para GitHub) hará más o menos lo que desea: ejecuta automáticamente las pruebas en todas las solicitudes de extracción. ( Más información sobre este proceso, incluidas capturas de pantalla ) .

Tenga en cuenta que las pruebas no se ejecutan en la bifurcación, sino en la bifurcación después de fusionarse con la maestra. (es decir, lo que obtendría después de fusionar la rama en maestro; tiene la garantía de que las pruebas aún se ejecutarán con éxito después de la fusión).

Si se agregan confirmaciones a la rama, las pruebas se vuelven a ejecutar. (Aunque por alguna razón, agregar commits al master no parece volver a ejecutar las pruebas).