Sistemas de Control de Versiones Distribuidos

Un sistema de control de versiones (SCM) es el responsable de mantener las trazas de varias revisiones de la misma unidad de información. Se utiliza normalmente en proyectos de desarrollo de software para gestionar el código del proyecto, pero también puede usarse para gestionar versiones de documentación de cualquier tipo de proyecto de la empresa.

El primer proyecto SCM fue CVS y consta de 1986, desde entonces muchos otros proyectos han florecido: Perforce(1995), CVSNT(1998), Subversion (2000) cada uno con sus peculiaridades y ventajas.

En Mayo de 2007 Linus Torvalds realizó una presentación sobre git y desde entonces el interés por los sistemas de control de versiones distribuidos (DVCS) ha ido aumentando considerablemente. Sebastian Auvrey editor de InfoQ muestra en un excelente artículo las ventajas de este tipo de sistemas que resumimos a continuación.

Un sistema DVCS moderno resuelve asuntos que no resuelven los sistemas VCS centralizados tales como:

• Realizar distintas ramas es fácil pero fusionarlas no lo es. Subversion por ejemplo no dispone de fusión de históricos, lo que fuerza a los usuarios a realizar estas tareas a mano.
  
• No hay manera de enviar los cambios a otro usuario si no es pasando por el servidor central.
  
• Subversion falla al fusionar cambios cuando los nombres de los ficheros o directorios han sido renombrados.
  
• La convención de nombres de subversion de las distintas Ramas/etiquetas/Trunks puede ser engañosa.
  
• No es posible realizar commits offline.
  
• Los archivos .svn contaminan los directorios locales.

Descentralización

DVCS tienen la ventaja de los sistemas peer-to-peer. Los clientes pueden comunicarse con otros y mantener sus propias ramas locales sin la necesidad de acceder a un repositorio central, La sincronización tiene lugar entre los peers que deciden que partes intercambiar.

CVCSvsDVCS

Esto da como resultado unas diferencias con respecto a los sistemas centralizados:

• Sólo se trabaja con copias.
  
• Operaciones normales como commits, vista de históricos, diferencias, y rollbacks son más rápidas porque no hay necesidad de comunicar con un sistema central.
  
• Cada copia de trabajo es vista como un backup remoto proporcionando así un sistema natural de seguridad contra pérdida de datos.
  
• Crear y borrar nuevas ramas son operaciones simples y rápidas.
  
• La colaboración entre los distintos peers se hace fácil.

Esquema de VCS Centralizado

Esquema de VCS Distribuido

La diferencia está en que en un repositorio centralizado, todo el mundo realiza las operaciones de commit, backup, tracing y sincronización sobre el mismo tronco y en uno distribuido cada usuario tiene su propio repositorio que comparte completo o sólo la rama necesaria con otros desarrolladores. Sin embargo, no hay que pensar que esto pueda dar con un caos sin regulación ya que si es necesario todos pueden notificar los cambios a un repositorio común, algo similar al centralizado que recogerá los últimos cambios de cada usuario.

La versión distribuida se centra en compartir los cambios mediante la asignación de un id único. Asimismo, las operaciones de Descarga/Grabación o aplicar son operaciones separadas mientras que en un sistema centralizado operan de manera conjunta. Además, el sistema distribuido no fuerza la estructura permitiendo crear sitios administrados "centralmente" o bien mantener a todos como peers.

Workflows

Sobre las distintas estrategias a utilizar a la hora de diseñar un workflow puede echarse un vistazo al artículo de bazaar el cuál se resume a continuación:

Estrategia Solo:

Estrategia Partner

Estrategia centralizada

Estrategia centralizada con commits locales

Estrategia descentralizada con parte principal compartida

Estrategia descentralizada con puerta de enlace humana

Estrategia descentralizada con puerta de enlace automática

Software

Los principales desarrollos de este tipo de sistemas son Mercurial (Apr, 2005), Bazaar (Mar, 2005), darcs (Nov, 2004), Monotone (Apr, 2003) y el propio git ya mencionado anteriormente.

Una tabla comparativa con las características principales de cada herramienta puede encontrarse en el artículo de Sebastian Auvrey. Parece que git se lleva la palma en cuanto a rapidez pero como bien se recoge en algunos debates es debido a su buena integración con Linux ya que hace uso de características nativas de este sistema operativo.

Ventajas y desventajas

Ventajas

• Todos los participantes tienen su propia caja de arena. Es decir puedes hacer cambios, roll backs y tus históricos permanecerán en tu repositorio local sin necesidad de hacer checkins gigantes.
  
• Trabaja offline. Sólo necesitas estar online para compartir cambios. No pasa nada si el servidor está caído.
  
• Es más rápido. Los Diffs, commits y reverts son hechos en local.
  
• Maneja los cambios mejor. Los sistemas distribuidos se han creado bajo la premisa de compartir los cambios. Cada cambio tiene un guid que hace fácil su traza.
  
• La creación y fusión de ramas es más fácil. Porque cada desarrollador tiene su propia rama y cuando se comparte es como realizar una integración inversa. El guid hace eso automáticamente combinando los cambios y evitando duplicados.
  
• Menos gestión. No es necesario un servidor siempre activo, ni la necesidad de añadir nuevos usuarios, lo que evita los quebraderos de cabeza en proyectos grandes.

Desventajas

• Todavía necesitas un sistema de backup. No hay que fiarse de que el backup reside en el otro(s) usuario(s), ya que este puede no admitirte más, o estar inactivo mientras que yo tengo cambios hechos, por lo que todavía será necesario un servidor central donde realizar los backups "para esos casos".
  
• Realmente no hay una "última versión". Si no hay un repositorio central no hay manera de saber cuál es la última versión estable del producto.
  
• Realmente no hay números de versión. Cada repositorio tiene sus propios números de revisión dependiendo de los cambios. En lugar de eso, la gente pide la última versión del guid concreto (un número verdaderamente feo). Afortunadamente cabe la posibilidad de etiquetar cada versión con un nombre más amigable.

Fuentes:

InfoQ
Intro to Distributed Version Control
Workflows
Patch Theory

De Blogs, Wikis y Blikis

¿Que qué es un bliki?

Pues parece la evolución natural de los blogs, o eso afirma Martin Fowler en su blog (?).

Resulta que un blog es un buen instrumento de comunicación tanto personal como empresarial y aunque ofrece ciertas capacidades de colaboración, hay que decir que son bastante restringidas, limitándose a ofrecer la posibilidad de publicación de algunos autores.

Por otro lado, las wikis son un instrumento de difusión de contenidos y conocimientos multiusuario, en las que distintos usuarios pueden corregir, editar un mismo artículo, manteniéndose un histórico de cambios y revisiones y la posibilidad de crear contenidos de forma no lineal o cronológica, algo que es el modo predeterminado de cualquier blog.

Las wikis han demostrado su funcionalidad con éxito en ambientes empresariales, proporcionando a las empresas un gestor de contenidos, barato y asequible para pequeños grupos, documentar proyectos o comunicarse con clientes, aunque con algunas limitaciones frente a otros cms comerciales y open source como gestión documental, integración con el sistema operativo, seguridad centralizada basada en repositorios o en sistema operativo, workflows avanzados de gestión y edición de contenidos, etc.

A pesar de todo esto resulta una herramienta muy útil precisamente debido a su sencillez y a su característica de apertura. Útil sobretodo para documentar el conocimiento de la empresa, bien a nivel de proyecto, o bien de manera institucional, donde cualquier integrante de una comunidad puede generar contenido que será útil para el resto de usuarios de esa comunidad-resolver problemas, aclarar dudas, perspectivas futuras, manuales de procesamiento, información, etc.-. El ejemplo más conocido en Internet es la Wikipedia.

Por tanto, ¿qué es un bliki? la respuesta es obvia, la combinación de un blog + un wiki. La capacidad de generar contenidos y ofrecer una herramienta colaborativa a una comunidad de usuarios, la posibilidad de hacer crecer los contenidos dentro de una comunidad y que siempre se encuentren vivos, junto con unas herramientas de catalogación y búsquedas de los mismos.

Aunque el término bliki parece que fue acuñado por Martin Fowler, la realidad es que el mismo y la herramienta fue creada por el mismo creador del primer Wiki Ward Cunningham.

En Internet hay quién dice que es la herramienta perfecta a sus problemas de mantenimiento de los blogs. Lo cierto es que cuando uno lee de qué tipo son esos problemas, ve que se pueden resolver simplemente incorporando un sistema de búsqueda, nubes de etiquetas, categorías, recomendaciones, etc. y como en cualquier proyecto, es necesario establecer bien las categorías y contenidos para no perderse nada, pero no es necesario disponer además de un wiki para que no desaparezcan los artículos, ya que a mi modo de ver el cometido del wiki es algo más elevado que hacer de soporte a los contenidos.

Como conclusión decir que por un lado tenemos una herramienta de fácil administración y edición como son los blogs pero que cuando hay muchos contenidos resulta difícil manejar algunos post y pueden caer en el olvido (si no se realiza una buena tarea de mantenimiento como se ha explicado anteriormente), y por otro una buena herramienta de colaboración y gestión del conocimiento. ¿Será esta la combinación perfecta?

Por último dejo algunos enlaces de software que hacen uso de blikis:

• Chisimba


• Confluence


• DokuWiki


• EditMe


• ikiwiki


• MoinMoin


• OddMuse


• OpenKH

• pimki
  
• PodWiki
  
• SnipSnap
  
• TikiWiki
  
• TWiki
  
• Wiclear
  
• XWiki

Día del W3C en España

El próximo 27 de Mayo tendrá lugar el día del W3C en el rectorado de la Universidad Politécnica de Madrid organizado por la oficina del W3c en España y que tendrá como título "Standars for Business".

El W3C es el consorcio internacional que desarrolla los estándares utilizados en la Web. Desde 1994, el W3C ha publicado más de ciento diez estándares, conocidas como Recomendaciones del W3C. Su director, Tim Berners-Lee, inventor de la World Wide Web en 1989 mientras trabajaba en la Organización Europea de Investigación Nuclear (CERN), fue galardonado en 2002 con el Premio Príncipe de Asturias de Investigación y Humanidades.

Esta jornada se aprovechará además para difundir a nivel nacional el Congreso Mundial WWW2009 que se celebrará, por primera vez en España, del 20 al 24 de abril de 2009, y que será organizado por la UPM.

Un servidor de aplicaciones sin Java EE

Springsource es la compañía que hay detrás del desarrollo del framework Spring y ha anunciado la salida de un servidor de aplicaciones sin Java EE basado en el popular framework Spring y retando de esta manera a los servidores de aplicaciones existentes.

El servidor de aplicaciones se ha construido sobre Spring, OSGi y Apache Tomcat, partiendo de los estándares Java EE pero con el modelo de programación de Spring de forma nativa.

Springsource Application framkework no trata de ser un servidor de aplicaciones tradicional ya que no soporta archivos de despliegue EAR, ni tampoco EJBs, aunque sí admite paquetes WAR, OSGi y propietarios PAR. Este servidor ha sido diseñado centrándose en aquellos proyectos de tipo opensource más usados. Además ha creado una serie de componentes incluidos en el kernel para tareas de tracing, bootstrap, gestión y carga de clases y otras características sobre el entorno de desarrollo Eclipse Foundation's Equinox OSGi.



Actualmente puede descargarse una versión beta con una licencia de evaluación, pero hay anunciada una versión opensource para la comunidad bajo licencia GPLv3, y según se puede leer en el blog de Rob Harrop además de las especificaciones técnicas en los comentarios dicen que no se soporta EJB, pero parece que en un futuro sí se haga con OpenEJB si la comunidad lo cree conveniente.

Hace un año Interface21 la empresa que desarrolla Spring cambió su nombre por el de Springsource al recibir una inyección de 10 Millones de dólares lo que hizo despegar a la misma debido al crecimiento que estaba experimentando y le ha servido para mejorar y ampliar su framework y crear una gama de productos alrededor, como por ejemplo las herramientas de testing y depuración que se integran con eclipse y que se echaban de menos, ya que aunque Spring facilita el desarrollo de los servicios de las aplicaciones es necesario cierta infraestructura para proyectos medianos y grandes debido a la cantidad de recursos que es necesario controlar y que son susceptibles de error, lamentablemente estas herramientas no son gratuitas. Las herramientas se lanzan actualmente de desde una perspectiva opensource y gratuita llamada "Springsource tool suite" e integrada con el IDE Eclipse. Lo que hace muy fácil ahora la creación de proyectos y el aprendizaje mediante cursos de Spring Framework.

Liderazgo y Coaching con SCRUM

SCRUM es una metodología de desarrollo de proyectos dentro del grupo de las llamadas metodologías y procesos ágiles que está gozando de buena publicidad y prensa actualmente dentro de las empresas de desarrollo del software, aunque hay que decir que SCRUM no es una metodología exclusiva de este tipo de proyectos, pudiendo aplicarse a todo tipo de proyectos de prácticamente cualquier área de la empresa.

Si bien, el ámbito perfecto de trabajo de SCRUM es aquel que se suele denominar como caótico, donde los requisitos no están bien definidos, o son son muy cambiantes, o las expectativas del proyecto no quedan demasiado claras desde el principio por parte de los clientes. Proyectos de uso interno o sometidos a una constante evolución son también un nicho perfecto para esta metodología. En este sentido proyectos de ingeniería, marketing o publicidad entre otros pueden beneficiarse de este marco.

Los equipos y valores de SCRUM

En algunos ámbitos se conceptúa a SCRUM como un marco de trabajo y no una metodología en sí misma, pero el hecho la que caracteriza es que minimiza la cantidad de procesos necesarios para abordar un proyecto que en muchos casos son fuente de ralentización de los mismos. Enfocada dentro del grupo de metodologías ágiles, cumple el manifiesto agile y se centra en los procesos de desarrollo de los proyectos, así como en las prioridades de los clientes.

Reduce los tiempos enfocándose en las tareas más que en los procesos abordando todas las circunstancias impredecibles que surgen en todas las áreas y niveles de un proyecto. Así mientras en un desarrollo de proyectos clásico y predictivo se confía toda la responsabilidad de la resolución del conflictos al gestor de proyectos, en SCRUM los equipos son auto-organizados y manejan por sí mismos toda actividad.

Este modelo de ejecución en equipo conlleva un estilo de liderazgo adaptativo, ya que no todas las situaciones son iguales. En SCRUM aparecen tres figuras representativa:s el dueño del producto (Product Owner) más orientado hacia el negocio, el Scrum Master orientado al cumplimiento y desarrollo de la metodología y el equipo como tercer integrante.

El modelo de SCRUM orienta su implementación hacia unos equipos bien formados, cuanta más experiencia tengan los integrantes del equipo mejor se desarrollarán los distintos sprints. Aunque este concepto no es nada nuevo, lo que queda claro es la implicación de las otras dos figuras (dueño del producto y scrum master), que les obliga a realizar un estilo de delegación con el fin de que el propio equipo sea autosuficiente. De hecho, el equipo de desarrollo decide qué tareas debe hacerse, cuál es el esfuerzo a dedicar a cada una de ellas y cuánto tiempo hay que dedicar a cada una de ellas. Mientras, el dueño del producto indica cuáles de las tareas deben salir en primer lugar, es decir, prioriza las tareas que hay que hacer en cada fase y reestima si es necesario la medición del esfuerzo hecha por el equipo, siempre que exista un consenso entre el equipo y el dueño del producto.

Este modelo resulta de lo más actual frente a las corrientes empresariales que se viven actualmente en cuanto a liderazgo de equipos y coaching. Ya que la práctica del coaching viene dando buenos resultados en el entorno organizacional, pues se encarga de potenciar las capacidades de sus empleados basándose en un modelo no impositivo y por otro lado usar un modelo de liderazgo situacional para saber adaptarse a las capacidades de cada colaborador, son a mi modo de ver dos complementos indispensables para una buena gestión de equipos con SCRUM, pues todos sabemos que la organización de equipos siempre es heterogénea en cuanto a niveles de experiencia y capacidades de sus integrantes, así también aumenta la complejidad de gestión cuando nos enfrentamos a un proyecto multidisciplinar, donde los perfiles corresponden a disciplinas diferentes.

Utilizar un modelo directivo impositivo con SCRUM no funcionará pues obligará a eliminar muchas de las características ágiles y de resolución de problemas, pero como se ha comentado anteriormente no todas las situaciones son iguales en cada momento ni todos los integrantes del equipo son iguales, por lo que en algunos momentos el estilo de liderazgo será directivo, en otros delegativo, en otros de acompañamiento, etc. dependiendo del nivel de experiencia, que es precisamente en lo que se basa el liderazgo situacional. Por otro lado SCRUM se basa en un modelo "basado" en la responsabilidad y en la autonomía, algo que es fácilmente alcanzable mediante las técnicas de coaching.

Estos factores quizá sean los motivos más difíciles de conseguir a la hora de implantar SCRUM, sobretodo si se viene de una metodología clásica centrada en procesos. Por último siempre conviene recordar que lo importante son los resultados hacia el cliente y delegar, e incluso negociar tareas de un proyecto con el equipo no es perder poder, sino aumentar la confianza y responsabilidad.