Modelo de desarrollo

Introducción

Tras estudiar un poco el funcionamiento de http://launchpad.net (no tan intuitivo como pretenden), he aquí una propuesta de modo de trabajo "con-código" para cuando tengamos que tirar líneas.

Los tutoriales concretos de bazaar siguiendo este modelo están aquí.

Ejemplo

Para resumir muy mucho, como algunos sabréis bazaar es un sistema de control de versiones que sirve igual que la historia de la wiki: lleva todas las versiones de tus archivos de código (en realidad de cualquiera), te enseña las diferencias entre versiones y te permite hacer otro millón de cosas interesantes como trabajar mucha gente a la vez (como subversion, pero sin necesidad de un server central), o mezclar bien los cambios entre el trabajo de mucha gente (lo más automático posible: si dos escribimos distinto una línea obviamente hay que revisar a mano, esto no es IA). Bazaar puede trabajar en modo "checkout", donde es básicamente "subversion" (el server centralizado, cuando cambias algo detecta tus cambios y tienes que mandarlos al repositorio remoto con "commit", y bajarte los cambios de otros con "update" antes de trabajar), pero también puede hacer "branch" (o "ramas", que son como "variantes" de una base de código con tus modificaciones por entendernos) con lo que todo se almacena en local, y para juntar tu código con otros branches hay un comando "merge" entre branches separados (parecido, supongo, al svn merge).

ojo que los comandos no son exactos, sino cogidos de los equivalentes en subversion.

Basamos el modelo de desarrollo en la propuesta de separarnos en grupitos de desarrollo con los que organizamos un poco.

Modelo de desarrollo

INDIVIDUO

• Absolutamente opcional. Para que la gente que no se aclare con el bazaar no tenga que liarse más de lo estrictamente necesario. Esto sirve solo para facilitar al trabajo al que se quiera complicar un poquito la vida al principio, es útil cuando eres desorganizado como yo.
• Trabajar en local con bazaar, y descentralizado.
• Puedes hacer commits locales (esto es, *sin* conexión a internete). Pero también puedes subir tu código a tu espacio de launchpad con bzr push, para bajarte el código desde la facu, sincronizar con tu portátil, tener un cierto backup o lo que sea. Sin embargo al no necesitar conexión para hacer commits puedes hacerlos frecuentemente (casi con cada cambio que hagas que ande a medias, vamos), y tienes "time machine" de tus archivos de código (de eso va el commit tb, puedes hacer "revert" y deshacer cambios).
• Puedes usarlo para otros proyectos tuyos, tener cienmil branches del código
• Como contra, hay que *aprender* a usarlo.
• Aquí es donde tiras tus líneas de código.

EQUIPO

• Los cuatro equipos del apocalipsis XD.
• Separación de trabajo por bloques de funcionalidad, o como podamos o queramos repartírnoslo.
• Cada equipo agrupa features del código, probablemente inestables y rotas, mientras se desarrollan.
• Trabajamos con el modelo "checkout" que es trabajar *igual* que en subversion, los commits son *solo* remotos.
• Dos opciones de trabajo:
  1. Si trabajas con bazaar en local, tus branches locales llevan tu código y su historia, y por tanto tienes que hacer merge de tu código personal con el branch del equipo (lógicamente, hay que sincronizarlo). En principio no debe ser mucho lío (nada que ver con subversion al respecto), pero esto es lo que habría que aprender realmente. Pero a cambio solo te hace falta conexión para sincronizar tu trabajo con el equipo, y puedes ir sincronizando más a alto nivel (cuando algo te medio funciona como para que el resto puedan usarlo, no una-vez-por-cada-cambio-en-archivos).
  2. Si pasas de liarte con bazaar en local, pasas a trabajar totalmente como si fuera subversion. Pierdes los commits locales y necesitas conexión (constante) a internet para cada commit, y pierdes también la posibilidad de hacer tus branches del branch del equipo (maldad extrema). A cambio, no te lías con merge y es muy similar a usar subversion, con el que algunos ya hemos trabajado.
• Aquí centralizamos el curro de cada equipo.
• Comentario: no es necesario un equipo *por feature*, en realidad para eso están los branches… Si os dais cuenta todos los equipos suben al *proyecto* hdlorean (lo veréis enseguida!), y en la página del proyecto quedan tanto los branches personales como los branches de equipo registrados, que pueden ser varios (se ve quién los publica, el equipo, y los nombres de esos branches, que sí pueden ser por feature).

PROYECTO

• Donde tenemos el proyecto ya todo junto.
• El "trunk" que viene por defecto en launchpad.
• Probablemente con sus propias branches (p.e. entregas a tal y cual fecha -se puede hacer con un tag-, estable, inestable, etc. ).
• A diferencia de los de equipo, feature-complete.
• Sirve para *integrar* el curro de los equipos: Aquí aplicamos control de calidad, los responsables de equipo (o team leaders que suena como más pijo) nos encargamos de mergear lo que sea, Mario controla que funcione como deba. El caso es que solo entre el código funcionando y se mantenga así lo más posible.
• Sería como un branch "de integración".
• nuevo: Usamos dos niveles de integración: en testing nos dedicamos a control de calidad y estabilizar código, mientras que unstable es para mezclar código entre repositorios separados y poder probarlo integrado. Todos los repositorios de equipo, por tanto, heredan de unstable y son mergeables con él.

Justificación

Como digo todo esto es un poco teórico porque no sé seguro si bazaar nos dejará hacerlo todo, pero creo que al menos sí bastante de ello. Así todo junto parece un follón, pero es solo para aclararnos. A la hora de la verdad se podría trabajar contra el checkout del team como quien curra con subversion, y solo hay problemas a la hora de integrar cambios entre todos. La contrapartida es que los desarrollos son separados, no hay problemas de tu-cambio-ha-roto-nuestro-código-en-otra-parte, etc.

Para entendernos: a la hora de la verdad, puede quedar en que tú subes tu código al branch de tu equipo, y luego solo nos peleamos un poco más los responsables con bazaar para integrarlo. Que es, por otra parte, quienes han confirmado que están dispuestos a trabajar así (al fin y al cabo somos quienes sufrirán un poco más para integrarlo). Para mayores problemas, recurriremos a Adrián como director de integración, o a Ezequiel como persona más informada en la tecnología.

Las ventajas de tener todo en launchpad es que cuando hay bugs se pueden relacionar con *todas* las partes afectadas por un bug a la vez (p.e. tu branch personal si trabajas con bazaar, a la vez el branch del equipo, y el proyecto que es donde apareciese). Puedes arreglar en *un* sitio y propagar los cambios a *todos*, o arreglar diferente en "estable" (con un parche cerdo XD) y en "inestable" (cambiando en plan serio lo que hubiese que cambiar). IDEM para peticiones de features, o lo que sea. Y el bugtracking así es más sencillo.

Otras "historias" de esto pueden ser p.e. que un equipo necesite un feature de otro equipo y estén ocupados con alguna otra prioridad, o lleve mucho tiempo implementarlo. Puedes o bien pedírselo amablemente, o bien implementarlo tú lo mínimo posible para que funcione y luego en el merge quitar tu implementación (ya bien sea en el merge hacia-proyecto o pillando trozos del código del otro equipo cuando está funcionando ya), o incluso implementarlo tú entero y que luego sea el equipo "responsable" de ese código el que lo pille de tu branch y lo mergee con el suyo.