Git submodules

Durante la preparación de la migración de SVN a GIT (Ver Migrando de svn a git) me encontré con  que en varios proyectos habían varios trunks. El árbol de directorios era algo así:

Proyecto
├── tags
└── trunk
          └── test
                    ├── branches
                    ├── tags
                    └── trunk

Ignorando si esto es o no una buena práctica, probé de que manera hacer lo mismo utilizando GIT, lo que me llevo a probar git submodules.

Aprovechando que GitBlit tiene soporte nativo para los submodules, armé lo siguiente:

Armando los repositorios

En primer lugar, cree diferentes repositorios en GitBlit utilizando el separador / para definir la pertenencia al mismo proyecto. 

Después de crear varios repositorios, la estructura me quedó de esta manera:

Los repositorios "A New Module" y " The New Hope" serían los diferentes componentes de nuestro proyecto, y en "Main Project" estaría el árbol completo.

Armando la estructura

Despues de hacer un git clone del repositorio MainProject, agregué los submodulos mediante los siguientes comandos:

1. git submodule add ssh://cmarquez@git.ascentio.com.ar:29418/A-New-Project/ANewModule.git ANewModule Para agregar ANewModule
2. git submodule add ssh://cmarquez@git.ascentio.com.ar:29418/A-New-Project/TheNewHope.git TheNewHope Para agregar TheNewHope

La estructura de carpetas va quedando de la siguiente manera:

Si hacemos un GitStatus, podemos ver que se generó un archivo .gitmodules

Si comiteamos y pusheamos al servidor, vamos a poder ver lo siguiente a través de la interfaz web:

Ahi podemos ver que las carpetas hacen referencia a los otros repositorios. De esta manera, podemos trabajar directamente en un modulo o en la carpeta que contiene todos los modulos, cada uno con un ciclo de evolución diferente.

Migrando de SVN a GIT

Como muchos de ustedes sabrán, cambiar el sistema de control de versiones en una empresa es un tema sensible, como lo es sugerir un nuevo lenguaje de programación, o la implementación de una nueva metodología.
En este post quiero comentar como hice para migrar de subversion (svn) a git en la empresa en la que estoy trabajando actualmente, de manera que mi experiencia les sirva
En primer lugar, tratamos de usar git-svn, pero después de un par de pruebas descubrimos que por detrás era svn el que hacia todo y lo dejamos de usar.
Para poder arrancar con el desarrollo del proyecto, empezamos a trabajar en un repositorio git alojado en gitlab, que permite tener repos privados. En nuestro servidor de integracion continua (jenkins) solamente usabamos SVN ya que era el sistema oficial de la empresa. El merge de git a svn lo haciamos manualmente y no había riesgos de perdida de código porque nadie trabajaba sobre el repo svn.
Ademas de un repositorio git, quería que la migración incluya algunas mejoras:

• Autenticación con el servidor LDAP: el servidor svn no estaba sincronizado con ldap, por lo que teníamos contraseñas diferentes al correo, etc. 
• Soporte claves SSH
• Interfaz web: En svn tampoco teníamos una interfaz web en donde analizar el repo. Me interesaba tener algo al estilo github.

Después de un poco de investigación, decidí implementar gitblit, que ya incluía varias de estas mejoras.

Arquitectura:

La arquitectura que armé es la que se puede ver en la imagen. El servidor LDAP permite la autenticacion y autorizacion de los usuarios.
De esta manera, si necesitamos que el usuario cmarquez sea administrador de gitblit, solamente tenemos que agregar a dicho usuario al grupo que definamos.
Jenkins es nuestro servidor de integración continua, y solo necesita permiso de lectura del repositorio git. También autentica con LDAP.

Gitblit:
Para tener gitblit en produccion, hice los siguientes pasos:

1. Instalacion: es bastante sencilla; solamente hay que bajar un zip de internet y ejecutar el archivo JAR que esta adentro.
2. Configuracion y pruebas: tambien es sencilla, PERO se complica a la hora de utilizar LDAP ya que no hay mucha información de logging/debug disponible. (en sintesis, no sabes porqué no anda cuando tenes un error) TIP: Wireshark y filtro para LDAP
3. Documentacion: Hice una FAQ en un mediawiki interno, de manera que las personas que deseen migrar puedan saber las cosas basicas.
4. Homologacion por IT: Le pedi a la gente de IT que incluya ese servidor para los backups periodicos y monitoreo.
5. Migracion: Migramos lo que teniamos en gitlab al repo gitblit. Para hacerlo, cerramos todos los branches que estaban abiertos (integramos) y copiamos los archivos al nuevo repo. Decidí perder el historial porque no teniamos mucho.

El resultado... algo asi: