DVCS bendito réplica de repositorio entre equipos distribuidos geográficamente

Mi compañía está explorando el cambio de Perforce a un DVCS y actualmente utilizamos muchos servidores proxy de Perforce porque los equipos de desarrollo de software se extienden por Alemania, China, EE. UU. Y México y, a veces, el ancho de banda de un lugar a otro no es tan bueno.

Hablando con TI, comenzamos a buscar una manera de mantener las cosas funcionando sin problemas desde la perspectiva distribuida geográficamente para que todos obtengan lo último y lo mejor sin determinar qué servidor de repositorios es la fuente de la verdad (es decir, replicar de manera transparente ).

Pensé que tal vez podríamos emular el mecanismo de DNS a través de ganchos pre-push y pre-pull . Por ejemplo, considere los países A, B y C. Al retirarse de la bendita A, A misma extraerá los cambios de B, lo que a su vez atraerá los cambios en C. Si B y C tienen nuevos cambios, caerán hacia A. Por el contrario, cuando hay un impulso, podría propagarse a todos los repositorios bendecidos.

Soy consciente de que, en general, solo tiene un repositorio bendecido, sin embargo, esto puede no escalar a nivel mundial y cada repositorio bendecido sería aplicable a los equipos de un solo país.

Mi pregunta es : ¿la concepción de la replicación de repositorios de DVCS es algo utilizado en la práctica ?, ¿alguien lo ha hecho con éxito ?, de ser así, ¿cuál es la forma correcta de hacerlo?

Esta pregunta se refiere a la replicación transparente y sospecho que todavía no hay respuestas porque la gente podría estar obsesionada con la transparencia. Me tomaré la libertad de dejar de lado la transparencia por el momento para centrarme en la replicación. Trataré con (o delicadeza) la transparencia más tarde, y de hecho no creo que sea tan importante en un DVCS.

Primero, permítanme analizar algunos puntos clave sobre la forma en que funcionan los repositorios en un DVCS. (Estoy más familiarizado con Mercurial, así que eso es lo que usaré para ejemplos, pero creo que todo lo que digo también es cierto para git).

R. En un DVCS, cualquier clon contiene el mismo contenido de archivo e historial que el original.

Si mantiene los repositorios sincronizados correctamente, esto significa que puede usar operaciones de propagación de cambios DVCS normales (clonar, empujar, tirar) y repositorios normales para construir un sistema de replicación.

B. Los nuevos cambios no tienen que propagarse a su origen.

En particular, si tuviera que obtener cambios de un repositorio particular y agregar algunos cambios propios, mis cambios no tendrían que volver a ese repositorio particular. Pueden ir a otro lado. La utilidad de esto debería quedar clara a partir de los ejemplos que mostraré a continuación.

C. Los cambios se pueden propagar mediante push o pull.

En un sistema centralizado, los nuevos cambios solo se pueden introducir (creo) en el repositorio. En un DVCS, es posible configurar una variedad de topologías de propagación de cambios, algunas de las cuales implican solo extracción. Esto ofrece más flexibilidad en la configuración.

Ejemplos

En aras de la discusión, digamos que sus equipos distribuidos usan sistemas en los dominios duke.de, duke.us, duke.cn y duke.mx, y además duke.de es donde queremos tener el repositorio "bendecido". Teniendo en cuenta estos supuestos, permítanme presentar una serie de ejemplos de diferentes topologías que podría configurar, teniendo en cuenta los tres puntos clave de DVCS anteriores.

0. Modelo de empuje centralizado

Tenga un único repositorio en hg.duke.de y haga que los desarrolladores de todas las ubicaciones clonen y extraigan desde aquí y empujen los cambios aquí. Esto podría funcionar para la gente en Alemania, pero probablemente sería un problema para las personas en el resto del mundo. Todas las operaciones de clonación, extracción e inserción atravesarían enlaces de red lentos de larga distancia. Esto está usando un DVCS como un sistema centralizado. Este es el problema que estás tratando de resolver.

1. Push centralizado con replicación

Tenga el repositorio bendecido en hg.duke.de y tenga réplicas en hg.duke.cn, hg.duke.mx y hg.duke.us. Los desarrolladores clonan desde su réplica local y envían los cambios a hg.duke.de. Cada vez que aparecen nuevos cambios en hg.duke.de, se ejecuta un gancho que los propaga a las réplicas. De lo contrario, las réplicas son de solo lectura, por lo que nunca habrá fusiones o conflictos.

Si soy un desarrollador en México, por ejemplo, clonaré desde hg.duke.mx pero empujaré los cambios a hg.duke.de. Si se introducen otros cambios en hg.duke.de antes de que pueda enviar mis cambios, se bloqueará mi inserción. Los otros cambios se replicarán a hg.duke.mx, por lo que extraeré estos cambios localmente, los fusionaré y luego intentaré presionar a hg.duke.de nuevamente.

Esto debería proporcionar algunas ventajas, ya que las grandes operaciones de clonación se realizan localmente. Empujar al repositorio central en otra ubicación puede no ser tan malo, ya que los cambios se empujan con poca frecuencia, los cambios incrementales generalmente son bastante pequeños. (Mercurial, en particular, esencialmente envía archivos comprimidos, no archivos completos y sus historiales).

En Mercurial, puede configurar un repositorio local para extraer de una ubicación y empujar a otra colocando algo como lo siguiente en el .hg/hgrcarchivo:

[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de

2. Modelo de extracción simple

Continuando con hg.duke.de como el repositorio bendecido y los demás como réplicas, podemos propagar los cambios a través de pull en lugar de push. Los desarrolladores clonan y extraen de su réplica local como de costumbre. Cuando un cambio está listo, un desarrollador envía una solicitud de extracción a algún servicio central, que extrae del repositorio del desarrollador a hg.duke.de. Será necesario establecer una política para las fusiones. Por ejemplo, si hay conflictos de fusión, la solicitud puede ser rechazada, lo que requiere que el desarrollador extraiga (de la réplica local), combine y vuelva a enviar la solicitud de extracción.

Este enfoque tiene la ventaja de no hacer que el desarrollador espere mientras se propagan los cambios. Por supuesto, el desarrollador todavía tiene que esperar a que se aplique la solicitud de extracción, pero al menos puede trabajar en cambios adicionales durante ese tiempo.

Variaciones

Hay un montón de variaciones que se pueden aplicar.

La presentación de una solicitud de extracción es un momento perfecto para la revisión del código. Los cambios se publican, en el sentido de que están disponibles para todos, pero aún no se han integrado en el bendito repositorio.

Las solicitudes de extracción se pueden realizar de forma manual o mediante algún sistema automatizado. El procesamiento de una solicitud de extracción podría no combinar los cambios directamente en el repositorio bendecido, sino en un área de preparación temporal donde se realiza un ciclo de construcción y prueba. Solo después de pasar todas las pruebas, el conjunto de cambios se integraría en el repositorio bendecido.

Quienes se sientan más cómodos con un modelo de inserción pueden querer configurar un repositorio de preparación local en cada ubicación, junto con la réplica, por ejemplo, hg-stage.duke.mx, hg-stage.duke.cn, etc. Esto requiere un poco más de trabajo, sin embargo, como los desarrolladores no solo tienen que fusionarse con otros cambios locales, sino que alguien tiene que ser responsable de fusionar los cambios de los repositorios en el repositorio bendecido. Sin embargo, esto puede funcionar en las circunstancias correctas y puede ser ayudado por la automatización.

"Transparencia"

Ahora al tema de la replicación transparente.

Dado los escenarios anteriores, realmente no veo la necesidad de una replicación transparente. Todos los repos son visibles para todos, y existen convenciones para extraer / clonar de la réplica local y empujar a un repositorio bendecido o un área de preparación local.

Si desea transparencia, puede hacer que las personas configuren dominios de búsqueda DNS de acuerdo con su ubicación. La réplica local y los repositorios de preparación simplemente se denominarían "hg" y "hg-stage" y la configuración de DNS los resolvería en hg.duke.cn y hg-stage.duke.cn para desarrolladores en China, y en consecuencia para desarrolladores en otros lugares. Pero esto es un poco de magia y puede ser confuso, y realmente no creo que agregue mucho.

Espero que esto responda tu pregunta. Me tomé algunas libertades con la respuesta, pero me parece que su situación podría remediarse mediante el uso de las técnicas que he descrito anteriormente.