Ciclo de lanzamiento más corto con DVCS


8

¿La elección de usar un DVCS en lugar de un CVCS realmente hace que los ciclos de lanzamiento sean más cortos? Si es así, ¿qué hace que los ciclos de lanzamiento de software sean más cortos y cuáles son los argumentos para esto?

  1. Relacionado con la solicitud de extracción? ¿La presentación más fácil de parches juega un papel aquí?
  2. Relacionado con el factor personas? ¿Los equipos de proyecto que usan CVCS actúan de manera más conservadora con los cronogramas de lanzamiento?
  3. ¿Algún otro factor?

Edité algunos de los "hechos" más presuntivos y cargué preguntas que algunos podrían encontrar insultantes y volví a abrir la pregunta. Debería ser una pregunta más imparcial y centrada que antes, pero si no está de acuerdo, hágamelo saber.
maple_shaft

Si el DVCS hace que el equipo sea más productivo, entonces SÍ. Si el DVCS no hace que el equipo sea más productivo, entonces NO. No hay magia en DVCS, es solo otra herramienta.
MrFox

Respuestas:


3

¿Qué hace que el ciclo de lanzamiento de software sea más corto con DVCS en comparación con CVCS?

No creo que haya necesariamente una diferencia entre DVCS y CVCS aquí, sino una diferencia en el modelo de ramificación al que se adhieren las personas.

Por lo que he reunido aquí y por mi experiencia, las personas que usan DVCS tienden a usar más ramas que las personas que usan CVCS. Y si desarrolla cada característica en una rama propia, es más fácil comenzar a preparar una versión con la nueva característica X, pero no la característica Y, cuyo desarrollo ha comenzado pero que aún no está listo para una versión.


Bueno, el modelo de ramificación al que se adhieren las personas se ve muy afectado por lo que facilita su sistema de control de versiones. Y no es una diferencia en esto.
Jan Hudec

3
Sin embargo, el hecho de que la ramificación (y lo que es más importante, la fusión ) es más fácil en DVCS que en la mayoría de CVCS no es una propiedad de distribución o centralización. Sería perfectamente posible que la fusión sea tan fácil en CVCS como en DVCS. Es solo que los usuarios típicos de CVCS nunca han experimentado una fusión fácil, por lo tanto, no saben que es posible y, por lo tanto, no solicitan esa característica a los proveedores. DVCS OTOH sería inútil sin una fácil fusión. Es la paradoja de Blub, básicamente.
Jörg W Mittag el

El modelo de ramificación se vuelve realmente difícil cuando es conceptualmente difícil separar entidades en ramas y hay mucho sangrado cruzado. Este no es un problema de implementación de CVS. Cuando esto sucede, necesita un enlace troncal y las confirmaciones frecuentes no 'combinan mejor'. Algunas cosas realmente necesitan ser centralizadas.
MrFox

3

Todos aquí parecen estar de acuerdo en que los proyectos que usan DVCS tienen ciclos de lanzamiento más cortos en general, pero aún no es seguro que la adopción de un DVCS provoque ciclos más cortos: ¡La correlación no es causalidad!

VCS distribuidos y ciclos de lanzamiento cortos son tecnologías relativamente nuevas. Es probable que los proyectos que abarcan uno abracen al otro, mientras que los grupos que prefieren lo probado y verdadero, o que tienen un flujo de trabajo establecido desde hace mucho tiempo, serán más conservadores y seguirán con CVCS y lanzamientos menos frecuentes.

Una mejor pregunta sería: "¿De qué manera el uso de un DVCS facilita el modelo de ciclo de lanzamiento corto?" Esto es lo que la mayoría de las respuestas están abordando, de hecho. El uso de un DVCS no impide que nadie tenga ciclos de liberación largos; adoptar los cortos es una opción, e implica metodologías de desarrollo, modelos de ramificación, revisiones de código, etc., no solo el VCS.


1
+1 para el primer párrafo. DVCS es un estándar entre las nuevas y ágiles startups ágiles, pero tiene pocos avances en grandes proyectos empresariales de estilo cascada. El nivel de complejidad, el entorno y los tipos de productos no son realmente los mismos.
MrFox

@suslik Hay bastantes empresas que usan BetKeeper o Sun TeamWare desde hace bastante tiempo.
johannes

2

¡Buena pregunta!

El CVCS cree en el principio primario de que todo debe seguir fusionándose / sincronizándose con 'el tronco'. Además, esperamos que a medida que evolucionamos, el enlace troncal sea el punto más estable antes de que se realice el lanzamiento. Entonces, las personas ponen su trabajo en una copia de trabajo, actualizan y prueban antes de registrarse. O, alternativamente, trabaja en ramas privadas / características y luego combina otros cambios troncales, prueba antes de reintegrarse.

El patrón DVCS puede ser significativamente diferente. Sigues ramificándote y bifurcándote. Puedes experimentar y finalmente fusionar ramas que tengan sentido. De vez en cuando escuchaste alguna solución de seguridad que debe salir inmediatamente, por lo que quieres que ese parche esté también en tu rama, ¡pero no quieres muchas otras cosas de tronco! Entonces, de manera predeterminada, sigue trabajando en su espacio, sigue tomando e integrando cosas, y llega el momento de la liberación, todos se sientan y deciden qué llevar y qué dejar.

Vea esto: http://nvie.com/posts/a-successful-git-branching-model/

Entonces, la diferencia esencial es esta: CVCS pregunta qué le dice la madre a sus hijos pequeños: no te alejes mucho más allá de un punto en el que pueda encontrarte, es decir, sigue sincronizando con el tronco. El DVCS funciona suponiendo que todo el trabajo está diseñado para ser independiente a menos que exista una necesidad explícita de fusionarse (por ejemplo, crear una versión).

Ahora volviendo a tu pregunta:

La explicación anterior en realidad suena más contraria a lo que observó / preguntó. ¡El verdadero desafío es definir qué es estable! cuando el número de usuarios es muy grande, y mientras las personas siguen vertiendo sus deltas, cada uno de ellos podría tener una ruptura en contra de otros cambios paralelos hasta que todos se hayan adaptado a su mejor nivel individual, así como toda la integración y las dependencias estén bien. Por lo tanto, cuando intente hacer una versión, uno necesita realmente sacudir las cosas, evitar que las personas ofrezcan nuevas funciones: identificar cualquier problema de integración cuando las cosas se fusionan, etc. ¡Todo esto implica que CVCS siempre le pide que tome 'descansos de lanzamiento' entre el desarrollo!

Cuando el número de contribuyentes se vuelve grande, llegar a este punto de 'interrupciones de liberación' se vuelve difícil y menos; y, por lo tanto, CVCS realmente lo obligará a hacer 'festivales de creación de lanzamiento' después de uno muy significativo.

En DVCS, sigue trabajando, probando, trabajando probando en su propio espacio. La creación e integración de la versión es una actividad bastante paralela y también puede permitirse hacer intentos de error al ver qué conjuntos de parches funcionan juntos y cuáles no (por lo tanto, se tomarán o se eliminarán de las versiones). En DVCS, puede desacoplar el desarrollo individual y, de vez en cuando, simplemente echar un vistazo si eso tiene sentido.


¿Qué son los 'descansos de liberación'?
linquize

¡Una pequeña pausa en el desarrollo hasta que el tronco se estabilice para crear un lanzamiento! Esto puede o no ser significativo dependiendo de la madurez de los desarrolladores.
Dipan Mehta

2
No compro el argumento de 'interrupciones de lanzamiento'. Me parece que ese es un problema con su ramificación en lugar de CVCS como concepto.
James

+1 @ James. Mi grupo estaba acostumbrado a "liberar pausas" o "bloqueos de código", cuando usamos una versión de PVCS muy desactualizada. Nos hemos movido a TFS (definitivamente no es un DVCS) y usamos ramas, no "interrupciones", para estabilizar las versiones. Sin embargo, es difícil romper con los desarrolladores de pensar en un "congelamiento de código" para cada versión.
DaveE

1

¿Qué hace que el ciclo de lanzamiento de software sea más corto con DVCS en comparación con CVCS?

Estoy de acuerdo con Bart en que la razón principal es el modelo de ramificación utilizado, pero el tipo de sistema de control de versiones afecta directamente qué modelos de ramificación son viables. Entonces tenemos dos subpreguntas. ¿Qué modelo de ramificación soportan mejor los sistemas distribuidos y por qué acelera el ciclo de lanzamiento?

La diferencia fundamental entre el control de versiones centralizado y distribuido es que sin la autoridad central no se puede aplicar una línea de tiempo lineal. Por lo tanto, para hacer posible el control de versiones distribuidas, estos sistemas necesariamente tenían que definir el historial como un gráfico acíclico dirigido, donde cada revisión simplemente tiene un identificador único, una o más revisiones principales y puede tener muchas revisiones secundarias arbitrarias de las que quizás ni siquiera esté al tanto, porque aún no se sincronizó con el sistema donde se crearon.

Resulta que este enfoque se presta muy bien a la ramificación. No tiene que hacer nada para obtener una sucursal, simplemente siempre tiene una. Por lo tanto, puede sumergirse directamente en el trabajo de cabeza y dejar decidir cuándo y dónde fusionarlo o incluso dónde guardarlo y con qué nombre hasta que sepa si realmente va de la manera que necesita.

En contraste, todos los sistemas centralizados mantienen la historia como un conjunto de ramas con una secuencia lineal de revisiones. Por lo tanto, debe decidir de antemano si necesitará una rama, asignarle un nombre y crearla explícitamente. Esto es bastante doloroso cuando aún no sabes lo que vale la idea y, a menudo, simplemente no lo sabes antes de comenzar a programar. Complicado por el hecho de que en la mayoría de los sistemas centralizados los nombres de las sucursales son globales, significativos, a menudo persistentes y no se pueden cambiar fácilmente, mientras que en todos los sistemas distribuidos principales son solo nombres locales que se pueden cambiar a su antojo y reciclar libremente. Y por el hecho de que todas las operaciones de bifurcación y fusión suelen ser un poco más lentas en CVCS.

Por lo tanto, DVCS facilita las ramas y, por lo tanto, los equipos que usan ramas DVCS todo el tiempo, mientras que los equipos que usan CVCS las evitarán la mayor parte del tiempo.

Ahora, ¿por qué usar ramas permite lanzamientos más frecuentes? Bueno, cada equipo subestimará una tarea de vez en cuando, a menudo cuando aparece un error difícil de rastrear. Los equipos que usan sistemas centralizados generalmente realizan toda la depuración, y la mayoría del desarrollo, en el tronco, porque las ramas son inconvenientes. Por lo tanto, no pueden liberar hasta que eliminen la mayoría de los errores y tengan que intercalar las fases de desarrollo y depuración.

Por el contrario, en los sistemas distribuidos donde todo el trabajo se realiza en ramas, estos se pueden combinar para probar, probar, corregir errores y solo el trabajo que pasa las pruebas se fusionó por separado con el tronco. Como resultado, el tronco tiene muy pocos errores y, por lo tanto, se puede liberar con más frecuencia, generalmente cada vez que aparece una característica importante.

También ayuda que siempre que haya un cambio en las prioridades, el trabajo en progreso se pueda archivar trivialmente con el enfoque de ramificación utilizado con los sistemas distribuidos. En la mayoría de los proyectos reales, los cambios en las prioridades ocurren todo el tiempo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.