¿Dónde podrían estar actualmente los sistemas de control de versiones distribuidas en el ciclo exagerado de Gartner? [cerrado]

12

Editar : Dada la reciente votación negativa (+ 8 / -6 en este punto) me quedó claro que el ciclo de vida de Gartner es una métrica sesgada desde la perspectiva de un programador. Esto es algo que forma parte de un documento que voy a presentar a la gerencia , y los tipos de gestión son parte de la audiencia de Gartner.

Dando exposición y entusiasmo a DVCS (que "podría" considerarse exagerado, o al menos atacado como tal ), piense en la siguiente pregunta al leer esta: "¿cómo podría usar el ciclo de exageración de Gartner para convencer a la gerencia de que los DVCS están listos (o listo para nosotros) y que no es solo una exageración "

Solo preguntar si DVCSs es bombo no sería constructivo, el ciclo de bombo de Gartner es un instrumento más objetivo que solo preguntar eso (incluso si este instrumento se considera sesgado). Si conoce algún otro instrumento, por favor, menciónelo.

Edición n. ° 2 : estoy de acuerdo en que el ciclo de vida de Gartner no es para todas las tecnologías, pero considero que puede haber generado suficiente expectación para que algunos lo consideren una exageración, por lo que tal vez merezca ser evaluado / meditado como tal al usar este instrumento en para probarlo / refutarlo en cualquier grado. Soy un defensor de DVCS, por cierto.

Edición n. ° 3 : Gracias por sus respuestas. Bounty acude a Caleb por responder mi pregunta con detalles y consejos prácticos. La respuesta aceptada va a philosodad por proporcionar otro instrumento útil y responder más allá de mi pregunta.


Estoy investigando para un documento técnico que estoy escribiendo a favor de la adopción de DVCS en la empresa y me topé con el concepto de prueba social . Quiero demostrar que la prueba social de la adopción de DVCS no es necesariamente culto a la carga y, al hacer más investigaciones, ahora me topé con el ciclo exagerado de Gartner que describe la madurez tecnológica en 5 fases.

ingrese la descripción de la imagen aquí

Mi pregunta es: ¿qué podría ser un indicador de la ubicación actual de los sistemas de control de versiones distribuidas (me refiero a git, mercurial, bazar, etc. en general) en una fase particular del ciclo de bombo? ... en otro (menos complicado) Es decir, ¿diría que las expectativas actuales de los DVCS son a) comenzar, b) inflar, c) disminuir (desilusión), d) aumentar (iluminación) oe) estabilizarse (madurar) y (más importante) ¿por qué ?

Sé que es una pregunta difícil y hay subjetividad involucrada, pero concederé la respuesta (y la cookie tradicional) al argumento / evidencia más claro para una fase en particular.

dukeofgaming
fuente
1
a más de 10 años , tiene que estar en la "Meseta de la productividad" según esa escala artificial
mosquito
@gnat: ¡Estoy de acuerdo al 100%! En el año 2000, cuando trabajaba en Sun, utilizaba SCCS / Teamware, lo cual fue correcto. Me rasqué la cabeza preguntándome cómo alguien podría gustarle CVS. Linus Torvalds pensó lo mismo, y se quedó con BitKeeper hasta que hizo Git. ¡Es CVS / SVN que tuvo el bombo innecesario!
Macneil
@Macneil, según mi recuerdo, CVS / SVN era capaz de ejecutarse en Windows y Linux, mientras que TeamWare / SCCS estaba bloqueado en el sistema de archivos Solaris (en Linux se ejecuta más o menos, si uno supiera cómo piratear la "suma de comprobación cero" espuria loco). No es que uno u otro medio es mejor, simplemente añadiendo algunos datos
mosquito
77
La escala de tiempo en el gráfico no parece estar relacionada con el tiempo desde la introducción original. Solo por ejemplo, "Energía inalámbrica" ​​se muestra hacia el lado izquierdo a pesar de que Tesla lo hizo en la década de 1890 e incluso si lo restringimos a cosas de alta tecnología / computadora, las etiquetas RFID pasivas también lo han estado utilizando durante bastante tiempo.
Jerry Coffin
@gnat: El tiempo no significa nada aquí. Cualquier tecnología dada puede permanecer para siempre en una etapa específica e incluso morir allí.
CesarGon

Respuestas:

5

El ciclo de exageración mide la cantidad de noticias / rumores que genera una cosa en particular, no el uso real de la cosa o su valor de productividad real. Entonces ... diría que desde esa perspectiva, DVCS está alcanzando un pico en su ciclo de noticias. En realidad, suficientes personas lo usan y alientan a otras personas a que lo usen, ya que está recibiendo mucha atención en el mundo de la tecnología. Una vez que la adopción esté más extendida, espero que las noticias / rumores se desvanezcan un poco cuando aparezca algo nuevo y brillante, y luego aumenten nuevamente a medida que las personas comiencen a comprender los sistemas más completamente.

Una forma de ver el ciclo de exageración es observar la cantidad de nuevos adoptantes. El número de nuevos adoptantes de una tecnología tiende a seguir la misma forma de curva exacta que el ciclo de bombo. Tiene sentido que el rumor sobre una nueva tecnología dada vaya a crecer rápidamente a medida que la tecnología gane un gran número de nuevos adoptantes. Los primeros en adoptar difundieron la innovación, y los que adoptaron en el medio generaron el rumor.

El zumbido durante la rápida adopción de una innovación está necesariamente mal informado. Si hay muchas personas que saben de algo pero no lo saben, tendrán expectativas diferentes y posiblemente mayores que los usuarios experimentados. De ahí viene el bombo publicitario.

El zumbido después de que la tasa de adopción haya alcanzado su punto máximo va a caer ... en parte porque antes, las expectativas poco realistas no han valido la pena (DVCS lo hará más productivo, tal vez, pero no solucionará todos sus problemas) y en parte porque algo más está pasando por un período de adopción rápida y está ocupando toda la mente compartida. El bombo es inconstante.

Pero en algún momento, comienza a obtener una tasa bastante constante de nuevos adoptantes, la innovación se ha convertido en la norma, y ​​los nuevos adoptantes quieren saber cómo usar esta cosa que ya han decidido que necesitan usar. Entonces, el zumbido en torno a la innovación tiene que ver con lo que las personas realmente están haciendo con él ahora que lo están usando, en lugar de lo que podrían hacer con él si lo estuvieran usando.

Entonces, si tomó la curva de exageración y la colocó junto a la curva S de las tasas de adopción (vea "Difusión de innovaciones" de Everett Rogers), esperaría que la exageración alcanzara su punto máximo cuando la curva S es más pronunciada, a medida que la curva S cambia dirección, y subir de nuevo a medida que la innovación alcanza su plena saturación del mercado.

DVCS se encuentra en un período de rápida adopción, por lo que probablemente estamos en algún lugar alrededor del pico del ciclo de bombo.

filosodad
fuente
Entonces, ¿básicamente estás diciendo que los DVCS podrían estar en la cima porque la gente todavía está predicando al respecto ?, ¿o aumentando de nuevo porque se está entendiendo mejor?
dukeofgaming
Diría que el grupo potencial de adoptantes aún es grande, por lo que hay mucha curiosidad y nuevos usuarios entusiasmados. Si nos fijamos en la curva S en la "Difusión de innovaciones" de Rogers, creo que DVCS está en la parte empinada: se está adoptando rápidamente. Esta rápida adopción genera exageración en las noticias / rumores. A medida que la adopción se satura, la exageración disminuye. La cosa ahora es noticia vieja. Luego, cuando la adopción se convierte en la norma, las noticias y los rumores se vuelven más sobre lo que la gente está haciendo realmente, en lugar de lo que podrían hacer.
philosodad
1
philosodad, ¿podría colaborar en esto como parte de la respuesta?
dukeofgaming
@dukeofgaming He modificado mi respuesta para dar más detalles sobre ese punto.
philosodad
15

No pretendo ser un experto en el tema de los ciclos de bombo, pero ofreceré algunas observaciones:

  1. El ciclo exagerado parece ser más un producto de las expectativas y la cobertura de los medios que una característica de la tecnología misma. Mi diccionario dice que exagerar es "publicidad o promoción extravagante o intensiva". Define la publicidad como "el aviso o atención prestada a alguien o algo por los medios de comunicación". Medios es un término colectivo para los diversos canales de comunicación de masas.

  2. Si acepta el punto anterior, se deduce que el ciclo de exageración se aplica solo cuando los medios cubren una tecnología determinada.

  3. No está nada claro que el ciclo de exageración se aplique a todas las tecnologías. Las revistas científicas están llenas de informes de avances que los principales medios de comunicación nunca notan. Sin la cobertura de los medios, es menos probable que se inflen las expectativas y se puede evitar la depresión.

  4. Los sistemas de control de versiones distribuidos no son tanto una idea nueva como un refinamiento de una vieja. Es difícil llamarlos una "tecnología emergente" del tipo que se supone que predice el ciclo de exageración.

Antes de comenzar a construir un caso para que los DVCS se ajusten a un gráfico de ciclo de bombo, debe construir un caso en el que el control de versión distribuido esté sujeto al ciclo de bombo. ¿El control de versiones distribuidas como "tecnología" obtiene cobertura de los medios? ¿Existen ahora, o ha habido alguna vez, expectativas infladas para el control de versión distribuido? ¿Es probable que los usuarios de DVCS se desilusionen cuando los productos DVCS no cumplan con las expectativas?

Me parece más probable que el control de versiones distribuidas sea solo una mejora en una categoría existente de productos, al igual que SVN fue una mejora en CVS. Si tuviera que trazar la tasa de adopción de SVN, no creo que obtenga una trama que se parezca al ciclo de exageración; en su lugar, obtendría una trama que aumentará constantemente hasta la meseta del dominio del mercado, seguido de una disminución lenta y prolongada a medida que los sistemas distribuidos como 'git' ganen popularidad.

Si realmente necesita una respuesta de ciclo exagerado, sugeriría que DVCS se uniera al juego al final de un período de desilusión / frustración con los sistemas de control de versiones no distribuidos y ha estado subiendo la cuesta de la iluminación a medida que aumenta la tasa de adopción.

En lugar de confiar en el ciclo de exageración para su argumento, sugeriría centrarse en la tasa de adopción del control de versión distribuido y las razones para ello. Hay mucha evidencia anecdótica de que las personas se están cambiando a DVCS porque funciona; por el contrario, no he oído hablar de conmutación a nadie volver a un sistema no distribuido, ya que se sintieron decepcionados. Para obtener algunos datos duros, puede intentar hablar con una empresa de alojamiento como Beanstalk . Además, preste atención a la interoperabilidad entre sistemas centralizados y sistemas distribuidos. Escuché que 'git' juega muy bien con SVN. Los sistemas centralizados continúan funcionando bastante bien en el ámbito corporativo, por lo que enfatizar "juega muy bien con"

Actualización en respuesta a la edición de OP:

¿Cómo podría usar el ciclo de bombo de Gartner para convencer a la gerencia de que los DVCS están listos (o lo suficientemente listos) [?]

Creo que hay algunos enfoques que podrían ayudar aquí, y todos se basan en datos duros:

Tendencias de Google. Obviamente, Google recopila un montón de datos sobre lo que hay en la red y lo que las personas buscan. Hace unos días, busqué (pero no pude encontrar) evidencia del control de versión distribuido wrt cycle wrt. http://trends.google.com/ dice que no hay suficientes datos para los términos dvcs o control de versión distribuido cuando limito la región a los EE. UU. (y los resultados de dvcs para el mundo no parecen muy relevantes o útiles). Buscar términos más específicos fue algo mejor, pero complicado por el hecho de que los nombres de productos como git y mercurial tienen otros significados (¿quién sabe?). El resultado para git muestra una tendencia que podría deberse en parte al sistema de control de versiones:

tendencia git

Intentando hacerlo más específico para el control de versiones, probé el repositorio de git :

tendencia del repositorio git

Una más ... pensando que si la gente está adoptando git debería haber una tendencia creciente en la búsqueda de ayuda con los comandos de git, probé git pull (azul), git commit (rojo) y git rebase (oro):

tendencia git pull / commit / rebase

Ese último gráfico parece proporcionar la mejor evidencia de que las personas están adoptando y usando git.

Búsqueda de Google.

Intente simplemente buscar términos como control de versión distribuido y anote las fechas en, digamos, los 25 artículos principales que encuentre. Trazar los resultados. La mayoría de los mejores éxitos que encontré tenían fechas en el rango 2007-2009. Si se aplica el ciclo de exageración, y si puede demostrar que la mayor parte de la cobertura de los medios ocurrió hace 3-5 años, parece una evidencia bastante buena de que hemos superado el pico de expectativas infladas.

Recopile ejemplos de proyectos que usan DVCS.

Hay muchos ejemplos en el mundo de código abierto, incluidos algunos grandes como Linux. (Linus Torvalds creó git para ayudar a administrar el desarrollo de Linux.) Más útiles para usted serán ejemplos de corporaciones que usan un DVCS. (Si hay algo que los gerentes odian más que adoptar una tecnología demasiado pronto, está quedando atrás). La exageración es solo eso: rumores sobre una tecnología o producto. Si puede encontrar evidencia de la adopción corporativa de DVCS, eso ayudará a contrarrestar el argumento de "es solo una gran exageración", tal vez mejor que cualquier otra cosa.

Últimos consejos:

  • Se específico. Su empresa no va a adoptar una tecnología completa: adoptará un producto específico. Algunos productos siempre serán menos maduros que otros. Elija dos o tres productos DVCS conocidos y muestre cómo encajarían cada uno en su proceso de desarrollo. A los gerentes les gustan más las ideas concretas que las vagas promesas, por lo que analizar la tecnología en términos específicos los hará sentir más cómodos.

  • No es todo o nada. Cualquier proyecto real que utilice un DVCS seguirá teniendo un depósito central, por lo que los temores sobre la pérdida del control de las joyas de la corona se pueden mitigar fácilmente.

  • No es necesario renunciar a su sistema actual. Algunas herramientas, como git, pueden funcionar bien con los sistemas de control de versiones existentes, como svn. Por lo tanto, puede agregar fácilmente DVCS a su proceso de desarrollo sin renunciar a nada.

  • Empieza pequeño. A menos que esté en una empresa pequeña que solo tiene un proyecto, debería ser fácil incorporar DVCS en el proceso de solo uno o dos de sus proyectos. No tienes que saltar de cabeza primero, solo sumerge un dedo del pie.

En resumen, identifique los puntos de resistencia y enfóquelos tan claramente como pueda.

Caleb
fuente
1
El ciclo de exageración se aplica en todos los casos, excepto en algunos, degenerados, incluso cuando los medios no lo informan. Los casos en los que no es así, donde nunca hay una adopción inicial (tecnología de nacimiento) y donde el punto de desilusión llega a cero (a menudo debido a que la tecnología es reemplazada por algo completamente mejor).
Donal Fellows
2
¿Cuándo fue el "canal de desilusión" para el navegador web?
Gort the Robot
1
@StevenBurnap ¿Se promocionó el navegador en algún momento? (pregunta genuina)
dukeofgaming
1
Por otro lado, ¿el ciclo de exageración se aplica a CUALQUIER COSA? ¿Hay alguna investigación real que respalde esto? Por lo que puedo decir, el ciclo de exageración se trata casi por completo de ajustar el patrón de noticias a algo después del hecho. No le dice nada sobre el futuro, el estado actual de una innovación, su curva de cambio futuro, o incluso si debe adoptarlo o no.
philosodad
1
@WilliamPayne Reconozco que es posible que alguna comunidad descubra repentinamente una tecnología existente, y que los medios dentro de esa comunidad puedan generar bombo / zumbido siguiendo el patrón del ciclo de bombo. Sin embargo, señalaría que el cuadro en la pregunta del OP está etiquetado como "Hype Cycle for Emerging Technologies". Además, no es suficiente afirmar que tal cosa podría suceder; realmente necesita señalar ejemplos donde eso ha sucedido. Como señala philosodad, si el ciclo de exageración es real o simplemente percibido es una pregunta abierta.
Caleb
2

argumento / evidencia de una fase particular

Cualquiera que sea la fase, debe ser una que coincida con el hecho de que la tecnología está en uso profesional durante "más de 10 años" , ya que VCS TeamWare distribuido ha estado allí por más tiempo: la Guía del usuario en pdf que se menciona a continuación está fechada en julio de 2001 .

Según Wikipedia, la implementación más grande de TeamWare fue dentro del propio Sun , donde (salvo algunas excepciones) en un momento fue el único VCS utilizado, lo que hace que miles de desarrolladores utilicen la herramienta. TeamWare se ha utilizado para administrar los árboles de origen más grandes de Sun, incluidos los del sistema operativo Solaris y el sistema Java .

http://i.stack.imgur.com/J68MH.png

El artículo de Wikipedia se refiere a un mensaje de Usenix de Evan Adams, quien fue el jefe de arquitectura de TeamWare, que establece en particular:

En la primavera de 1991 decidimos implementar el proyecto TeamWare ...

TeamWare es un conjunto de herramientas de línea de comandos y GUI creadas a partir de varias bibliotecas comunes. Las bibliotecas son proporcionadas por el grupo TeamWare para uso de las aplicaciones TeamWare; No se proporcionan para un uso más general.

TeamWare es un producto de gestión de código que fomenta el desarrollo paralelo y está construido sobre SCCS. Un usuario realiza una copia (recuperación) de una jerarquía SCCS creando así una jerarquía personal. En esta jerarquía, el usuario realiza y prueba los cambios. Estos cambios se integran (devolución) en la jerarquía original. Si la jerarquía de integración contiene cambios que no están en la jerarquía del usuario, TeamWare detecta que ha habido cambios paralelos y rechaza la integración. Por lo tanto, los usuarios deben incorporar cambios en la jerarquía de integración en su propia jerarquía antes de la integración. TeamWare también incluye la utilidad filemerge, un programa gráfico de diferencias de tres vías que permite a los usuarios fusionar cambios paralelos. TeamWare rastrea los cambios en el archivo de origen (deltas de SCCS) y los cambios de nombre de archivos ...

Si está interesado, encuentre más detalles aquí:

  • "El viejo y la C" de Evan Adams
  • "Guía del usuario de Sun WorkShop TeamWare" en el sitio de Oracle / Sun - pdf julio de 2001 , html

Según mi recuerdo, CVS / SVN centralizado en ese entonces tenía la ventaja de ser capaz de ejecutarse en Windows y Linux, mientras que TeamWare (SCCS) se ha bloqueado en el sistema de archivos Solaris (en Linux se ejecuta más o menos, si uno supiera cómo hackear errores espurios de "suma de comprobación cero").

mosquito
fuente
44
Hay tecnologías de más de 10 años antes del pico de expectativas infladas. No estoy seguro de que el tiempo solo pueda posicionar una tecnología en particular en una fase.
dukeofgaming
@dukeofgaming más de 10 años es un hecho objetivo y lo afirmo . Cualquiera que sea la "fase" / "medida exagerada" subjetiva que se rellene sobre ella, el hecho tiene que estar allí
mosquito
1
Lo siento, todavía no entiendo tu punto. Si entiendo correctamente, ¿estás diciendo que ~ 10 años son un hecho objetivo, pero para qué fase?
dukeofgaming
1
@gnat: Bueno, creo que "Hype Cycle" es un gran nombre inapropiado. El Hype Cycle no se trata de bombo sino de madurez tecnológica. El bombo es solo una consecuencia de una tecnología de la que se habla mucho pero que no es lo suficientemente madura; el ciclo muestra esto pero también otros aspectos, como la adopción. Entonces, en resumen, estoy tomando el Ciclo Hype por lo que retrata la madurez del wrt en lugar de la exageración, la exageración es solo un problema menor.
CesarGon
3
@gnat: No niego el mérito de DVCS a ese respecto. Pero el modelo Hype Cycle evalúa la madurez más las expectativas juntas; una tecnología puede ser bastante madura, pero si las expectativas al respecto son extremadamente altas, aún puede ser decepcionante (de ahí la desilusión). En mi opinión, las expectativas sobre DVCS han sido mucho más altas de lo que ha entregado. Además, DVCS puede haberse utilizado en proyectos de Solaris y Java, pero eso no significa que su madurez y expectativas estén equilibradas. Por lo tanto, una gran exageración.
CesarGon
1

Mi respuesta:

Creo que la respuesta se encuentra en algún lugar entre "Internet TV" y "Cloud Computing" en el hombro ascendente del "Pico de las expectativas infladas" (aunque creo que ambos han avanzado un poco rápidamente en los últimos años).

Naturaleza del ciclo de bombo:

Según tengo entendido, la progresión a través del ciclo de bombo se caracteriza por una conciencia evolutiva sobre los pros y los contras de una tecnología en particular, más que por cualquier medida objetiva de "madurez" (lo que sea que eso signifique).

Antes de que hayamos acumulado un conjunto suficientemente diverso de experiencias para construir opiniones equilibradas (e independientes ), la dinámica de masas (naturalmente) prevalece, con opiniones altamente correlacionadas con poca diversidad, sutileza o profundidad de análisis.

Esto es tan cierto en el "Canal de la desilusión" como en el "Pico de las expectativas infladas"

Si la comunidad produjera una amplia y diversa gama de opiniones diferentes, con un análisis en profundidad sobre dónde y cuándo es apropiado implementar DVCS y dónde y cuándo no, entonces podemos inferir que estamos en la "Meseta de la Productividad" (O, al menos, un poco más arriba de la "Pendiente de la Iluminación").

Si, por otro lado, el discurso se centra en la superioridad (o no) de una tecnología sin tener en cuenta las caídas y pliegues del panorama competitivo en el que se encuentra, entonces podríamos inferir que estamos en el "Pico de Expectativas infladas "o el" valle de la desilusión ". Incluso podríamos estar en ambas fases al mismo tiempo, si la comunidad está dividida en campamentos por una guerra de llamas.

:-)

Evaluación de DVCS según estos criterios:

A partir del análisis relativamente superficial que he visto en el discurso hasta ahora, y la relativa ausencia de comentarios negativos, estimaría que actualmente estamos subiendo el "Pico de las expectativas infladas", con preguntas (como esta) que indican que hay Hay algunos que están preparando la pendiente hacia abajo en el otro lado.

Creo que un fuerte indicador de la madurez de la tecnología DVCS (desde el punto de vista corporativo) será cuando el debate pase de preguntar simplemente "¿Por qué DVCS?" a "¿Cómo podemos estructurar mejor nuestro flujo de trabajo y procesos en torno a DVCS para maximizar el beneficio para la organización?".

Por lo que he visto, todavía no estamos todos allí. (Aunque algunos de nuestros compatriotas más sofisticados están liderando el camino)

El papel del ciclo Hype en la toma de decisiones:

El modelo "Hype Cycle" es un modelo de sesgo conductual y nos ayuda a comprender nuestro propio estado mental. Si podemos determinar que una tecnología es promovida por otros, entonces eso puede afectar nuestra propia posición mental y (a riesgo de pensar dos veces) es posible que necesitemos compensar en consecuencia y obligarnos a comportarnos racionalmente al elegir nuestros criterios de selección.

Criteria de selección:

No hace falta decir que las opciones de criterios de selección dependen extremadamente del contexto.

Personalmente, haría (como una especie de ejercicio de lluvia de ideas) un breve análisis FODA (15 minutos) de cada opción que esté considerando, junto con (seriamente) un análisis PEST de la situación para garantizar que brinde una visión más amplia (no tecnológica) factores en tu análisis.

FODA para VCS distribuido

Fortalezas:

  • Flexibilidad: más libertad para elegir diferentes flujos de trabajo.
  • Mejor rendimiento en conexiones de red de bajo ancho de banda / alta latencia: mejor para equipos distribuidos y trabajadores externos.
  • Funcionalidad de fusión más sofisticada, que le permite bifurcar con más frecuencia. (No estoy seguro de que esto sea algo bueno).
  • El código fuente está "respaldado" en cada máquina de desarrolladores. (bastante falso, ya que podría interferir con la planificación adecuada de recuperación ante desastres)

Debilidades:

  • Flexibilidad: debido a que tenemos más libertad para elegir diferentes flujos de trabajo, necesitamos realizar un trabajo adicional para definir qué flujo de trabajo estamos utilizando y aplicarlo.
  • Complejidad y dificultad conceptual (especialmente para miembros del equipo que no son desarrolladores de software).

Oportunidades:

  • ¿Quizás se puede utilizar la flexibilidad para diseñar un flujo de trabajo que se adapte mejor a las necesidades del negocio?

Amenazas:

  • ¿Quizás pasaremos tanto tiempo rediseñando nuestro flujo de trabajo que perderemos el foco en nuestro producto principal?
  • Puede ser difícil lograr que algunas personas utilicen incluso herramientas simples, especialmente si no creen que sean necesarias o no estén motivadas.

FODA para VCS centralizado

Fortalezas:

  • Proporciona un canal de comunicación implícito en banda para la organización y el proceso empresarial.
  • Restringe los flujos de trabajo posibles a un subconjunto (en muchos casos razonable).
  • Facilita la configuración de CI y otras herramientas de automatización de desarrollo.
  • (SVN específico) Admite grandes repositorios.
  • (Específico de SVN) Muy estable, utilizado por muchas organizaciones grandes y conservadoras.
  • ¿Políticamente más aceptable en una organización de mando y control de arriba hacia abajo?

Debilidades:

  • Inflexible.
  • Bajo rendimiento sobre conexiones de bajo ancho de banda / alta latencia, lo que dificulta su uso para equipos distribuidos y trabajadores fuera del sitio (especialmente si el repositorio se hace grande)

Oportunidades:

  • ¿Quizás podamos usar la naturaleza monolítica del repositorio para ayudar a los desarrolladores a navegar por el producto y reutilizar más el código del otro?

Amenazas:

  • Si el proyecto de repente se vuelve muy importante y necesitamos traer desarrolladores adicionales que trabajen en otros sitios, ¿pueden trabajar efectivamente con un repositorio SVN alojado (para ellos) fuera del sitio?
  • Si el conjunto de desarrolladores crece tanto que coordinarlos se vuelve difícil, ¿el repositorio centralizado único se convertirá en un cuello de botella? (¿Podemos evitar esto de otra manera?)

Conclusión:

Qué VCS usar depende de las circunstancias individuales. Para muchas de las situaciones en las que he trabajado, un DVCS con un flujo de trabajo centralizado hubiera funcionado bien, pero habría tenido que justificar el tiempo y el esfuerzo para desarrollar un mecanismo para apoyar y hacer cumplir el flujo de trabajo, lo que hubiera sido (aún es difícil.

En última instancia, creo que la discusión debería centrarse en la pregunta: ¿Qué flujo de trabajo se adapta mejor a nuestro negocio? La mejor herramienta para usar debe seguir naturalmente la respuesta a esa pregunta.

William Payne
fuente
Para responder a su pregunta en el otro comentario: aplicación empresarial
dukeofgaming