¿Cómo se usa DVCS en equipos grandes?

Recientemente comencé a ingresar a Git en un proyecto personal, y puedo ver cómo un DVCS podría beneficiarnos en el trabajo (que es una gran empresa de software empresarial, que actualmente ejecuta Perforce). El trabajo de características en mi equipo, por ejemplo, consiste principalmente en desarrolladores que crean sus propias sucursales; a veces estos se comparten entre pequeños equipos de desarrolladores. Creo que sería más eficiente en esta instancia usar un DVCS.

Sin embargo, en el caso más general, me interesaría saber de personas que usan un DVCS en el trabajo, en equipos medianos y grandes.

  1. ¿Cómo manejas las fusiones de N vías? ¿Es esto incluso un escenario común? Mercurial solo admite fusiones en N forma haciendo fusiones bidireccionales (N-1) (y lee que esta es la solución preferida en otros DVCS), lo que suena como un process muy laborioso incluso para N relativamente pequeño.
  2. ¿Usas un solo repository central autorizado, o es realmente P2P?
  3. ¿Los desarrolladores a menudo empujan y extraen el código entre sí, o todo pasa por el repository central?

Mi equipo de mi empleador anterior usó Git, y funcionó bien para nosotros. No éramos tan grandes (¿tal vez 16 o así, con quizás 8 committers realmente activos?), Pero tengo respuestas a sus preguntas:

  1. Las fusiones de N-Way no son terriblemente comunes. Se nos ocurrieron algunas convenciones sobre nombres de sucursales que nos permitieron escribir scripts que facilitaron el process de "liberación de ingeniería" (utilizo comillas de susto porque no teníamos un ingeniero de versiones), y las personas crearían twigs de características privadas, pero rara vez tuvo un problema con la fusión de más de dos twigs (ver el siguiente).
  2. (y # 3). Teníamos un repository central en un server de desarrollo por tres razones: (a) La máquina de desarrollo tenía un RAID5 (más tolerante a fallas) y copys de security nocturnas (las estaciones de trabajo dev no eran todas las noches), (b) las versiones de producción se creaban en el server de desarrollo. y (c) tener un repository central simplificado de scripting. Como resultado, las fusiones en N simplemente nunca sucedieron. Lo más parecido que tuvimos a N-way fue cuando alguien se fusionó lateralmente y luego se fusionó verticalmente.

Git fue realmente grandioso para nosotros debido a su alto grado de flexibilidad; sin embargo, tuvimos que establecer algunas convenciones (nombres de twigs y tags, ubicaciones de repositorys, scripts, etc., process) o podría haber sido un poco caótico. Una vez que configuramos las convenciones, la flexibilidad que teníamos era simplemente fantástica.

Actualización: nuestras convenciones básicamente fueron así:

  • un directory en nuestro server NFS que albergaba todos los repositorys centrales
  • teníamos varios proyectos que compartían componentes, así que los distribuimos en bibliotecas, esencialmente, con sus propios repositorys, y los proyectos entregables simplemente los incluyeron como submodules de git.
  • había cadenas de versiones y nombres de versiones impuestas desde arriba, así que solo usamos variantes de esas como nombres de sucursales
  • de manera similar, para las tags, siguieron los nombres de lanzamiento dictados por el process
  • los proyectos entregables contenían un file de properties que leí en los guiones del intérprete de commands, y eso me permitió escribir un solo guión para gestionar el process de lanzamiento de todos los proyectos, aunque cada uno tenía pequeñas variaciones en el process; las variaciones se tuvieron en count en esos files de properties
  • Escribí scripts que rebuildían un package entregable desde cualquier label
  • El uso de git nos permitió controlar el acceso usando PAM y / o permissions de usuario normales (ssh, etc.)
  • Hubo otras convenciones que son más difíciles de poner en una list con viñetas, como cuando las fusiones deberían suceder. Realmente, yo y otro hombre somos una especie de "git gurus" internos, y ayudamos a todos a descubrir cómo usar las twigs y cuándo fusionarse.
  • hacer que la gente se comprometa en trozos pequeños y no arrojar bombas-dif en la twig principal fue un desafío. Un hombre dejó caer aproximadamente dos semanas de trabajo en un compromiso, y finalmente tuvimos que resolverlo todo. Una gran pérdida de time y frustrante para todos.
  • comentarios informativos y detallados para ir con commits

Hubo otras cosas que aprendes a medida que tu equipo adquiere experiencia y aprende a trabajar el uno con el otro, pero esto fue suficiente para comenzar.

Actualización : cualquiera que siga estas cosas por ahora ya lo sabe, pero Vincent Dreissen ha escrito una versión sólida y bastante exhaustiva (pero no exhaustiva) sobre la ramificación y la ingeniería de lanzamiento usando Git . Recomiendo utilizar su process como punto de partida, por dos razones:

  • muchos equipos lo hacen de esta manera o utilizan alguna variante cercana (incluidos Linux, Git y muchos otros equipos de proyectos OSS), lo que significa que este método ha sido probado y modificado para ser exitoso en la mayoría de los casos. Es muy poco probable que enfrente un problema que no se haya enfrentado y resuelto dentro de las limitaciones de este model.
  • debido a lo anterior, casi cualquier ingeniero con experiencia en Git entenderá lo que está sucediendo. No tendrá que escribir documentation detallada sobre la naturaleza fundamental de su process de publicación; solo tendrá que documentar cosas específicas solo para su proyecto o equipo.

Esquema de flujo de trabajo de whygitisbetterthanx :

alt git work-flow con el administrador de integración http://whygitisbetterthanx.com/images/workflow-b.png

Para escalar esto hasta aún más desarrolladores, simplemente agrega otra capa de "tenientes de confianza" entre el administrador de integración y los desarrolladores.

He estado trabajando durante varios años con el equipo de comstackdores Glasgow Haskell usando Darcs . Recientemente (varios meses) comencé a usar git para mi propia copy del repository, tanto para el performance como para mejorar mi educación.

  1. ¿Cómo manejas las fusiones de N vías?

    No hay fusiones de N vías. Cada desarrollador origina una secuencia de parches, y los flujos se fusionan uno a la vez en cada repository. Entonces, si N desarrolladores hacen cambios simultáneamente, se fusionan en pares.

  2. ¿Usas un único repository central autorizado?

    Absolutamente. Es la única forma de saber qué es GHC y qué no.

  3. ¿Los desarrolladores a menudo empujan y extraen el código entre sí, o todo pasa por el repository central?

    Creo que depende de los desarrolladores y del VCS que estés usando. En el proyecto de GHC casi todos los tirones y empujones que veo pasan por el depósito central. Pero hay un portero de peso pesado (autoadministrado) que impulsa al repository central, y si un colega tiene una solución de error que necesito ahora , lo sacaré directamente de su repository. Con Darcs es muy fácil extraer solo un parche (en lugar de todo el estado como en git), y sé que mis compañeros deveopers, que tienen más experiencia con los darcs, usan esta característica mucho más que yo — y les gusta mucho.

    Con git , cuando estoy trabajando estrechamente con otro desarrollador, con frecuencia crearé una nueva twig con el único propósito de compartirla con otra persona. Esa twig nunca llegará al repository central.

El bastante famoso "Tech Talk: Linus Torvalds en git" explica cómo se usa para Linux (casi tan grande como el equipo que se me ocurre)

Si recuerdo correctamente, su uso se asemeja a una cadena de command militar: cada module tiene un mantenedor, que maneja las requestes de extracción de los desarrolladores, luego hay algunas personas "más confiables" que tratan de extraer datos de los mantenedores de los modules en el repository oficial de git kernel.org.

"Linux: gestión de Kernel Source con 'git'" también lo explica, aunque nuevamente no es una explicación concisa.

Aquí hay un ejemplo (de ninguna manera un "universal")

Tenemos VCS central (ClearCase o SubVersion, dependiendo de los diferentes proyectos), y los estamos utilizando para esfuerzos de desarrollo "oficiales" (desarrollo, parches, arreglos), donde el número de sucursales es limitado y está bien identificado.

Sin embargo, para la refactorización de desarrollos que involucran una gran cantidad de estados intermedios, donde nada funciona, y donde muchos desarrolladores necesitan tener su propia twig o twigs basadas en actividades, algunos repositorys Git se configuran entre esos desarrolladores, de forma P2P.
Una vez que el trabajo alcanza algún tipo de estabilidad 0.1, y las fusiones se networkingucen, se reimporta en el VCS, donde el trabajo puede continuar de una manera central y "orderada".

Dado que Git en Windows funciona bien (MSysGit), logramos pequeños desarrollos iniciales hechos de manera rápida por ese lado.

Todavía estamos evaluando a Git para un desarrollo de proyecto a gran escala.

Probablemente sea mejor investigar cómo funcionan los desarrolladores del kernel de Linux. Tienen un flujo de trabajo bastante complejo donde los cambios se envían desde muchas fonts, y luego los desarrolladores de confianza para cada subsistema (llamados tenientes) incorporan los cambios, y cuando están contentos los envían a Linus, quien eventualmente los arrastra a su tree o los rechaza Por supuesto, es más complejo que eso, pero eso es una descripción general.