sábado, junio 30, 2012

Y un repositorio de código para el 2012? GIT

Hará cosa de dos meses que vengo penando cual debería ser el repo de código corporativo del Instituto que actualmente viene usando el SVN. Esto me lleva al 2003, cuando tuve que tomar un puesto de liderazgo muy importante para un proyecto grande en IBM en su cuenta Telefonica, en esa época CVS dominaba el mercado y una de las cosas que hice fue migrar a SVN, pese a las puteadas del pulgin de Eclipse, lo pudimos hacern y en pocas semanas. Pero al terminar me dejo lan mala señal que era mas de lo mismo aunque la gente estaba muy contenta, usaba el VC de moda pero en números, no funcionaba los lockeos, los merges eran súper complejos, lo que ganamos automatizando el build lo perdí haciendo los merges, la mentira del rename, etc, etc.
Volviendo al 2012, si planifico una estrategia uniforme, tengo que tener cuenta las tendencias actuales, grupos que trabajan en diferentes locaciones, diferentes segmentos de red, lan, wan, internet, el avance de cloud y soluciones hosteadas fuera del datacenter, estado del arte actual de los VC y su integración con las nuevas plataformas de desarrollo e infraestructura (virtualizacion, continuos integration, puppet, etc). Pensando en todas esos temas, hay tres drivers fundamentales:
  1. El VC indiscutido es GIT, hay otras cosas buenas en el mercado como el de Jazz (RTC) o TFS (de MS) pero por el momento considero que IBM Argentina no esta maduro para colaborar con una implementación de RTC ni TFS esta lo suficientemente maduro para soportar las plataformas que quiero soportar. Obviamente están los Otros como peforce o mercurial, pero acá el Open Source lidera.
  2. Ubicuidad, considero que es fundamental que el código este disponible (de manera segura) y pueda ser accedido desde diferentes dispositivos y plataformas. El equipo de desarrollo de software de elite que tiene el instituto tiene que poder accederlo fácilmente sin problema.
  3. Lo necesito rápido, y posibilidad de ir escalandolo sin grandes complejidades ni costos de administración de los operadores aprendiendo un nuevo servicio de TI.

Teniendo en cuenta todo esto, comencé un piloto con Github el cloud de GIT mas utilizado por la comunidad open Source que tiene muy buena latencia, soporta varios protocolos y se puede utilizar desde adentro del instituto como de afuera y tiene features fantásticos como el pull requesón y revisión de código entre pares.

Vamos a ver que sucede con el correr del tiempo, toda decisión tiene sus desafíos, aquí intento enumerarlos:
  • Resistencia al cambio por utilización de GIT. Yo lo uso y puede resultar complejo sin una GUI, a mi me resulta cómodo la consola por ser usuario de Linux o MAC, pero es algo que estoy planificando. No tengo duda que GIT es la plataforma, no va a ser fácil la transición.
  • Integración con el IDM del Instituto, si bien lo mas parecido a IDM que tenemos es AD por el momento la solución de GITHub no tiene ninguna integración pensada o que yo haya visto, están las APIs disponibles que con unas horitas de programación ruby lo integro con mucho gusto.
  • Como mantener la historia del SVN en el GIT, entiendo que se puede, hay comandos de rebase entre ambos repos pero nunca lo hice y no quiero llegar a la solución de dejar un repo SVN en modo lectura.

Y me estoy ganando muchos enemigos? Puede ser, pero lo veo muy claro si quiero dar un servicios de excelencia no puedo darme el lujo de trabajar con tecnologías legacy que me frenen mas adelante... Se viene el CI en la nube con Cloudbeed?

Todo comentario o sugerencia será mas que bienvenida, alguien ya lo hizo?

5 comentarios:

Hernán dijo...

Tengo experiencia trabajando con las herramientas de IBM como Rational Software Architect y estas están basadas en eclipses mucho más viejos que las versiones actuales. En este caso fue imposible hacer andar el plugin para GIT y obligar a todos a perder la IDE para VC fue imposible. Creo que más allá de las tecnologías es importante el soporte de las herramientas. En las comunidades Ruby / python es prácticamente universal GIT. En Java con herramientas propietarias, prácticamente imposible. Al no estar atado por las herramientas creo que el piloto es la mejor opción. BTW en el piloto que realicé usé 'git-cvsimport' y se portó muy bien para generar un repositorio GIT en base a uno de CVS. No se si existe un 'git-svnimport'

Gustavo Andrés Brey dijo...

Hernán,
Buen punto, la integración con herramientas es fundamental. Lo que se esta viviendo en los últimos años es la manera de evitar la obligación de usar un IDE en particular, si no que sea una elección del developer, herramientas como maven para Java ayudan en gran medida. El pulgin de GIT para eclipse, EGit ya funciona perfecto para las operaciones mas importantes desde 3.6 y ni hablar 3.7, no te olvides que ya es parte de la comunidad de eclipse hace ya varios años. Obviamente para operaciones ya mas complejas que tiene que hacer algún integrador, la linea de comando es fundamental en GIT. Igual, para los que no tengan un IDE con soporte para GIt (I'm sorry les digo) siempre este el TortoiceGit.
Buena ata del cvsimport, si esta para SVN, te manejo lo histórico?

opensas opensas dijo...

una UI para git que me ha dado muy buenos resultados es smartgit (http://www.syntevo.com/smartgit/index.html)

el soporte de intellij también parece muy bueno

de todas maneras, lo más recomendable es darle al menos unos meses a la línea de comandos, para entender qué es lo que realmente ocurre

también te recomendaría que le pegues una mirada a gitflow (http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)

saludos

sas

Gustavo Andrés Brey dijo...

Gracias Sebastián! Me gusto lo del git-flow, voy a verlo mas en detalle.

Guillermo Díaz S. dijo...

Hola Gustavo, soy desarrollador Junior Java. Llevo un año trabajando en el lenguaje. He sacado el primer certificado de oracle para Java 7 SE lo cual sé que no es gran cosa.

La empresa para la que trabajo usa svn y yo he tratado de ganarme a mis superiores mostrandoles Git, pues bien, ha pasado el tiempo y al parecer he avanzado algo en la empresa para la que laboro.

Me considero alguien qué le gusta aprender y me gusta liderar, razón aparente que hace poco tiempo acá me han puesto como líder técnico de un equipo de 7 desarrolla dores Java, más viejos que yo.

En fín. Hablando un poco sobre mi, me gustaría saber cómo te fue con la propuesta de git, que comentas en este post. Me da curiosidad porque justamente trato de inculcar el uso del mismo a personas que no lo usan y que para ellos es más facil un solo commit a un repo central

Gracias de antemano, ojalá puedas ayudarma dando un feedback sobre tu experiencia.