Sistemas de Control de Versiones Distribuidas y la Empresa - una buena mezcla? [cerrado]

Acabo de introducir un DVCS (Git en este caso) en una gran compañía bancaria, donde Perforce, SVN o ClearCase eran los VCS centralizados de opciones:
Ya sabía de los desafíos (ver mi respuesta anterior " ¿Podemos finalmente pasar a DVCS en Software Corporativo? ¿Es SVN todavía un 'must have' para el desarrollo?")

He sido desafiado en tres frentes: {[12]]}

• Centralización: mientras que el modelo descentralizado tiene sus méritos (y permite commits privados o trabajando sin la red mientras se tiene acceso al historial completo ), todavía necesita haber un conjunto claro de repos centralizados , que actúen como la referencia principal para todos los desarrolladores.

• Autenticación : un DVCS le permite "cerrar sesión" (confirmar) su código como... casi cualquier persona (autor " foo", correo electrónico " [email protected]").
  Puedes hacer un git config user.name foo, o git config user.name whateverNameIFeelToHave, y tener todas tus confirmaciones con nombre falso en él.
  Que no se mezclan bien con el referencial de usuario único centralizado de "Active Directory" utilizado por grandes empresas.

• Authorization: por defecto, puede clonar, empujar o tirar a cualquier repositorio, y modificar cualquier rama, o cualquier directorio.
  Para los proyectos sensibles, que puede ser un problema de bloqueo (el mundo bancario suele ser muy protector de algunos algoritmos de precios o quants, que requieren un estricto acceso de lectura / escritura para un número muy limitado de personas)

La respuesta (para una configuración de Git) fue:

• centralización: se ha configurado un servidor único para cualquier repositorio que tenga que ser accesible por todos los usuarios.
  La copia de seguridad se ha estado encargando (incremental todos los días, completa todas las semanas).
  Se ha implementado DRP (Disaster Recovery Plan), con un segundo servidor en otro sitio, y con replicación de datos en tiempo real a través de SRDF.
  Esta configuración en sí misma es independiente de la tipo de referencial o herramienta que necesita (DVCS, o Nexus repo, o main Hudson scheduler, o...): cualquier herramienta que pueda ser crítica para una versión en producción debe instalarse en servidores con copia de seguridad y DR.

.

• autenticación : solo dos protocolos permiten a los usuarios acceder a los repositorios principales:
  • basado en ssh, con clave pública / privada:
    • útil para usuarios externos a la organización (como el desarrollo off-shore),
    • y útil para cuentas genéricas que Active Directory manager no quiere crear (porque sería una cuenta "anónima"): una persona real tiene que ser responsable de esa cuenta genérica, y esa sería la que posee la clave privada
  • basado en https, con un Apache autenticando a los usuarios a través de una configuración LDAP: de esa manera, se debe proporcionar un inicio de sesión real para cualquier operación git en esos repositorios.
    Git lo ofrece con su protocolo http inteligente , permitiendo no solo pull (leer) a través de http, pero también push (escribir) a través de http.

La parte de autenticación también está reforzada a nivel de Git por un post-receive hook que se asegura de que al menos uno de los commits que está enviando a un repositorio tenga un "committer name" igual al nombre de usuario detectado a través del protocolo shh o http.
En otras palabras, necesita configurar su git config user.name correctamente, o cualquier empuje que desee hacer a un repositorio central será rechazar.

.

• authorization : ambas configuraciones anteriores (ssh o https) están cableadas para llamar al mismo conjunto de script perl, llamado gitolita, con parámetros as:
  • el nombre de usuario real detectado por esos dos protocolos
  • el comando git (clonar, empujar o tirar) que el usuario quiere hacer

El script de gitolite perl analizará un archivo de texto simple donde las autorizaciones (lectura / escritura se ha establecido el acceso para un repositorio all, o para ramas dentro de un repositorio dado, o incluso para directorios dentro de un repositorio).
Si el nivel de acceso requerido por el comando git no coincide con la ACL definida en ese archivo, el comando se rechaza.

Lo anterior describe lo que necesitaba implementar para una configuración de Git, pero lo más importante es que enumera los principales problemas que deben abordarse para que una configuración de DVCS tenga sentido en una gran corporación con un usuario único basar.

Entonces, y solo entonces, un DVCS (Git, Mercurial,...) puede agregar valores debido a:

• Intercambio de datos entre múltiples sitios: si bien todos esos usuarios se autentican a través del mismo Active Directory, pueden ubicarse en todo el mundo (las empresas para las que he trabajado tienen desarrollos generalmente entre equipos en dos o tres países). Un DVCS se hace naturalmente para intercambiar datos eficientemente entre ésos distribuidos equipo.

• Replicación en entornos: una configuración que se ocupa de la autenticación/autorización permite clonar esos repositorios en otros servidores dedicados (para pruebas de integración, pruebas UAT, preproducción y pre-despliegue)

• Process automation: la facilidad con la que puede clonar un repositorio también se puede usar localmente en la estación de trabajo de un usuario, para fines de prueba unitaria con las técnicas de "confirmaciones guardadas" y otros usos inteligentes: ver " ¿Cuál es el uso más inteligente del repositorio de código fuente que haya visto?".
  En resumen, puede enviar a un segundo repositorio local a cargo de:

  • varias tareas (prueba unitaria o análisis estático del código)
  • volver al repositorio principal si esas tareas tienen éxito
  • mientras que todavía está trabajando en el primer repositorio sin tener que esperar el resultado de esas tareas.

.

• características del asesino: Cualquier DVCS viene con ellos, el principal es merging (¿alguna vez intentó hacer un flujo de trabajo de fusión complejo con SVN? ¿O sloooowly fusionar 6000 archivos con ClearCase?).
  Eso solo (fusionar) significa que realmente puede aprovechar ramificando , mientras que puede en todo momento fusionar su código a otra línea "principal" de desarrollo, porque lo haría:
  • primero localmente dentro de su propio repositorio, sin molestar a nadie
  • luego en el servidor remoto, empujando el resultado de esa fusión en el repositorio central.