Mercurial - ¿Puedo hacerlo mejor?

Question

Hemos estado usando Mercurial durante un par de meses y ya ha mejorado nuestro proceso de implementación MUCHO. Esta es la parte buena.

El sistema que tenemos instalado funciona, pero sigue siendo propenso a errores si no tiene cuidado o no se apresura. Esto me deja preguntando si hay maneras que podemos mejorar o ... tal vez estamos completamente fuera de la pista :)

Nuestro medio ambiente consisten en:

• estación de trabajo de desarrollo local (cada desarrollador)
• servidor de desarrollo (que aloja la base de datos & el repositorio central)
• Un servidor de aceptación (¿Dónde se realiza control de calidad)
• Un servidor de ensayo (donde la rama etapa de liberación, entonces ROBOCOPY a los sistemas vivos)

Un poco de historia sobre la razón por la que cambiamos:

Estamos en un ambiente de trabajo que a menudo tenemos nosotros cambiar de una tarea a otra, dejando a muchas tareas pendientes. Muchos quedarían obsoletos y llenarían la rama principal cuando volviéramos a CVS. La implementación fue una pesadilla ya que tuvo que trabajar con líneas que debían activarse y otras que no usaban Beyond Compare.

Mercurial con ramas con nombre y fácil fusión resuelve esto para nosotros. Entonces, al no saber qué esperar, lo configuramos.

Primero limpiamos limpiado nuestra fuente de producción, la poda de archivos muertos, etc.

Nos FTP'd que en la puesta en escena y hace este nuestro nuevo repositorio como "default", esto iba a ser nuestra rama estable listo para ser desplegado en todo momento.

Después, hicimos un hg clone en el servidor de desarrollo y teníamos cada desarrollador hg clone desde la rama predeterminada de desarrollo.

En la aceptación donde hacemos QA hicimos un hg clone de la rama predeterminada del servidor de desarrollo.

En este punto tenemos una copia estable del código en todas partes, ¡todos están ansiosos por comenzar!

máquina local son empujando a dev, aceptación tira de dev y puesta en escena es completamente aislado y puede tirar desde cualquier lugar si se proporciona la ruta de acceso.

Ahora la idea detrás de esto era que la sucursal predeterminada en nuestro sistema siempre sería una copia del código en el servidor activo, siempre que recordamos tirar antes de comenzar una nueva sucursal. Al iniciar una nueva característica, podríamos:

hg pull -b default #synch up 
hg update default 
hg branch {newFeature} #newFeature completely isolated from other changes. 

*work on {newFeature} 

¡Vaya! ¡Un insecto! esto no está relacionado con lo que estoy trabajando actualmente, vamos a llamarlo {bugFix111}. Esto parece requerir una nueva rama independiente de mi función; volver a la configuración predeterminada. Esto aislará NewFeature y bugFix111 entre sí y cada uno puede activarse de forma independiente ya que están basados ​​en los valores predeterminados.

hg update default 
hg pull -u 
hg branch {bugFix111} 

Una vez que el trabajo se haya completado el ejemplo {bugFix111}

hg push -F {bugFix111} #send our fix to the main central repo on dev. 

Ir a la aceptación:

hg pull -b {bugFix111} #pull the fix from the central repo (dev). 
hg merge {bugFix111} #merge the code in the default QA branch. 
hg commit -m "Merging {bugFix111} into default" 

*QA sign off on the fix 

Tenemos que ramifican la aceptación - por defecto se llevará a cabo control de calidad y suelte donde fusionamos las cosas a medida que se cancelan.

hg update release 
hg merge {bugFix111} #fix is now ready to go live 
hg commit -m "Merging {bugFix111} into release" 

En estadificación:

hg pull -b release {PATH TO ACCEPTANCE REPO} 
hg merge release 
hg commit -m "Merging {bugFix111} into staging default" 
hg tag release{date} 
*robocopy to live 
*run task that pull from staging to dev so that they synch up again. 

Esto ha estado trabajando para nosotros y ahorrar un poco de tiempo de implementación, ya que es muy fácil de simplemente ROBOCOPY la rama versión estable.

Problemas

Lo que hemos notado es:

• Es fácil meter la pata hasta una fusión cuando la fusión de la segunda vez en libertad, esto parece contra de la corriente. Podemos romperlo después de que el control de calidad se cierre.

• se pudo obtener el control de calidad para poner a prueba nuestra rama de lanzamiento así, pero parece que la duplicación de recursos, el objetivo es sólo para tener características aislado y ser capaz de enviar uno a la vez.

• Podemos explotar por completo fusionando la liberación de algo incorrecto, p. La versión de fusión de hg cuando está en el valor predeterminado de aceptación la sobrescribe por completo.

• Si olvidamos tirar antes de comenzar una nueva sucursal, estamos trabajando en una base incorrecta.

• Pocas otras rarezas, pero esos son los mayores obstáculos.

que se dan cuenta de que este es un post largo, pero espero que las respuestas de ayuda para otras novatos mercuriales como yo tratando de establecer un flujo de trabajo decente en su empresa.

Answer 1

¿Por qué no aprovechar la puesta en escena de la rama QA? Luego, el trabajo de fusión ya se ha realizado y validado, es decir, si el compromiso tiene alguna fusión manual, también lo importará en etapas. De lo contrario, debe replicar la combinación en la etapa de etapas como lo está haciendo ahora.