git - usados - Sistemas de control de versiones distribuidas y Enterprise: ¿una buena combinación?

¿qué es un sistema control de versiones centralizado? (9)

Absolutamente un modelo de fuente distribuida puede tener sentido en una empresa, pero depende de la estructura de sus equipos.

El control de fuente distribuido le brinda la flexibilidad de crear sus propios flujos de trabajo.

Imagine, si lo desea, un equipo más grande, dentro del cual hay equipos más pequeños que trabajan en sucursales de funciones separadas.

Todos estos equipos pueden tener sus propios repositorios centrales, con sus propios mecanismos de control de automatización / control de compilación.
Pueden trabajar en cualquier lugar y respaldar su trabajo local siempre que lo deseen.
Luego pueden elegir qué comprobaciones desean compartir entre los grupos.
Pueden tener un único integrador individual, trabajando en su propia máquina, realizando fusión, sin afectar a los demás.

Estas son cosas que se podrían lograr con un servidor centralizado tradicional, pero como señala @Brook, el modelo centralizado tiene que escalar, mientras que el modelo distribuido ya está fragmentado, por lo que no (o al menos, menos) necesita escalar verticalmente los servidores.

Puedo ver por qué los sistemas de control de fuente distribuida (DVCS, como Mercurial) tienen sentido para los proyectos de código abierto.

¿Pero tienen sentido para una empresa? (a través de un sistema de control de fuente centralizado como TFS)

¿Qué características de un DVCS lo hacen mejor o peor para una empresa con muchos desarrolladores? (sobre un sistema centralizado)

Acabo de presentar un DVCS (Git en este caso) en una gran empresa bancaria, donde Perforce, SVN o ClearCase eran las opciones de VCS centralizadas:
Ya sabía de los desafíos (ver mi respuesta anterior " ¿Podemos finalmente pasar a DVCS en software corporativo? ¿SVN sigue siendo un ''imprescindible'' para el desarrollo? ")

Me han desafiado en tres frentes:

centralización : si bien el modelo descentralizado tiene sus ventajas (y permite compromisos privados o trabajar sin la red al tiempo que tiene acceso al historial completo ), todavía debe haber un conjunto claro de repositorios centralizados , que actúen como referencia principal para todos los desarrolladores.
autenticación : un DVCS le permite "firmar" (comprometer) su código como ... casi cualquiera (autor " foo ", correo electrónico " [email protected] ").
Puedes hacer una git config user.name foo , o git config user.name whateverNameIFeelToHave , y tener todas tus confirmaciones con nombre falso en ella.
Eso no se combina bien con el único referencial de usuario centralizado "Active Directory" utilizado por las grandes empresas.
Autorización : de forma predeterminada, puede clonar, enviar o extraer de cualquier repositorio y modificar cualquier rama o directorio.
Para proyectos delicados, eso puede ser un problema de bloqueo (el mundo de la banca suele ser muy protector de algunos algoritmos de precios o cuarteles, 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 que cualquier repositorio tenga que ser accesible para todos los usuarios.
La copia de seguridad se ha estado ocupando (incremental todos los días, completo cada semana).
DRP (Plan de recuperación de desastres) se ha implementado, 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 del tipo de referencia o herramienta que necesite (DVCS o Nexus repo, o el programador principal de Hudson, o ...): cualquier herramienta que pueda ser crítica para una versión en producción debe instalarse en los 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 desarrollo extraterritorial),
  - y útil para cuentas genéricas que el administrador de Active Directory no desea 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 propietaria de la clave privada
- Basado en https, con 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 de git en esos repositorios.
  Git lo ofrece con su protocolo http inteligente , que permite no solo pull (leer) a través de http, sino también push (escribir) a través de http.

La parte de autenticación también se refuerza en el nivel de Git mediante un enlace post-receive que garantiza que al menos una de las confirmaciones que envía a un repositorio tiene un "nombre de committer" 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 impulso que desee realizar a un repositorio central será rechazado.

autorización : ambas configuraciones previas (ssh o https) están conectadas para llamar al mismo conjunto de script perl, llamado gitolite , con los siguientes parámetros:
- el nombre de usuario real detectado por esos dos protocolos
- el comando git (clonar, empujar o tirar) que el usuario quiere hacer

La secuencia de comandos perl de gitolite analizará un archivo de texto simple donde se han establecido las autorizaciones (acceso de lectura / escritura para un repositorio de todo, 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 es rechazado.

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 una base de usuarios única.

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

intercambio de datos entre múltiples sitios : mientras todos esos usuarios están autenticados a través del mismo Directorio Activo, 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 de manera eficiente entre los equipos distribuidos.
replicación en todos los entornos : una configuración que se encarga de la autenticación / autorización permite clonar esos repositorios en otros servidores dedicados (para pruebas de integración, pruebas UAT, preproducción y predespliegue)
Automatización de procesos : 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 pruebas unitarias con las técnicas de "guardian commits" y otros usos inteligentes: consulte " ¿Cuál es el uso más inteligente del repositorio fuente? ¿Alguna vez has visto? ".
En resumen, puede pasar a un segundo repositorio local a cargo de:
- varias tareas (prueba unitaria o análisis estático del código)
- retrocediendo al repositorio principal si esas tareas son exitosas
- mientras todavía está trabajando en el primer repositorio sin tener que esperar el resultado de esas tareas.

características de asesino : cualquier DVCS viene con aquellos, el principal se está fusionando (¿alguna vez intentó hacer un flujo de trabajo de fusión complejo con SVN? ¿O fusionar toscamente 6000 archivos con ClearCase?).
Eso solo (fusión) significa que realmente se puede aprovechar la branching , mientras se puede combinar todo el tiempo el código con otra línea de desarrollo "principal", porque lo haría:
- primero localmente dentro de su propio repositorio, sin molestar a nadie
- luego en el servidor remoto, presionando el resultado de esa fusión en el repositorio central.

Al menos con tfs 2013, usted tiene la capacidad de trabajar desconectado con espacios de trabajo locales. Distribuido vs centralizado es definido por la empresa y depende de las necesidades y requisitos de los proyectos en desarrollo.

Para los proyectos empresariales, la capacidad de conectar el flujo de trabajo y los documentos a los cambios del código puede ser crucial para conectar los requisitos del negocio y los elementos de orden superior a los cambios de código específicos que abordan un cambio específico, error o adición de funciones.

Esta conexión entre el flujo de trabajo y el repositorio de código separa TFS de las soluciones de solo repositorio de código. Para algunos lugares donde se requiere un orden superior de auditoría de proyectos, solo un producto como TFS satisfaría más los requisitos de auditoría del proyecto.

Puede encontrar una descripción general del proceso de administración del ciclo de vida de la aplicación aquí.

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx

DSCS tiene una historia mejor (en general) que los sistemas centralizados para redes fuera de línea o lentas. Tienden a ser más rápidos, lo que es realmente notorio para los desarrolladores (que usan TDD) que hacen muchos check-ins.

Los sistemas centralizados son algo más fáciles de comprender inicialmente y podrían ser una mejor opción para los desarrolladores menos experimentados. Los DVCS le permiten crear muchas mini-ramas y aislar nuevas características mientras sigue haciendo check-re-color rojo en el estilo de codificación verde. De nuevo, esto es muy poderoso, pero solo es atractivo para los equipos de desarrollo bastante entendidos.

Tener un único repositorio central para compatibilidad con bloqueos exclusivos tiene sentido si se trata de archivos que no se pueden combinar como activos digitales y documentos que no son de texto (archivos PDF y Word, etc.) ya que le impide meterse en un lío y fusionarse manualmente.

No creo que el número de desarrolladores o el tamaño de la base de código juegue tanto, se han demostrado ambos sistemas para admitir grandes árboles fuente y números de committers. Sin embargo, para grandes bases de código y proyectos, DVCS brinda mucha flexibilidad para crear rápidamente sucursales remotas descentralizadas. Puede hacer esto con sistemas centralizados, pero debe ser más deliberado, bueno y malo.

En resumen, hay algunos aspectos técnicos a tener en cuenta, pero también debe pensar en la madurez de su equipo y su proceso actual en torno a SCCS.

El mayor problema que enfrentamos con Git en la configuración empresarial es la falta de control de acceso de lectura basado en rutas. Es inherente a la arquitectura de Git (y supongo que a la mayoría de los DVCS) que si tienes acceso de lectura al repositorio lo tienes todo. Pero a veces un proyecto requerirá un pago escaso (es decir, usted quiere que la versión controle los datos confidenciales cerca de la fuente, o si desea darle a un tercero una vista selectiva de parte del proyecto).

Fuera de la caja, Git no ofrece permisos; tienes ganchos para escribir los tuyos.

La mayoría de los gestores de repo populares Github Enterprise, Gitlab, Bitbucket proporcionan restricciones de escritura basadas en sucursales. Gitolite permite ser más fino, proporcionando restricciones de escritura basadas en ruta (y más).

El único administrador de repos que he escuchado sobre el acceso de lectura compatible es Perforce Helix, que vuelve a implementar el protocolo git en la parte superior del backend forzado, pero no tengo experiencia práctica con él. Es prometedor, pero me preocuparía cuán compatible es con el git "simple".

Mejor sincronización en ubicaciones remotas / desconectadas.

Nuestro equipo utilizó TFS durante aproximadamente 3 años antes de cambiar a Mercurial. El soporte de fusión / ramificación de HG es mucho mejor que TFS. Esto se debe a que un DVCS se basa en la fusión indolora.

Para agregar a los otros comentarios, me gustaría observar que no hay ninguna razón por la que no pueda tener un repositorio central corporativo . Técnicamente es solo otro repositorio, pero es a partir del cual envías la producción. He usado una u otra forma de VCS durante más de 30 años y puedo decir que cambiar a Mercurial fue como un chico de la ciudad que respira aire puro en el campo por primera vez.

Para mí, lo más grande que ofrecen es Speed. Son órdenes de magnitud más rápidos para las operaciones más comunes que el control de fuente centralizado.

Trabajar desconectado es también una gran ventaja.