meaning - mercurial vs git

¿Cómo utilizar mercurial para la gestión de lanzamientos?

Question

Esta es una pregunta de la prima con mi pregunta anterior de "Cómo gestionar el desarrollo concurrente con mercurial", que cubre el flujo de trabajo del desarrollador individual. La respuesta a esta pregunta influirá en la elección del flujo de trabajo del desarrollador.

Esto NO es una "práctica recomendada de administración de la versión" o una pregunta de IC general, ya que se ha asked many times con buenas respuestas, y hay una gran cantidad de publicaciones disponibles para matar el tiempo.

Solo estoy pidiendo formas específicas de usar mercurial en el contexto de la administración de versiones .

La respuesta más obvia y predominante sería supuestamente estable / predeterminada , que está completamente cubierta por el hermoso blog de @Steve Losh, y más concisa en una respuesta de él. Es simple y eficaz.

Un ejemplo destacado de esta configuración es la propia hg. hg usa algunos repositorios más para el desarrollo activo, pero para fines de administración de versiones, todo parece estar contenido en las ramas estable / por defecto del repositorio principal .

La configuración de hg realmente manifiesta una variación, o más bien una versión extendida, de estable / predeterminado: clon de rama . Describí el proceso en una respuesta a una pregunta en una sucursal con nombre frente a varios repositorios (con otra gran respuesta de @Martin Geisler). Lo que olvidé mencionar en mi respuesta es cómo funciona el clonado de rama para el flujo de trabajo del desarrollador: si necesita corregir un error para un ramal, hg clone <main repo>#<branch> pero no el clon de ramal, porque su conjunto de cambios Aún así, regresa al repositorio principal y empuja hacia fuera para clonar automáticamente. Por supuesto, puede elegir no clonar y simplemente hg update <branch> en su clon principal, pero la mayoría de los argumentos para usar clones separados (especialmente la compilación independiente) se aplican aquí.

Ahora volvamos a la pregunta: ¿hay otras formas que se ajusten a diferentes escenarios del mundo real? Por ejemplo, un ciclo de lanzamiento tradicional mayor / menor / parche con un largo lapso entre lanzamientos probablemente requiera un flujo de trabajo bastante diferente al de una aplicación web de lanzamiento a medida que se acelera. Por favor, también comente sobre los enfoques de estable / predeterminado y clonación de rama si lo desea.

Ya que esto es casi una pregunta de una encuesta, solo puedo tratar de aceptar subjetivamente la "mejor" respuesta. Si puedo obtener algunas respuestas más que mi pregunta de flujo de trabajo del desarrollador, es decir.

¡Gracias por todas sus aportaciones!

Answer 1

Estoy en el proceso de rediseñar nuestro flujo de trabajo para su lanzamiento. Así que he encontrado esta pregunta. He decidido escribir mi experiencia. Por lo que vale ...

Para el desarrollo, estamos utilizando algo que parece ser una variación de lo que usted llama el flujo de trabajo estable / predeterminado (por supuesto, todo pasa a través de comandos que hacen cumplir el flujo de trabajo, los llamo myw después):

• Tenemos un servidor central que contiene todos nuestros repositorios.
• Tenemos un clon central estable por proyecto en este servidor.
• Tenemos un clon de desarrollo central por proyecto, que es un clon de estable en este servidor.
• inicialmente, uno puede myw create theproject que crea los clones / dev estables para el proyecto en el servidor y localmente (en la computadora del desarrollador)
• cuando alguien tiene que desarrollar una nueva característica, puede myw clone theproject dev mygreatfeature que:
  • clona el repositorio del proyecto en el servidor como mygreatfeature
  • clones localmente el repo clonado mygreatfeature
  • hace muchas cosas útiles como actualizar hgserver / hudson ci ...
• él puede myw fetch dev y myw fetch stable cualquier momento
• cuando la función está terminada, la fusiona con su clon de desarrollo local, presiona el resultado combinado en el clon de desarrollo central y cierra el clon central que se archiva por un tiempo: myw close theproject mygreatfeature

Todo eso funciona muy bien y es bastante suave. Hemos preferido los clones a las ramas con nombre, ya que era sencillo cerrar realmente una rama con características, y en ese momento la parte de "rama con nombre" mercurial parecía "trabajo en progreso".

La parte de lanzamiento del flujo de trabajo se realiza básicamente así:

• el "release master" recupera del clon de desarrollo central a su clon de desarrollo local.
• Obtiene del clon central estable a su clon local estable .
• Trae de su clon local estable los cambios que están en su clon de desarrollo local.
• comprueba todo, si está bien, haga myw release 1.2.3_RC2 que:
  • etiqueta con 1.2.3_RC2
  • Empuje hacia el proyecto centralizado estable clon.
  • De hecho, este es un candidato de lanzamiento , que será probado durante un tiempo por nuestro servidor de CI y por nuestros probadores de incondicional.
• Las correcciones de errores descubiertas por esas pruebas se fijan en el clon estable local y se presionan en el clon estable centralizado.
• cuando está bien, el "release master" hace un lanzamiento formal: myw release 1.2.3

Eso funciona bastante bien, incluso si necesitamos mejorar algunos comandos para suavizar el proceso. Uno de los principales inconvenientes es que son muchos clones :)

Para la administración de versiones anteriores, actualmente tenemos un clon de estable hecho para cada versión principal. Como no hay una gran necesidad de backport muchas características, solo tenemos que seleccionar algunos errores realmente malos con el hg transplant (por cierto, una gran extensión).

Lo hemos utilizado durante aproximadamente un año, y ciertamente necesitamos mejorar nuestros comandos caseros, especialmente para la parte de lanzamiento :)

El principal inconveniente es que tienes que darte a ti / a tu equipo algunas herramientas para manejarlo porque sin ellas podría ser inmanejable, por lo tanto, nuestro conjunto de comandos myw casa myw . Como de costumbre, la rama de la característica no debe durar demasiado tiempo, o la fusión puede ser difícil de hacer. Las cosas como la refactorización / cambio de nombre deben hacerse en los puntos elegidos, o darán a su equipo mucho trabajo de fusión.

Como vamos a tener más y más versiones para mantener, estoy tratando de mejorar la parte de ''versión anterior pero que tengo que admitir''. Leyendo el comentario de Bert F , he leído este gran article . ¡Hay buenas ideas y está bien explicado con un esquema realmente bueno! Parece que alguien ha implementado la versión hg de su herramienta git-flow como article . Algo a tener en cuenta. Me gusta el lanzamiento y las revisiones de las sucursales. ¡Y creo que hacer cumplir dicho flujo de trabajo con una herramienta es bastante obligatorio!

my2c