Cumplimiento en la administración de DVCS en un contexto empresarial, ¿qué esperar de una transición desde un CVCS (Perforce)?

Question

Trabajo en una gran empresa multinacional como ingeniero de software y actualmente estoy manteniendo una conversación muy agradable con TI y otros desarrolladores con respecto a la adopción de un DVCS (Mercurial y/o Git).

Una de las cuestiones planteadas por TI fue el cumplimiento y la propiedad intelectual (por cierto,Forzosamente habla en voz alta sobre esto.y en relación con Git). Me parece que TI tiene la impresión de que debido a que Mercurial/Git se distribuyen, tener repositorios en cada máquina de desarrollador es un escenario fuera de control y tendrían que auditar cada repositorio.

Otra cosa que creo que es una preocupación para TI es el hecho de que ahora tenemos "100" repositorios en lugar de "10" enormes. Tengo la impresión de que piensan que su esfuerzo administrativo para mantenerlos/monitorearlos crecería "diez". doblar". Creo que el software de gestión de repositorios (Rhodecode, Atlassian Stash) sería el primer paso para brindar control de acceso y trazabilidad.

Mis preguntas son:

1. ¿Es el software de gestión de repositorios suficiente para una empresa de este tamaño (digamos ~2000 desarrolladores y ~50 depósitos de Perforce en ~10 servidores)?, para cumplir (y cumplir con otros requisitos empresariales).

2. ¿Qué abarca exactamente este requisito de "cumplimiento"? ¿Hay alguna referencia que pueda dar (por ejemplo, un estándar IEEE o algo así)?

Mi empresa ha utilizado Perforce durante aproximadamente 10 años.

Answer 1

En realidad, no hay muchos cambios cuando se cambia a un DVCS. La gran diferencia es que la copia del código fuente en la estación de trabajo de cada desarrollador ahora también es su propio repositorio.

Dudo que haya muchas razones para que TI se preocupe por esto. El hecho de que git y mercurial se distribuyan no significa que vaya a implementar/entregar directamente desde el escritorio de algún desarrollador. Todavía es posible (y casi con certeza necesario) continuar usando algunos repositorios centrales en los que todos verifican, para realizar pruebas, control de calidad y eventual lanzamiento.

Ya sea que TI esté monitoreando el código fuente en las estaciones de trabajo de los desarrolladores o no, nada cambia realmente. Aún obtendrás el historial de cambios en los repositorios centrales tan pronto como se envíen, que es lo que sospecho que realmente les preocupa.

Lo que tuganarDesde el punto de vista de TI, no se accede a los repositorios centrales cada pocos minutos (¡o segundos!) cada vez que los desarrolladores se comprometen. Los desarrolladores pueden terminar de trabajar en algo y luego subirlo solo cuando esté listo, pero aún tener control completo de la versión en su estación de trabajo sin tener que conectarse a la red casi tanto.

Finalmente, necesita tener una conversación más detallada con TI sobre la naturaleza exacta de los problemas de cumplimiento de los que están hablando. Esto podría ser cualquier cosa, desde la gestión de la propiedad intelectual, ISO 9000 o algunas leyes/regulaciones gubernamentales.

(A todos: siéntanse libres de mejorar esta respuesta; esta esnomi área de especialización...)