luauf.com » Gestión

Introducción a Control de Versiones con Git

Luciano — Sun, 26 Feb 2012 00:47:54 +0000

Git es un software de control de versiones, como lo son, por ejemplo: CVS, SVN o VSS.

Git fue diseñado por Torvalds con el objetivo de llevar el kernel de Linux en un repositorio confiable o como el propio Linus dijo “rápido, muy rápido, fácil, bonito y espectacular”.

Una de las referencias de Linus en el diseño de git fue CVS, pero como un ejemplo de lo que NO HAY QUE HACER, pues lo sufrió durante siete años en una compañía y allí aprendió a odiarlo con pasión. Linus tampoco quizo probar con SVN, pues el lema de SVN era “hacer CVS bien”, y eso ya lo condenaba, pues no había forma de hacer a CVS bien.

Dejando de lado las anécdotas anteriores, Git es utilizado por la mayoría de los desarrollos open source de la actualidad:

El propio Git
Linux Kernel
Perl
Eclipse
Gnome
KDE
Qt
Ruby on Rails
Android
PostgreSQL
Debian
X.org

Para quienes no saben lo que es un software control de versiones, básicamente, se puede resumir en un servidor donde se suben los archivos de un proyecto y a medida que se van modificando se van registrando y documentando estos cambios (versionando). En principio la idea es sencilla y más de un improvisado podría cuestionar el uso del mismo. No obstante, en la medida que un proyecto crece, la cantidad de archivos aumenta, los cambios y la cantidad de programadores también, resulta totalmente insostenible trabajar sin un control de versiones.

Trabajar sin control de versiones implica no saber donde está el último fuente, arrancar trabajando de una versión anterior y perderse los cambios de la que realmente era la última, no saber cuales son y quien realizó los cambios, no deshacer fácilmente los cambios realizados (downgrade), o no poder facilitar la transición a una versión totalmente nueva de un proyecto manteniendo el soporte a la anterior.

Una cosa más, la mayoría de los IDEs actuales tienen integración con Git, o si no la tienen, tienen algún plugin para hacerlo. Ahora, si no utilizas un IDE, tu caso es un poco más delicado

Sin más preámbulos, vamos a la práctica. En mis prácticas no utilizaré IDE, utilizaré un único archivo fuente y utilizaré el mismo equipo (dotado con Ubuntu Linux) como repositorio y cliente. Por lo tanto, primero, descargaré lo necesario: apt-get install git-core

Primer paso, en rol de “servidor”, creo el repositorio:

$ git init mi_repositorio

Initialized empty Git repository in /home/luciano/mi_repositorio/.git/

En caso de no pasar el último argumento, en mi caso: mi_repositorio, el repositorio se inicializará en el directorio actual.

Ahora, en rol de “cliente”, supongamos que tengo mis desarrollos en este path:

$ pwd
/home/luciano/desarrollo

Si quiero “sincronizar” mi directorio de desarrollo con el repositorio de git, debe hacer un “clone”, así:

$ git clone /home/luciano/mi_repositorio
Cloning into luciano…
done.
warning: You appear to have cloned an empty repository.

Estamos arrancando de cero, por lo tanto el warning es ignorable

El argumento que cambiará del “clone” en el caso que el repositorio se encuentre en otro servidor, será el path del repositorio, que deberá ser antecedido por usuario@host, por ejemplo:

git clone username@host:/path/to/repository

Un repositorio administrador por git cuenta con lo que se denominan tres árboles, el primero, el directorio local (directorio de trabajo). El segundo es un “directorio intermedio” a donde van a parar los archivos que se agregan al proyecto, finalmente el “HEAD” donde reside la última versión confirmada. Ahora, veremos como agregar un archivo al repositorio y como “commitearlo”.

Primero, creo un archivo fuente en mi directorio de trabajo:

$ pwd
/home/luciano/desarrollo
$ cd mi_repositorio
$ touch holamundo.c

Observen lo siguiente, no hay nada que decir:

$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use “git add …” to include in what will be committed)
#
# holamundo.c
nothing added to commit but untracked files present (use “git add” to track)

Ahora, agrego el archivo al repositorio:

$ git add holamundo.c

Finalmente, commit:

$ git commit -m “revision inicial” holamundo.c
[master (root-commit) 2b983d9] revision inicial
Committer: Luciano

Ahora, el estado nuevamente:

$ git status
# On branch master
nothing to commit (working directory clean)

Un último comentario acerca de lo último, el commit quedó registrado con mi usuario (Committer) y mi host luciano@lucid.

Una opción, antes de lo anterior, es setear esos valores de la siguiente forma:

$ git config –global user.name “Juan Del Rio”
$ git config –global user.email juan@delrio.com

Ahora, modifico el fuente y observo el estado de nuevo:

$ echo “/* holamundo program */”> holamundo.c

$ git status
# On branch master
# Changes not staged for commit:
# (use “git add …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: holamundo.c
#
no changes added to commit (use “git add” and/or “git commit -a”)

Hay cambios sin “commitear”, por lo tanto, hago un nuevo commit:

$ git commit -m “agregue encabezado” holamundo.c

$ git status
# On branch master
nothing to commit (working directory clean)

Para terminar (por ahora), si elimino el archivo:

$ rm holamundo.c

$ git status
# On branch master
# Changes not staged for commit:
# (use “git add/rm …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# deleted: holamundo.c
#
no changes added to commit (use “git add” and/or “git commit -a”)

Por lo tanto debo:

$ git rm holamundo.c
$ git commit -m “bye bye adios” holamundo.c
$ git status
# On branch master
nothing to commit (working directory clean)

Por hoy esto es todo, a pesar de que es muy poco y aún no es lo suficiente para compreder las virtudes de un sistema de control de versiones, basta para saber como hacer “altas, bajas y modificaciones”.

En la próxima entrega, quedo comprometido en tratar los “push” a un servidor remoto, trabajar con “branches”, hacer “merges” y un poco más.

Administración de proyectos con dotProject

Luciano — Wed, 09 Jul 2008 02:46:20 +0000

Recuerdo de mi época de estudiante universitario que usabamos DotProject para la gestión de un proyecto grupal. Para quienes no lo conozcan DotProject es algo así como un Ms. Project, pero con interfaz web y distribuido bajo licencia GPL.

El recuerdo del dotProject viene a mi, a partir de un artículo que leí BarraPunto , y que me pareció interesante citar pues cita características como definiciones de proyectos (OpenUP, Scrum, XP), integración con SVN, etc.

“Complutense de Madrid ha desarrollado una extensión de dotProject, el gestor de proyectos con interfaz web, con varias características interesantes para la comunidad: un asistente para la importación de definiciones de proyectos (OpenUP, Scrum, XP y algún otro); la gestión de control de versiones con subversion (dotproject sólo permite etiquetar a mano los ficheros); el concepto de rol como responsable de tareas; y la posibilidad de definir dependencias de tipo produce/consume entre tareas y productos del proceso de desarrollo. El software se distribuye bajo GPLv3 y se puede descargar. En esa dirección se podrán encontrar demos (vídeos + software) y manuales de instalación y uso.”

Vía: BarraPunto

Extreme Programming (XP)

Luciano — Wed, 18 Jun 2008 02:31:56 +0000

Las metodologías ágiles en el desarrollo de software son términos bastante de moda hoy en día, y no por nada. De hecho, te pueden resultar familiares términos como Extreme Programming (XP), Scrum, Crystal, Evolutionary Project Management (Evo) o Feature Driven Development (FDD).

En esta ocasión, quiero compartir un breve resumen de un texto acerca de Extreme Programming. Exceptuando la parte histórica, XP se basa en llevar al extremo las buenas prácticas de desarrollo de software, y así bajar el riesgo, permitir cambios de especificaciones durante el desarrollo y favorecer la comunicación con el cliente.

Lo más interesante radica en la enumeración de las prácticas que son llevadas a un extremo:

Como probar programas es bueno, entonces se hacen pruebas unitarias y funcionales todo el tiempo.
Como hacer pruebas de integración es importante, la integración sigue inmediatamente después de las pruebas unitarias
Como revisar la calidad del código es recomendable, se revisa código todo el tiempo y se hacen refactorizaciones, que implican cambios de diseño para hacerlo más simple, pero que no afectan la funcionalidad.
Como los estándares de codificación permiten una mejor comunicación y reducen los errores, se fijan estándares precisos y estrictos.
Como es bueno que el sistema sea simple, se busca la simplicidad siempre, diseñando solo lo que se necesita en el momento.
Como los requerimientos de la arquitectura pueden ser cambiantes, se van refinando constantemente.
Como el desarrollo incremental es positivo, se hacen iteraciones lo más cortas posibles: se diseña una pequeña porción, se la codifica y se la prueba.
Como suele suceder que un proyecto se suspenda en un momento determinado (por ejemplo por falta de presupuesto) se implementa primero lo que tiene mayor valor para el cliente.
Como es importante tener una comunicación frecuente con el cliente, siempre debe haber un cliente acompañando el desarrollo. Además éste es fundamental para escribir pruebas funcionales y establecer prioridades.
Como dos cabezas piensan mejor que una, y cómo refuerzo a las prácticas anteriores, los programadores trabaja de a dos: uno escribe y el otro piensa en mayor escala, buscando simplicidad, errores y formas alternativas de solución del problema. Estas parejas pueden intercambiarse a lo largo del desarrollo, de todas formas cada pareja es responsable de una tarea, y hasta no terminar esta no hay intercambio.

Extraído de: Orientación a objetos con Java y UML, de Carlos Fontela.

Instalar un repositorio CVS en Linux

Luciano — Sun, 08 Jun 2008 19:57:10 +0000

CVS (Concurrent Versions/Versioning System) es una aplicación cliente-servidor que instala un repositorio centralizado de aplicaciones, archivos y básicamente cualquier tipo de archivo.

En esta publicación vamos a instalar, configurar y probar CVS en Linux, especificamente sobre la distribución de Ubuntu 8.04:

Descargar el cliente y servidor CVS, cvs y cvsd:



$ sudo apt-get install cvs cvsd

Entre otras cosas, la instalación crea una estructura de directorios en /var/lib y crea los usuarios y grupos cvsd:



/etc/passwd

cvsd:x:114:116:cvs pserver daemon:/var/lib/cvsd:/bin/false
/etc/groups

cvsd:x:116:

Dentro del directorio /var/lib/cvsd crearemos el directorio para nuestro repositorio (se pueden crear tantos directorios como repositorios querramos utilizar).



$ cd /var/lib/cvsd/

$ sudo mkdir cvsroot

Cambiamos el propietario y grupo del directorio creado, con el usuario y grupo creado durante la instalación por el cvs:



$ sudo chown cvsd:cvsd cvsroot

Ejecutamos cvsd-buildroot para que se creen los directorios y archivos administrativos del sistema y se actualicen los binarios (cada vez que se actualicen los binarios del CVS deberíamos ejecutarlo)



$ cvsd-buildroot /var/lib/cvsd

Para finalizar, inicializamos el repositorio y creamos un usuario para acceder al mismo:



$ sudo cvs -d /var/lib/cvsd/cvsroot/ init

$ sudo cvsd-passwd /var/lib/cvsd/cvsroot/ luciano

/usr/sbin/cvsd-passwd: adding user 'luciano' to '/var/lib/cvsd/cvsroot/CVSROOT/passwd'

Enter new password:

Retype new password:

En esta instancia, nuestro repositorio ya está creado y ya podemos empezar a trabajar con el mismo. Para probar si es así, podemos conectarnos por línea de comandos o a través de algún IDE (por ejemplo, Eclipse o NetBeans incluyen integración con repositorios):



cvs -d :pserver:luciano@localhost:/cvsroot login

Logging in to :pserver:luciano@localhost:2401/cvsroot

CVS password:

Vía: Emilio

¿Que es Bazaar?

Luciano — Wed, 04 Jun 2008 02:59:59 +0000

En los últimos días, producto del renegar diario con CVS, he empezado a leer un poco acerca de distintos sistemas de control de versiones. De esa lectura aparecen nombres como CVS, SVN, Git y Bazaar.

En esta ocasión, sin entrar en detalles técnicos ni prácticos, me limitaré a citar algunas características de Bazaar. Espero en una futura publicación poder decir “Como instalar Bazaar”.

Bazaar es una herramienta de control de versiones distribuidas
Es patrocinada por Canonical Ltd. ¿te suena? Canonical es el sponsor comercial de Ubuntu
Se centra en la facilidad de uso y puede ser utilizado por un único o en conjunto con equipos de desarrollo
Está escrito en Python, publicado bajo licencia GNU/GPL y disponible para plataformas Windows, Linux y Max OS X.
Comandos similares a otros sistemas de control de versiones (CVS, SVN)

Para finalizar, una presentación de la herramienta, realizada por Martín Albisetti:

Vía: El CoDiGo K

Revolución Scrum

Luciano — Fri, 25 Apr 2008 00:03:32 +0000

Hace tiempo vengo escuchando y leyendo acerca del Scrum, así que leyendo un poco armé un resumen, muy breve, útil para tener una idea general de que se trata.

Scrum es una metodología para el desarrollo de software que, como ninguna, se ha ganado muy rápido el visto bueno de los usuarios y cada vez más el de las empresas de la industria del software.

Ken Schwaber y Jeff Sutherland han sido los responsables de desarrollar una nueva manera de gestionar proyectos de construcción de software. Para el nacimiento de Scrum, los autores comparan la tradicional aproximación secuencial de desarrollo de productos en el que consecutivas fases del desarrollo son llevadas a cabo por diferentes grupos de especialistas (similar al desarrollo en cascada) con un enfoque más iterativo, en el que, usando una metáfora basada en el rugby, solo una persona corre en cada momento y el equipo pasa el balón al siguiente corredor. El liderazgo del proyecto va cambiando y todos trabajan como un equipo.

Scrum asume que los requerimientos cambiaran durante el proyecto. Scrum toma el cambio como una forma de entregar al final del desarrollo algo mas cercano a la verdadera necesidad del cliente.

El mercado actual exige ciclos de desarrollo cada vez más cortos. Para lograrlo se utiliza el “sprint de requisitos”, una lista en la que se detalla de cómo se van a construir los diferentes requisitos del producto. Cada sprint suele realizarse en un plazo de entre 2 y 4 semanas. Al final, el objetivo es entregar algo que funcione, para el usuario pueda probarlo y se puedan introducir los cambios necesarios antes de que sea demasiado tarde. Esto es lo que nos permitirá ser flexibles.

Schwaber y Sutherland se basaron en el trabajo de la década del 80 de los japoneses Takeuchi y Nonaka, quienes estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, 3M o Hewlett-Packard. De ahí extrajeron la base de la metodología SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.

Vía: La masa, el ladrillo, la bota, el bocadillo… , PymeCrunch