Gestión de lanzamiento de Mercurial. Rechazar los cambios que no pasan las pruebas

7

Investigación de gestión de control de fuente distribuida (específicamente mercurial). Mi pregunta es más o menos ¿cuál es la mejor práctica para rechazar conjuntos completos de código que no pasan las pruebas?

Ejemplo :

Un equipo está trabajando en un programa de hello world. Tienen probadores y un lanzamiento programado con características específicas planeadas.

Upcoming Release:
   Add feature A
   Add feature B
   Add feature C

Entonces, los desarrolladores hacen sus clones para sus características, hacen el trabajo y los combinan en un repositorio de control de calidad para que los evaluadores lo examinen.

Digamos que los evaluadores informan que "la función B está incompleta y, de hecho, es peligrosa", y les gustaría volver a probar A y C.

Ejemplo de finalización.

¿Cuál es la mejor manera de hacer todo esto para que la función B se pueda eliminar fácilmente y termine con un nuevo repositorio que contenga solo las funciones A y C combinadas?

¿Recrear el repositorio de prueba? Retroceder B? ¿Otra magia?

    
pregunta CrazyPenguin 12.06.2012 - 17:46

3 respuestas

6

La clave aquí es crear un flujo de trabajo que evite la situación en la que el código "malo" se expone a desarrolladores o equipos distintos de los que lo crearon. Si esto ocurriera, el código bueno se mezclaría con el código malo y sería difícil "no fusionar" o desenredarlo. Por lo tanto, evita que esto suceda en primer lugar.

Supongo que HelloWorld en este ejemplo es el repositorio de la línea principal, que contiene un buen código conocido. Los desarrolladores A, B y C clonan todo desde este repositorio y desarrollan sus cambios en su contra. En el modelo que estoy describiendo, HelloWorld-test es un repositorio transitorio que QA solo utiliza para probar cambios combinados antes de moverlos a la línea principal. Los desarrolladores nunca miran a HelloWorld-test. Así es como funciona.

  • A, B y C, todos clonan un buen código de la línea principal (HelloWorld).

  • A hace cambios y le dice a QA que está lista (o A empuja sus cambios a un repositorio en escena). QA clona la línea principal y extrae y combina los cambios de A, y luego construye y prueba. Suponiendo que todo esto sea exitoso, el control de calidad luego fusiona estos cambios en la línea principal.

  • B ahora hace que sus cambios estén disponibles. QA clona la línea principal y luego arrastra y combina los cambios de B en HelloWorld-test. Continuando con su ejemplo, digamos que estos cambios son malos. Entonces, la combinación de control de calidad falla, o la compilación falla, o las pruebas fallan, o algo así. En este punto, QA declara que los cambios son incorrectos, notifica a B y simplemente tira la prueba HelloWorld. Ahora es responsabilidad de B extraer y fusionarse desde la línea principal, corregir fallas en las pruebas o lo que sea.

  • Luego, el control de calidad puede realizar el proceso con C, comenzando desde un clon nuevo de la línea principal y fusionando los cambios de C. Tenga en cuenta que los cambios incorrectos de B nunca han llegado a la línea principal, por lo que los cambios de C (o los de cualquier otra persona) nunca se mezclarán con ellos.

  • En algún punto, B ha arreglado sus cambios y le pide a QA que haga otro pull / merge / build / test. El control de calidad puede hacer esto a continuación, o simplemente pueden ir alrededor del ciclo de diferentes desarrolladores o equipos hasta que vuelvan a B.

Esto a menudo se denomina "modelo de extracción" del desarrollo. Creo que los cambios en el kernel de Linux se manejan de esta manera.

En muchos casos, no es "QA" quien realiza el ciclo de extracción / fusión / construcción / prueba, sino que lo hace un sistema de integración continua como Hudson o Jenkins.

Por supuesto, hay muchas variaciones de esto, ya sea que los desarrolladores individuales o los equipos tengan repositorios de prueba, si los cambios se propagan a través de empujar o tirar, etc. Pero todos deberían compartir estas características clave:

  1. Solo los cambios buenos conocidos llegan a la línea principal.

  2. Los desarrolladores solo extraen / clonan de la línea principal, por lo que nunca basan su trabajo en cambios negativos.

  3. Los nuevos cambios se fusionan, se crean y se prueban de forma aislada de todo lo demás y se verifican bien antes de fusionarse en la línea principal.

respondido por el Stuart Marks 13.07.2012 - 18:42
1

Puedes usar colas de parche para las cosas que se van a elegir, o puedes usar hg backout para eliminar los cambios de solo un conjunto de cambios (consulte el libro hg y busque "hg backout" aquí ).

La diferencia es que las colas de parches permitirán que B nunca aparezca en el historial.

OTOH, podría estar mejor alentando "ramas de características" para las características y correcciones de errores, luego seleccione qué ramas se integrarán en la línea de base.

    
respondido por el dukeofgaming 13.06.2012 - 16:44
0

Su mejor apuesta es hacer que el código sea probado antes de comprometerse. Retroceder a B es su mejor apuesta, si no puede hacer eso.

El hecho de retirar el conjunto de cambios es el proceso de aplicar el parche inverso de ese conjunto de cambios. Por extensión, puede retroceder un rango de conjuntos de cambios aplicando el inverso del parche de todos los conjuntos de cambios. Esta debería ser la metodología predeterminada para "revertir" un cambio o un conjunto de cambios, ya que mantendrá la consistencia y la integridad del repositorio.

hg pull
hg up # Now your working directory and local repo are up to date
hg up -r revLast # Update to the latest revision you want to backout
hg revert -a -r revFirst-1 # Creates an inverse patch of revFirst to revLast
hg ci -m "Backed out revFirst - revLast" # Commit inverse patch
hg merge # Merge inverse patch to tip in my working directory
hg ci -m "Merged change back into the tip" # Commit inverse patch to tip in local repo
hg push # Push to master
    
respondido por el dietbuddha 12.06.2012 - 20:38

Lea otras preguntas en las etiquetas