Detener a los desarrolladores comprometerse con la rama incorrecta en DVCS

12

El problema

Estoy en un proyecto de software que tiene aproximadamente 10 desarrolladores, compartimos el código fuente a través de Mercurial. Tenemos una rama de desarrollo y producción por lanzamiento. Repetidamente durante el transcurso del proyecto, hemos tenido el código fuente de una sucursal, es decir, v1 se está incorporando a las sucursales de parches y mantenimiento para versiones anteriores de software, es decir, v2.

Esto se traduce en un tiempo invertido en retirar el compromiso incorrecto o en un código incorrecto (posiblemente no QAd) que llega y se implementa en la rama incorrecta si no nos damos cuenta de que el código ha entrado en la rama incorrecta.

Diseño / método de nuestra rama y combinación

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

Por lo tanto, trabajaremos en una rama de desarrollo de versiones, hasta que se considere listo , se ramifique para una única rama de prueba / UAT / Producción, donde se realizan todas las versiones y el mantenimiento. Las etiquetas se utilizan para crear versiones de esta rama. Mientras se está probando v1, se habrá creado una rama para v2 y los desarrolladores comenzarán a trabajar en nuevas características.

Lo que suele suceder es que un desarrollador realiza un trabajo debido a la rama v2-dev en v1-dev o v1-prod, o peor aún, fusionan v2-dev en v1-prod (o errores similares similares).

Le decimos a la mayoría de los desarrolladores que no accedan a las ramas -prod , sin embargo, el código aún se cuela. Un grupo de desarrolladores más avanzados se encarga de la rama -prod.

Se debe tener en cuenta que, si bien v2 acaba de comenzar el desarrollo, es posible que haya algunos parches bastante considerables en v1 para solucionar problemas. Es decir. Es posible que v1 no solo esté recibiendo un pequeño parche extraño.

Lo que hemos intentado hasta ahora

  • Tener una rama -prod separada, con gatekeepers. Una rama -prod debería generar advertencias a través de su nombre y la mayoría de los desarrolladores no necesitan estar nunca en esa rama. Esto realmente no ha reducido el problema.
  • Aumentó el conocimiento de este problema entre los desarrolladores, para tratar de hacerlos más vigilantes. Una vez más, esto no ha tenido mucho éxito.

Posibles motivos que veo para los desarrolladores comprometidos con la rama incorrecta

  • Un diseño de rama demasiado complejo
  • Tener desarrollo activo en múltiples ramas en paralelo. (El proyecto muestra síntomas de uso del avalanche-model .)
  • Los desarrolladores no entienden suficientemente bien el DVCS

Preguntas que he leído que eran algo relevantes

He leído esta pregunta al no comprometerme con la rama equivocada y creo que las respuestas con respecto a las señales visuales pueden ser útiles. Sin embargo, no estoy completamente convencido de que los problemas que estamos experimentando no sean síntomas de un problema más fundamental.

Con las pistas visuales, podemos incorporarlas fácilmente en la línea de comandos, sin embargo, casi la mitad del equipo usa eclipse, lo cual no estoy seguro de cómo incorporar señales visuales.

Pregunta

¿Qué métodos, en forma de software, gestión de proyectos o gobierno, podemos utilizar para reducir (idealmente, detener) los compromisos en la rama equivocada ocupando nuestro tiempo o ensuciando nuestro código implementado?

Se agradecerán los comentarios específicos sobre las razones por las que creo que pueden estar contribuyendo como se describe anteriormente, pero esto no debería limitar su respuesta.

    
pregunta imp25 04.09.2013 - 00:19

4 respuestas

22

El problema es que estás cambiando lo que el significado de una rama está a la mitad del proceso.

Inicialmente, la rama v1 dev es para desarrollo. Todas las características nuevas van allí. En algún momento en el futuro, se convierte en una rama de mantenimiento para la rama v1 release . Este es el quid del problema.

No es que los desarrolladores sean descuidados, es que los permisos y roles de la rama son descuidados y están sujetos a cambios.

Lo que debe hacer es establecer el rol de cada rama y mantener ese rol. Si el rol cambia, rama.

Por ejemplo:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

En este modelo, los desarrolladores siempre se comprometen con dev. Si está creando un parche, marque el parche en la rama de esa versión (o mejor aún, bifurque la rama de la versión en busca de un parche y luego vuelva a combinarlo en la rama de la versión).

Un artículo que debe leer (y probablemente es un eufemismo para 'debería') es Estrategias de bifurcación SCM avanzada por Stephen Vance.

  

En este documento, primero defino la ramificación en un sentido general. Luego discuto varias estrategias para la bifurcación, comenzando con lo obvio y avanzando hacia varias que son más apropiadas para grandes esfuerzos de desarrollo. En el camino, discuto los pros y los contras de cada estrategia, usándolos para motivar los cambios que componen las estrategias más complejas ...

En este artículo, identifica cinco roles que pueden tener las ramas. A veces, una rama puede cumplir dos funciones y las funciones no necesariamente necesitan una nueva rama siempre que las políticas de la función no cambien a la mitad de la rama (de vez en cuando verá una mención de "rama en política incompatible"). / p>

Estos roles son:

  1. Línea principal. Aquí es donde se hacen las ramas. La ramificación siempre desde la línea principal hace que las combinaciones sean más fáciles ya que las dos ramas tendrán un ancestro común que no se ramifica rama a rama.
  2. Desarrollo. Aquí es donde los desarrolladores verifican el código. Uno puede tener múltiples ramas de desarrollo para aislar los cambios de alto riesgo de los que son rutinarios y mundanos.
  3. Mantenimiento. Corrección de errores en un entorno de producción existente.
  4. Acumulación. Al fusionar dos sucursales, es posible que uno no quiera correr el riesgo de desestabilizar la línea principal. Así que ramifique la línea principal, fusione las ramas en el acumulador y vuelva a unirse a la línea principal una vez que las cosas estén resueltas.
  5. Embalaje. Empaquetado ocurre una liberación en las ramas del embalaje. Esto a menudo se convierte en el lanzamiento y sirve para aislar el esfuerzo de lanzamiento del desarrollo. Consulte Cómo lidiar con lo no deseado se compromete a romper las compilaciones de lanzamiento de larga ejecución? para un ejemplo de dónde el empaquetado entra en conflicto con el desarrollo.

En tu ejemplo, tienes una línea principal en cascada (esto es un problema, hace que las combinaciones sean más difíciles. ¿Qué sucede si quieres combinar una solución para v1 en v2 y v3?) rama de mantenimiento (cambio de política, esto es un problema).

Está bien, dices, eso es genial, pero esto fue escrito para un ejercicio que es un VCS centralizado: estoy usando DVCS.

Veamos el git-flow model y veamos cómo se aplica.

La rama maestra (azul) es la rama de lanzamiento - para etiquetar. No es la línea principal. La línea principal es en realidad la rama desarrollada (amarilla). Las ramas de liberación (verde) son el papel del embalaje. El desarrollo de bajo riesgo ocurre en la línea principal, el desarrollo de alto riesgo ocurre en las ramas características (rosa). En este modelo, la acumulación se realiza en la rama desarrollada. El mantenimiento se considera 'hot fixes' que son rojos.

Si bien las políticas de rol no coinciden exactamente (cada producto tiene su propio ciclo de vida ligeramente diferente), son una coincidencia.

Hacer esto debería simplificar su política de bifurcación y facilitarla a todos los involucrados.

    
respondido por el user40980 04.09.2013 - 04:07
3

Si bien ha intentado usar una rama -prod separada con gatekeepers, parece que el repositorio se utiliza para realizar las compilaciones de producción. Si las compilaciones de producción solo se hicieran desde un repositorio de producción, el grabador solo puede ser ejecutado por su controlador de acceso, por lo que los desarrolladores no podrían empujar hacia él. Esto pone una carga en el controlador de acceso, que solo presionaría al repo de producción después de la revisión. Por supuesto, la gente aún podría extraer del repo de producción cuando sea necesario.

A medida que las personas adquieren experiencia, deben rotarse a través del rol de guardián, para obtener una comprensión o un cuidado más profundos de los que parecen carecer.

Y, como regla general, aplique Occam's Razor: la estructura de repositorio completa debe ser lo más sencilla posible para hacer su trabajo.

Véase también el comentario de Sean.

    
respondido por el andy256 04.09.2013 - 01:25
2

Es posible que los desarrolladores simplemente no obtengan DVCS lo suficientemente bien, pero creo que es mucho más probable que simplemente tengas demasiados problemas y que los desarrolladores no puedan hacer un seguimiento de lo que están haciendo desde el momento a momento Olvidan en qué rama se supone que deben trabajar y sus cambios terminan en el lugar equivocado.

Le sugiero que tenga un problema con el hecho de que todos trabajan en todas estas sucursales de manera regular.

La sugerencia de

@ andy256 de un repositorio separado para prod sería ciertamente útil, pero es posible que deba considerar la parcelación del trabajo de manera diferente, o tal vez arreglar las cosas para que ningún desarrollador esté trabajando en más de una rama en una semana determinada. p>     

respondido por el Michael Kohne 04.09.2013 - 01:36
1

Parece que has identificado uno de mis principales osos de error. La mayoría de las herramientas de control de fuente son exactamente eso, herramientas de control de fuente. Permiten que varios desarrolladores trabajen en el mismo directorio de origen, realizando cambios y manejando conflictos. Ha habido algunos bordes ásperos en el camino, pero cvs, subversion, git, mercural etc. entregan todo esto.

Luego tienes el siguiente paso, cuando necesitas estabilizar el código para el lanzamiento, e introduces la ramificación. Aquí es donde las herramientas comienzan a fallar a los desarrolladores. Las herramientas son capaces de hacer la rama, e incluso identificar los conjuntos de cambios que se han acumulado en las ramas después de que se hayan ramificado, pero ese no es el problema al que se ha enfrentado ahora.

Las herramientas son realmente deficientes para seleccionar qué cambios deben copiarse en otras ramas y cuándo debe ocurrir. Git-flow intenta resolver esto creando una estrategia de bifurcación que significa que cuando las bifurcaciones se fusionan, TODOS los cambios se fusionan, y luego requiere que el programador tome decisiones razonables sobre cuándo y qué ramos se fusionan.

En un único repositorio donde todos los desarrolladores están trabajando en un proyecto que tiene un solo hilo de lanzamiento, git flow resuelve el problema, pero la vida no es tan simple para muchas empresas.

El entorno complejo es donde tiene varios equipos responsables de los diferentes aspectos de la solución total, realizando lanzamientos internos a otros equipos. git-flow simplemente no es capaz de resolver este tipo de problema.

La única forma en que he visto este trabajo, es si cada equipo es responsable de definir sus lanzamientos y controlar cuándo cambian sus dependencias. Solo porque el equipo A ha lanzado la versión 1.3, el equipo B solo comienza a usar la versión 1.3 del equipo A cuando el equipo B elige.

En efecto, un equipo de desarrolladores define los grupos de cambios que deben moverse, y los desarrolladores que reciben los cambios definen cuándo reciben el grupo de cambios.

La única herramienta de control de fuente que he visto que realmente ofrece esto es rigurosa, e incluso entonces, la mayoría de los desarrolladores se quejarán de ello porque la GUI es demasiado confusa para ellos, y no se comporta como una subversión ...

    
respondido por el Michael Shaw 04.09.2013 - 15:46

Lea otras preguntas en las etiquetas