TFS: Combinar las mejores prácticas

Question

TFS: Combinar las mejores prácticas

Tenemos una arquitectura de rama estándar donde tenemos una rama de desarrollo para cada equipo, un rama de integración común (desde donde se ramifican todas las ramas de desarrollo) y rama de producción ramificada desde la integración.

Durante la fase de desarrollo hago muchos commits en la rama de desarrollo. Al final de la fase fusiono mis cambios a la integración y más tarde a la producción.

¿Tiene sentido fusionar cada commit individualmente, copiando el commit original descripci y la vinculación a la tarea original? Otra opción es, por supuesto, fusionar todas las confirmaciones a la vez, con una sola operación de fusión. La razón de mi pregunta es que el primer camino lleva mucho tiempo. No veo ninguna herramienta de automatización en TFS que vincule la fusión con otra rama a la confirmación original.

Me gustaría escuchar su opinión sobre las mejores prácticas.

46

version-control tfs

Author: Community, 2009-12-07

Source

2 answers

Siempre solo he fusionado un rango de confirmaciones en la rama de integración, solo especificando el rango de los conjuntos de cambios que he fusionado.

Los elementos de trabajo relacionados con elementos de trabajo individuales en la etapa de desarrollo son elementos de trabajo de la fase de desarrollo. No creo que haya ninguna necesidad de incorporarlos a la integración o liberación.

No ha especificado dónde está grabando errores / solicitudes de características de los clientes. Si estás asignando estos a la rama release probablemente estés crear otros elementos de trabajo más detallados para la rama de desarrollo y al fusionar, simplemente marcará todos los problemas que se corrijan como resueltos para la rama en la que se está fusionando.

Resumiendo, no veo ninguna razón por la que no ir con fusiones masivas.

5

Author: Gergely Orosz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-12-07 15:41:41

score 74 · Accepted Answer

Las fusiones de Dev* -> Integración e Integración -> Producción siempre deben ser fusiones "copy". Esta es la forma más segura de preservar la estabilidad de sus ramas aguas abajo.
1. Primero combine en la otra dirección (por ejemplo, Integración -> Dev2) para recoger los últimos cambios de la rama de destino.
2. Si hay conflictos, maneje las diferencias caso por caso. AcceptMerge (ya sea automático o manual) es generalmente el resultado deseado, pero a veces querrá tomar uno o la copia de la otra rama sin cambios.
3. Use la rama source (Dev #2 en nuestro caso) para incorporar completamente, reaccionar y estabilizar estos cambios.
4. Fusionar en la dirección deseada (por ejemplo, Dev2 - > Integración). Resolver todos los conflictos como AcceptTheirs [también conocido como "copy from source"].
5. Asegúrese de que no haya cambios en la rama de destino entre los pasos #1-4. Si la rama Dev está aceptando fusiones tempranas y a menudo, como debería ser, entonces no debería ser oneroso bloquear la rama de destino durante este esperanzadamente corto proceso. Si anticipas una fusión "big bang" de muerte por cualquier razón, hay una posibilidad decente de bloquear a otros equipos de hacer lo mismo en paralelo, por lo que es posible que tengas que repetir los pasos #1-4 repetidamente hasta que estés listo.
Haz fusiones "catch up" siempre que sea posible. Es decir, combinar las cosas en el mismo orden en que se registraron. Si los conjuntos de cambios 10, 20 y 30 son candidatos a fusionarse desde A -> B, entonces cualquiera de estos rangos de fusión es un " ponerse al día:" 10~10, 10~20, 10~30. Cualquier rango de conjuntos de cambios que se salte el # 10 se conoce como "cherry pick"."Una vez que empiezas a recoger cerezas, te encuentras con algunos peligros:
1. No puede usar el modelo merge down, copy up descrito anteriormente. Solo por eso, Laura Wingerd diría que estás saltando sobre una acera.
2. Si alguno de los archivos tocados en su rango también se tocaron anteriormente, tendrá que hacer una fusión de contenido de 3 vías para que solo se propaguen los diffs seleccionados. No la herramienta diff es perfecta; está agregando un riesgo distinto de cero de traer más código del previsto, sobrescribiendo accidentalmente los cambios realizados en el objetivo, introduciendo errores de lógica donde las dos ramas divergen, etc.
3. El conjunto de cambios que está promoviendo en la rama supuestamente más estable representa una configuración que nunca se ha construido o probado antes. Puedes hacer una conjetura decente sobre el estado final de la rama objetivo. "Estoy fusionando todos los cambios que afectan al Módulo Foo, y probé la nueva versión de Foo en Dev, así es como Foo se comportará en la integración, ¿verdad?" Asegúrese...posiblemente...si puedes rastrear cada dependencia en tu cabeza (incluyendo todo lo que puede haber cambiado en la Integración mientras estabas probando Dev). Pero estas conjeturas no son de ninguna manera conocidas o validadas por su cadena de herramientas SCM.
4. En TFS específicamente, cherry picking donde los cambios de espacio de nombres están involucrados es solo pedir que se queme. Si su rango de versión y/o ámbito de ruta excluye la fuente de un cambio de nombre, vendrá como una rama en su lugar. Si excluyes el objetivo, colgará una eliminación. Si su ámbito de ruta no incluye la raíz de un undelete, obtendrá errores crípticos. Si su rango abarca un tiempo entre una recuperación y una nueva eliminación, obtendrá archivos "phantom" que aparecerán en el objetivo incluso si no incluye la recuperación en sí. Si fusiona Movimientos con todos los ámbitos de ruta y versión correctos, pero lo hace fuera de orden, es posible terminar con un nombre de destino diferente que el nombre de la fuente incluso después de que se hayan agotado todos los conjuntos de cambios candidatos. Estoy seguro de que hay más maneras para que este combo salga mal que no vienen a la mente en este momento...sólo confía en mí.
Siempre haga un Get en la rama de destino antes de fusionar. Versión avanzada para máxima seguridad: sincroniza el espacio de trabajo en el que te fusionarás con un número de conjunto de cambios específico que esté en o cerca de la punta, luego también [ponerse al día] fusionar con ese mismo conjunto de cambios. Al hacerlo se evitan algunos potenciales cuestión:
1. Fusionando en código obsoleto, produciendo diffs confusos de 3 vías que parecen eliminar cambios de lo que ves en Tip. [eventualmente los recuperaría al Checkin + Resolve, pero no hay razón para pasar por dos diffs riesgosos cuando puede evitar ambos]
2. Tener que pasar por el proceso de resolución de conflictos dos veces: una al Fusionar, otra al Registrar. No hay manera de evitar esto en el caso general, pero la mayoría de las veces el # de cambios simultáneos realizados mientras se Fusiona + Resolver es pequeña en comparación con el número de cambios que encontrarías en un espacio de trabajo que podría estar desfasado días o semanas.
No combines por etiqueta (o espacio de trabajo) a menos que realmente sepas lo que estás haciendo. Revisemos las características ofrecidas por las etiquetas TFS y luego diseccionemos por qué cada una es inapropiada para una fusión segura y consistente.
1. Las etiquetas pueden representar varios puntos en el tiempo. Si una etiqueta representa una instantánea consistente del VCS then y siempre fue pensado como tal then entonces no tiene ventaja técnica sobre una fecha o conjunto de cambios #. Desafortunadamente, es bastante difícil saber si una etiqueta es de hecho consistente a lo largo del tiempo. Si no, la fusión por etiqueta puede conducir a:
  1. Selección inadvertida, si el rango comienza con una etiqueta que apunta a un elemento @ un tiempo por delante de su primer candidato
  2. Exclusión inadvertida, si el rango comienza con una etiqueta que apunta a un elemento @ un tiempo antes del final del rango
  3. Exclusión inadvertida, si el el rango termina con una etiqueta que apunta a un elemento @ un tiempo antes del inicio del rango
2. Label versionspecs representa un conjunto específico de elementos. Se pueden usar para excluir deliberadamente archivos y carpetas que una consulta recursiva pura vería de otra manera. Esta característica, también, es una mala coincidencia para las operaciones de fusión. (Y de nuevo, si no necesita esta habilidad, está incurriendo en el siguiente riesgo sin ganar nada sobre fechas y conjuntos de cambios.)
  1. Elementos no presente en la etiqueta será simplemente ignorado, en lugar de fusionarse como eliminaciones pendientes. A diferencia de algunos de los casos extremos cubiertos hasta ahora, este es un gran problema que es muy probable que suceda en escenarios convencionales, pero la mayoría de la gente no lo hace. [Como resultado, TFS 2010 agrega soporte para elementos eliminados dentro de etiquetas.]
  2. Selección inadvertida de cereza, si agrega un elemento a la etiqueta que ha estado presente durante un tiempo pero que fue excluido de fusiones anteriores debido a uno de los lados mencionados anteriormente effects.
  3. Recolección intencional de cerezas. Toda la ventaja que esta característica trae a Merge es romper una de nuestras pautas, por lo que obviamente esa no es una buena razón en absoluto. Además, causa la selección de cerezas en el nivel file, que es incluso más peligroso que la selección de cerezas "ordinaria" por conjunto de cambios.
3. Las etiquetas tienen nombres, propietarios y comentarios amigables y personalizables. Por lo tanto, tenemos una diferencia de usabilidad pura vs fechas / conjuntos de cambios; ninguna ventaja técnica es conferir. Pero incluso aquí no es tan atractivo como parece. TFS no hace mucho para mostrar las etiquetas en la interfaz de usuario, mientras que puedes ver comentarios de conjuntos de cambios por todas partes. La consulta por el propietario es rápida (del lado del servidor), pero la mayoría de las otras búsquedas son lentas (del lado del cliente) a menos que sepa el nombre exacto de la etiqueta. Las instalaciones de gestión son prácticamente inexistentes. Sin registro de cambios o auditoría, solo una marca de tiempo. En total, estas no son razones para abandonar la garantía proporcionada por conjuntos de cambios.
Siempre fusiona toda la rama a la vez. La fusión de archivos o subárboles es a veces tentadora, pero en última instancia equivale a una simple selección bajo un nuevo disfraz.
Planifique con anticipación. Desafortunadamente, la re-crianza de ramas en TFS es un tema doloroso. A veces es arduo, a veces son solo unos pocos pasos, pero nunca es obvio; no hay un comando incorporado (hasta 2010). Llevarlo a cabo en 2005/2008 requiere un conocimiento bastante profundo de su rama actual estructura, estructura deseada, y cómo abusar de los efectos secundarios de varios comandos TF.
No cree ramas dentro de ramas. Por ejemplo, la bifurcación y la fusión a veces se recomienda como una forma de mantener módulos comunes o binarios entre proyectos poco acoplados. No creo que este sea un buen consejo para empezar far mucho mejor hacer que su sistema de compilación haga su trabajo principal correctamente, que calzando su sistema de control de fuentes para hacer algo para lo que realmente no está diseñado hacer. De todos modos, esta táctica de "compartir" choca terriblemente con los proyectos que viven dentro de una jerarquía de ramas más amplia para propósitos de SCM. Si no tienes mucho cuidado, TFS te permitirá crear relaciones arbitrarias de muchas a muchas ramas entre elementos de control de versiones. Buena suerte resolviendo eso (una vez tuve que hacerlo por un cliente, no bastante.)
No cree archivos con la misma ruta relativa en dos ramas de forma independiente; use Merge para ramificarlos o pasará horas persiguiendo conflictos de espacio de nombres. (n/a en 2010)
No vuelva a agregar archivos encima de una ruta donde antes existían otros elementos. Ya sea que los elementos antiguos fueron Renombrados / Retirados, o simplemente Eliminados, se enfrentarán a desafíos interesantes en el momento de la fusión; como mínimo, requerirá dos Checks para propagarse completamente. (n/a en 2010, aunque la experiencia todavía está algo degradada; solo se requiere 1 checkin, el contenido del elemento se conserva, pero el historial de nombres está en esa rama y todas las ramas posteriores)
No use la bandera / force a menos que sepas lo que estás haciendo. Las fusiones All / force son efectivamente cherry picks, lo que lleva a riesgos muy similares (el código se pierde durante el proceso de resolución, etc, etc).
No uses la bandera /baseless a menos que realmente sepas lo que estás haciendo. Te pierdes las eliminaciones similar similar a las etiquetas, excepto que los renombres siempre se transforman en ramas en lugar de solo en los casos de borde desafortunados. Usted no recibe ninguna protección de débito / crédito en absoluto. Y lo más aterrador de todo es que crearás nuevas relaciones de rama. A veces. (no se muestra retroalimentación al usuario en cuanto a si cada elemento de destino es nuevo, viejo con una nueva relación, o viejo con una relación existente)
Evite /deseche (y de forma equivalente, acepte sus resoluciones) cuando sea posible. Descartar algunos conjuntos de cambios solo para aceptar los siguientes es otro nombre para la selección de cerezas:)
Tenga cuidado con sus resoluciones en general. Cada uno tiene efectos secundarios únicos aparte de su efecto en la fusión en cuestión.
1. AcceptTheirs es una forma rápida y poderosa de obtener una fusión "copy", como se recomienda en la primera directriz. Si lo usa en otros escenarios también, recuerde que está no simplemente diciéndole a TFS que haga que el contenido del archivo sea el mismo. Le estás diciendo que los dos archivos están completamente sincronizados desde un POV de versiones. A saber, cualquier cambio previo en el archivo de destino que pudiera haberse fusionado en dirección opuesta ya no se considerará los candidatos una vez que compruebas un AcceptTheirs.
2. Tenga en cuenta que un AcceptMerge (auto o manual) cuyo contenido resultante sea idéntico al archivo fuente será considerado un AcceptTheirs por el servidor. No hay diferenciación en el protocolo Checkin webservice.
3. Usar AcceptYours cuando se trata de renombrar puede torcer tu cerebro. Rápidamente terminarás en una situación en la que "el mismo" elemento tiene diferentes nombres en diferentes ramas. Suponiendo que tenga una buena razón para descartando los cambios en primer lugar, este fenómeno no es inseguro en sí mismo in de hecho, probablemente sea necesario evitar interrupciones de compilación o personalizaciones únicas en sus makefiles. Es confuso para los humanos, y es muy probable que rompa cualquier script de automatización que tenga que asuma que las estructuras de árbol son consistentes de rama en rama.
4. AcceptMerge es el valor predeterminado por una razón. A veces conduce a más conflictos de versiones de lo que parece estrictamente necesario, pero es la opción más segura cuando se requiere una verdadera fusión. (Por ejemplo, paso #1 de la directriz principal "fusionar hacia abajo, copiar hacia arriba". Siempre y cuando sigas las otras pautas, el número de fusiones que requieren atención manual debería caer dramatically dramáticamente, así que si vienes de un flujo de trabajo que es pesado en la selección de cerezas.
Los errores deben estar vinculados al conjunto de cambios donde se realizó la corrección. Si más tarde necesita profundizar en las ramas aguas abajo para ver cuándo, dónde (y posiblemente cómo) se corrigió el error propagado, es una función de control de fuente pura. No es necesario contaminar el artículo de trabajo con equipaje adicional, y mucho menos alterar la forma en que fundamentalmente realiza fusiones. En 2005/2008 puedes recorrer el historial de fusiones con el comando 'tf merges' o una interfaz de usuario de terceros como Attrice SideKicks. En 2010 obtiene visualizaciones ingeniosas integradas en Visual Studio. Instrucciones y capturas de pantalla en MSDN.