Archive for 9 junio 2010

Cómo interactuar con tus técnicos

9 junio 2010

Últimamente estoy oyendo (más veces de lo habitual) lo difícil que es entenderse con esa gente que llaman “los informáticos” a distintas personas relacionadas con la creación de sitios web. La cosa es, cuando menos, preocupante. Me parece esencial tener una buena comunicación con tus técnicos para poder construir un buen portal web. Especialmente me refiero a la gente con la que más nos toca trabajar: Diseño, usabilidad y jefes de producto, …. Quisiera aclarar que, aunque trabajamos con máquinas, somos profundamente humanos y por lo tanto, sí, se puede hablar con nosotros.

Tank, I need an exit.....Fast!

Visto esto e inspirado por mi amiga Olga y su post de “Los otros” me he decidido a escribir unos consejillos de cómo tú (diseñador, responsable de usabilidad, jefe, CEO, …) podrías interactuar mejor conmigo (léase los informáticos).

  • Tip #1: No me hagas trabajar. Al menos para nada. Es mejor no reinventar la rueda (salvo que seas un fabricante de ruedas, claro). Déjame utilizar cosas estándar del mercado aunque no se ajusten al milímetro a lo que tienes en mente. Seguro que sirve igual y, además, nos evitamos un montón de trabajo de desarrollo, depuración de errores, … de trabajo del pesado.
  • Tip #2: El trac lo aguanta todo (TM). Utiliza algún sistema de gestión de tickets para crear tareas o reportar errores. Si no puede ser, utiliza el email. Si me dices al oído eso de “anda amigo, cuando tengas un hueco hazme el favor de …”, lo más probable es que ocurra una de estas dos cosas: Que se me olvide lo que me has pedido, o que haga como que se me ha olvidado. ¿Quieres echar un vistazo al Trac de Voota?
  • Tip #3: Mañana también existe. No me digas que todo es super-mega-crítico porque entonces nada lo será. Si tienes alguna idea importante o algo que no va como quisieras, casi siempre pude esperar a la siguiente release. No me hagas dejarlo todo para atender a tu capricho. Vale, sí, hay cosas que no pueden esperar a mañana …. Pocas.
  • Tip #4: No despliego los viernes ni después de las 12. Es verdad, lo confieso, me gusta la cerveza. Muchas tardes después del trabajo y, sobre todo, el fin de semana, me gusta tomarla. Lo prefiero a estar atendiendo incidencias provocadas por subir cosas a producción a última hora, deprisa y corriendo.
  • Tip #5: El que lo abre lo cierra. Si me abres una incidencia o me pides un desarrollo, no te olvides de cerrarlo. Revisa que efectivamente es lo que pedías y que todo está correcto. Esto evitará que, más adelante, tengamos errores en producción descontrolados.
  • Tip #6: Dame detalles, no la tabarra. Cuando informes de un error dame detalles precisos: Donde falla con que datos o en que url. Recuerda que a menudo un pantallazo vale más que 1.000 palabras. Con mucha prosa me mareo, me aburro y me invitas a procrastinar.
  • Tip #7: Ya voy. Si no esperas a que termine, es probable que no funcione. Revisar es bueno, pero espera a que el trabajo este hecho. Es bastante habitual ponerse a probar un desarrollo o incidencia antes de que te diga que está listo para revisar: Fail!
  • Tip #8: Trabajo para tí, aunque esto jamás te lo voy a decir. Es importante entender que si me facilitas el trabajo y me ayudas a trabajar mejor y más rápido, el que ganas eres tú, tu negocio o tu portal.

En fin amigos, espero que “los informáticos” vayamos perdiendo poco a poco esa fama de bichos raros y que la comunicación sea cada vez más fácil. Se que hablo desde mi técnico punto de vista, así que si tienes algo que decir, no te cortes 😉

Anuncios

Un workflow sencillo con git

4 junio 2010

Uno de los grandes quebraderos de cabeza del desarrollo web es el control del ciclo de vida. Cuando la cosa se pone seria, muchos desarrolladores, muchos cambios etcétera, se hace imprescindible alguna metodología compleja tipo integración continua. Sin embargo, en la mayoría de los casos es suficiente con tener un poco de orden y unos procedimientos claros.

Gráfico GitHub de los commits de Voota

Gráfico GitHub de los commits de Voota

Es, sin duda, el gestor de versiones el principal aliado para gestionar correctamente el ciclo de vida. Este es el workflow que utilizamos en Voota con git:

  1. Cada desarrollador “sube” sus cambios al repositorio de software cada vez que realiza un desarrollo. Para ello se utiliza la rama “master” en git, que es, por decirlo de alguna manera, la arteria principal del desarrollo. Es el proyecto vivo que se irá actualizando diariamente.
    git commit -am “Resuelto el ticket #nnn”
    git push
  2. Cuando hay un “change set” razonable, o lo que es lo mismo, ya se tienen unos cuantos cambios que queremos que sean revisados, se envían al servidor de pruebas (“stage”). En el servidor de pruebas hay una copia (“clone”) exacta del código fuente, pero que, para que funcione en modo test, se realizan algunos cambios básicos. En el caso de Voota se copian los scripts de php que ponen a Symfony en modo test (en realidad esto sólo se hace una vez al instalar el servidor):
    mv frontend_test.php a index.php
    mv backend_test.php a backend.php

    A continuación se utiliza la magia de git. Se actualizan los fuentes con rebase. La gracia de “rebase” es que re-aplica las acciones que se han realizado (como los mv de arriba) sobre la copia local después de actualizar los cambios desde el repositorio. De este modo no es necesario volver a hacer las modificaciones.

    git pull –rebase
  3. Para el paso a producción hace falta un poco más de control. Se debe implementar un mecanismo que permita al desarrollador retomar el código en el estado exacto que está en producción. Este es el uso que damos a las etiquetas (tags) de git:
    git tag milestone1_8_5
    git push –tags

    Esto creará una foto del proyecto en su estado actual, con todo el conjunto de fuentes agrupado bajo el nombre de etiqueta milestone1_8_5. Como curiosidad, se pueden ver aquí las etiquetas que tenemos en el git de Voota.
    El resto es similar al entorno de pruebas, con la diferencia que no se actualizarán los programas de la rama “master” como antes, si no que se hará de la etiqueta recién creada:

    git pull –rebase origin refs/tags/milestone1_8_5

Alguien que conozco diría “Todo perfecto. Invitar a cañas” 😉 … pero, ¿que pasa si se sigue desarrollando en la rama “master” y se detecta un error importante en producción?¿a alguien le ha pasado alguna vez? Nada, se arregla y listo. Ahí va el procedimiento:

# Por si algún otro desarrollador ya lo ha hecho antes, se actualizan las etiquetas desde el repositorio:
git fetch –tags

# Se crea una rama basada en la etiqueta de la versión en producción:
git checkout milestone1_8_5 -b b_milestone1_8_5

#####################################
# Se hacen cosas: Arreglar el bug por ejemplo 😉
#####################################

# Se suben los cambios a git:
git commit -am ‘se explica lo que se ha hecho un poco’

# Se actualiza la etiqueta:
git tag -f milestone1_8_5

# Se “empuja” al repositorio
git push –tags

# Volvemos a la rama principal en la copia local
git checkout master

# Se aplica el parche a la versión en desarrollo para que no se pierda en la siguiente release
git merge b_milestone1_8_5

# Se borra la rama creada para la ocasión
git branch -d b_milestone1_8_5

Ahora en el servidor de producción se actualiza la versión “tirando” de la etiqueta:

git pull –rebase origin refs/tags/milestone1_8_5

Trabajar con git tiene muchas ventajas y una de ellas es hacer las cosas fáciles y rápidas. Creo que este es un buen ejemplo.