¿Qué tan adecuado es un DVCS para el entorno corporativo?

Question

He estado usando SVN desde hace un tiempo, y estoy muy contento con la forma en que funciona (pero no puedo decir que soy un experto, y realmente no he hecho mucho con las sucursales y la fusión). Sin embargo, ha surgido la oportunidad de introducir algunas prácticas nuevas en un nuevo equipo, así que pensé en echar un vistazo a las DVCS para ver si vale la pena dar el salto.

La empresa para la que trabajo es una empresa bastante estándar en la que todos trabajamos en el mismo lugar (o a veces en casa) y queremos mantener un almacén central de todos los códigos.

Mi pregunta es: si todo lo que hace con un DVCS es crear un centro central en el que todo el mundo impulsa sus cambios, ¿hay realmente algún beneficio al pasar a un DVCS y sus gastos adicionales en este tipo de entorno?

Answer 1

Con DVCS las personas pueden mantener sus propias sucursales locales sin realizar ningún cambio en el repositorio central, y enviar sus cambios al repositorio principal cuando creen que está cocinado. Nuestro proyecto está almacenado en un repositorio SVN pero personalmente utilizo git-svn para administrar mis cambios locales y lo encuentro bastante útil, porque no podemos enviar todos los cambios de inmediato (primero tienen que ser aprobados por el integrador).

Answer 2

Personalmente, considero que es un gran beneficio. Incluso con un repositorio central, un DVCS cambia el flujo de "editar código, actualizar desde central, confirmar" a "editar código, confirmar, enviar a central". Entre otras cosas, eso significa que la resolución de conflictos es mucho menos estresante. También puede fomentar el desarrollo en trozos más pequeños, ya que no tiene que presionar después de cada compromiso. Si tu equipo está de acuerdo con eso, eso significa que tus compromisos individuales pueden dejar la aplicación en un estado extraño, siempre y cuando funcione cuando finalmente presionas al repositorio central. Si no están de acuerdo con eso, siempre y cuando esté usando git (o patch queues para hg, IIRC), aún puede hacer dev con el mismo estilo, pero luego condensa todas sus confirmaciones más pequeñas en una confirmación más grande que está completa antes de empujarlo al repositorio central.

Answer 3

Creo que el principal beneficio de un DVCS viene cuando desea enviar sus cambios directamente a otras personas (o máquinas, por ejemplo, llevar el repositorio a su casa), sin pasar por un centro central. Si tiene la necesidad de hacer esto, un DVCS es definitivamente el camino a seguir. Si, como usted dice,

todo lo que está haciendo con un DVCS es la creación de un eje central que todo el mundo empuja sus cambios a

entonces ’ re no realmente aprovechando el propósito principal de una DVCS y yo diríamos que SVN es suficiente.

P.S. También se podría argumentar que un DVCS alienta a los usuarios a cometer más a menudo, ya que pueden hacerlo en su repositorio personal y publicar solo sus cambios cuando ’ estén listos —, pero esto puede lograrse fácilmente en SVN usando ramas, con el único “ Abajo ” siendo que “ personal ” commits incrementa el número de versión de todo el repositorio.

Answer 4

Tendrá la inevitable guerra de Git contra Mercurial comenzando aquí pronto ... :-) Yo personalmente uso Mercurial, pero lo que tengo que decir debe ser adecuado para todos DVCS.

En mi opinión, sí, son adecuados para uso corporativo. Los uso en mi propia empresa, aunque con un pequeño número de desarrolladores que la usan, pero si te preocupa la escalabilidad, mira los grandes proyectos de Código abierto usando git y mercurial, p. Mozilla, Python.

El enfoque del eje central funciona bien: es un modelo de trabajo familiar para los usuarios de subversión y siempre tiene una versión "definitiva". Bloquea el acceso a esto y aplica cualquier gancho para hacer cumplir las políticas de compromiso y, después de eso, los desarrolladores tienen una gran cantidad de libertad para trabajar cómo les gusta con sus copias locales.

Otra gran ventaja es que he encontrado fusión mucho menos dolorosa con mercurial que con subversión.

Lo que es más complicado con un DVCS es administrar archivos binarios; no se puede requerir un bloqueo en un archivo binario como se puede con subversión (entre otros). Administre esto con comunicación idealmente.

Por último, la clonación de un repositorio es ideal para mantener las cajas en sincronización si está trabajando desde varias PC.

Espero que esto ayude. K

Answer 5

Todo depende de cómo desee trabajar en los proyectos. Los entornos distribuidos son geniales si todos quieren construir en su propia sucursal. Prefiero un repositorio central para mi trabajo (en un equipo pequeño) ya que hace que los desarrolladores piensen en lanzar una versión de nuestro producto.

En mi experiencia, veo a muchos usuarios de DVCS que piensan en sus propios cambios como aquellos que no tienen que revisar y estos usuarios revisan los cambios de todos los demás desarrolladores antes de fusionarlos en su propio árbol. Me gusta ver mis cambios como el cambio al producto principal, por lo que reviso estos cambios antes de enviarlos. Como resultado, tratamos de mantener el producto bastante estable durante todo el ciclo de desarrollo. Refactorizar funciona bien, ya que todos actualizamos a menudo.

Varios usuarios de DVCS que conozco prefieren trabajar en su función en un árbol independiente y dejar la integración con el producto central en la fase final de su desarrollo. Esto funciona bien si la característica es independiente, pero no me gustaría ser quien tenga que integrar todas las características desarrolladas de esta manera con un plazo a la vista. Si integras a menudo, los DVCS no difieren mucho de los VCS centrales, y la mayoría de los DVCS admiten un repositorio central, mientras que cada vez más VCS centrales admiten varias características exclusivas de DVCS, como confirmación y estantería sin conexión.

(FYI: Fuera de línea cometa, está previsto para Subversion 1.8)

Answer 6

la sobrecarga no es tan grande, de hecho, en nuestro entorno, el empuje hg añadido es menos de una sobrecarga que cometer al repositorio central de SVN era . pero la mayor ventaja son todas las campanas y silbatos que vienen con mercurial, que son excelentes para un desarrollador individual, independientemente del tamaño del equipo o el flujo de trabajo. en primer lugar, el hecho de que cada WC sea un repositorio es excelente, ya que puede experimentar mucho más libremente sin contaminar el repositorio maestro. luego, hay una funcionalidad que se basa en la igualdad wc == repo: bisect para encontrar rápidamente la revisión donde se introdujo un error, grep para, bueno, grep el historial, así como la funcionalidad que simplemente falta de la subversión, como diffs coloreados en terminal.

Answer 7

La gran ventaja de usar un DVCS para mí es que puedo comprometerme con mi repositorio local sin tener que compartir estos cambios con todos los demás. Así que cuando trabajo en un gran cambio hago pequeños commits incrementales, lo que significa que puedo revertir solo los últimos 30 minutos de trabajo, o hacer una diferencia con una versión que estaba funcionando ayer, pero solo presionar al repositorio central una vez que todo mi trabajo está completo .

Creo que este beneficio solo vale la pena pasar a un DVCS para.

Sin embargo, usar un DVCS requiere un poco más de reflexión y comprensión y utilizar un sistema de control de versiones "estándar" como SVN o CVS, por lo que tendrá que considerar la sobrecarga de capacitación si se mueve a un DVCS o su repositorio central lleno de muchas ramas diferentes que la gente no se dio cuenta de que estaban creando.

Answer 8

Incluso con un flujo de trabajo concentrador, un DVCS le permite realizar pequeños commits localmente, fusionarlos solo cuando lo desee e insertarlos cuando estén listos.

con un no-DVCS, que se ven obligados a cualquiera:

1. hacer su trabajo sin cometer, hasta que sea pulida y empujar una enorme commit.
2. haga pequeños commits sobre la marcha, que todos tienen que fusionarse a menudo, aunque fusionar compromisos intermedios no les aporta nada de valor.

Y si explora un callejón sin salida, sin DVCS: con el primer método, no puede rebobinar, no tiene un compromiso al que volver; con el segundo, tanto los commits como los reverts tenían que ser combinados inútilmente por todos los demás.

Answer 9

Bazaar VCS pueden funcionar como VCS distribuidos y como VCS centralizados para que tenga la libertad de seleccionar el flujo de trabajo que necesita. Al mismo tiempo, las sucursales privadas locales (donde las personas pueden experimentar mientras trabajan en nuevas funciones y al mismo tiempo comprometer su progreso regularmente) es gran beneficio.

También DVCS realiza un flujo de trabajo de desarrollo natural cuando se requiere la revisión obligatoria del código antes de que los nuevos cambios se conecten al enlace troncal. Este flujo de trabajo (con respecto a SVN) se describe brillantemente en el UQDS article. Y a pesar de que el artículo describió el flujo de trabajo basado en SVN, lo encontrará más natural cuando use cualquier DVCS en lugar de SVN, porque en DVCS la bifurcación y fusión es una operación básica de primera clase.

Answer 10

Personalmente, creo que la mayor ventaja de DVCS es que se compromete (localmente) antes de la fusión, por lo que si a mitad de la fusión resulta ser más complejo de lo que pensaba originalmente, es trivial volver a un estado limpio sin perder tu trabajo compare con CVCS donde generalmente tiene que fusionarse exitosamente antes de poder comprometerse.

ventajas adicionales incluyen:

• trabajar desde casa/en el sitio de clientes se hace más fácil, ya que no requiere conexión a la red sólo para comprobar algo en, y si usted espera hasta volver a la base para impulsar cambios de la historia se conserva en lugar de agrupar todo en un solo cambio.
• La mayoría de las operaciones DVCS son mucho más rápidas ya que no necesitan extraer datos a través de la red
• Algunas cosas (p. Ej. Scripts de configuración de usuario) se comparten mejor directamente entre desarrolladores que desean compartirlas en lugar de a través de una central ubicación

Answer 11

En mi experiencia hay varias maneras de utilizar un DVCS dentro de un entorno corporativo:

• el soporte multi-sitio: se ha separado equipos y utiliza su DVCS para establecer diferentes " servidores "en cada ubicación por lo que el No estás limitado por los problemas de red subyacentes (y créeme, habrá).Solía ​​hacerse con "cosas grandes" como Clearcase Multi-site o Wandisco (para SVN/CVS), pero ahora es bastante factible con los sistemas DVCS.

• Soporte "usuarios de roaming": usted es un corp. desarrollador pero desea trabajar en casa por un tiempo determinado (o nunca): en lugar de depender de la VPN, puede tener un DVCS en su computadora portátil y luego puede comprometer, revisar, diferenciar, ramificar y fusionar sin ser lento abajo por el servidor central. Se sincroniza de nuevo cuando está en línea o de vuelta en la oficina.

• Verdadero "desarrollo distribuido": que es el caso extremo: cada desarrollador tiene su propio DVCS (como lo haría en el mundo de OSS). Realmente dependerá de las habilidades y la motivación del equipo: si el equipo realmente quiere avanzar, se beneficiarán, de lo contrario será la pesadilla de SYSADM tener que gestionar ni un solo depósito, sino cientos ... con sus problemas correspondientes.