Automatizando el día a día

Cerrado por traslado

2011-03-18T01:53:00.000Z

Ya he completado la mudanza. A partir de ahora puedes leerme en Eliminando la (sub)rutina.

Estoy de mudanza

2011-03-14T19:47:00.000Z

Alguno me ha comentado que aún está esperando la segunda parte del artículo de herrammientas colaborativas (¡qué bien, hay gente que me lee! :-)

Voy a tardar un poco más porque estoy mudando mi blog a Posterous (junto con mi página personal). En cuanto esté listo ya les avisaré por aquí. La url de momento es ejosafat.posterous.com, pero la definitiva será www.ejosafat.com.

Como dicen los anglosajones, stay tuned!

Herramientas de colaboración online (I)

2010-12-27T12:48:00.000Z

Recientemente di un mini-taller sobre herramientas de colaboración online, y me llamó la atención ver como muchas organizaciones seguían atrapadas en el caos de las bandejas de entrada con miles de correos y documentos repartidos por múltiples carpetas en máquinas locales o servidores, habiendo soluciones económicas y efectivas para evitar eso.

El Caos: situación típica en muchas pequeñas empresas

Veamos un diálogo habitual en muchas PYMES (y no tan PYMES):

(Yo): ¡Oye! ¿Cual es la contraseña para entrar en el servidor xxx del cliente yyy?

(Lucas): Eso creo que lo tiene Juan en un correo.

(Juan): No, a quién se lo enviaron es a Jose.

(Jose abre su Outlook, realiza un rápido escaneo visual entre sus miles de correos): mmmm... no lo veo, espero que le doy a buscar.....

(como es de esperar, el buscar del Outlook no encuentra absolutamente nada relacionado, o igual te dice que ha encontrado una impresora que si quieres instalar el driver metas un cd...).

(A Lucas se le enciende la bombilla): ¡espera! ¿no estará en el documento de claves que tenemos en el servidor?.

Miro en el servidor y tras esperar un rato a que conecte (este Windows 2xxx Server es más lento que...) veo un documento llamado claves ftp... a ver si está ahí..., no hubo suerte...

...pero no voy a desanimarme, acabo de ver que hay una carpeta que se llama claves; entro ahí y veo varios ficheros de texto, pero tampoco se encuentra en ninguno de ellos...

...mmmm.... subo en el árbol de directorios y me encuentro una carpeta con el nombre del proyecto de dicho cliente, entro pero ahí no hay nada realmente....

...y a todo esto ya ha pasado media hora para poder subir un pequeño fichero (y aún no he conseguido hacerlo), !acción que no debería haberme llevado más de un par de minutos!

Problemas de repartir la información en un montón de archivos dispersos

Tener la información que necesitas dispersa entre ficheros alojados en diversas carpetas de un servidor no es la mejor manera de organizarla. Es más dificil encontrarla, bien porque no sabes donde está, bien por los diversos formatos en los que se puede encontrar, y sobre todo por el hecho de que tampoco dispongas de una herramienta de búsqueda eficaz de la información contenida en esos ficheros. Hay que advertir a los usuarios de Windows que un perro de verdad tiene más probabilidades de encontrar algo olisqueando la carcasa de tu disco duro que el perrito del windows xp.

Si el servidor donde reside la información no es accesible desde el exterior, olvídate del teletrabajo en esos días de lluvia. O si no están en un servidor, sino en el ordenador de ese compañero de trabajo que se ha ido de vacaciones un mes a Brasil y nadie conoce su contraseña...bueno, lo puedes imaginar.

Problemas de tener la información dispersa en un puñado de emails

Si vas intercambiando emails con distintas personas a lo largo del proyecto, y además tu cliente de correo no es muy bueno con las búsquedas, y como suele pasar no has estado fino a la hora de escribir el asunto de los emails, buscar cualquier información puede ser una ardua tarea. Si además entran personas posteriormente al proyecto, hay que estar buscando los emails con información relevante para enviarselos y ponerlo al día.

Al final la información anda dispersa en las bandejas de correo de varias personas y encontrar cualquier pedacito de información no es tarea fácil.

El Orden: usa alguna herramienta de colaboración online

Existen multitud de herramientas de gestión de proyectos y colaboración online, bien como software instalable, bien como servicios ofrecidos por lo general gratis, con opciones ampliadas para clientes de pago e incluso suelen existir servicios de hosting para las soluciones instalables, por si no tenemos servidor o no queremos complicarnos la vida. Voy a hablar únicamente de los que he tenido la ocasión de usar o probar, pero basta googlear un poco para descubrir un vastísimo ecosistema de aplicaciones de este tipo.

Dentro de las instalables, mencionar dos clásicos: el dotProject y el PHProject 6. Ambos son soluciones en PHP, OpenSource, que podemos instalar o buscar algún proveedor que ofrezca el alojamiento de alguna de estas soluciones ya instaladas. No están mal si eres fan de las cosas rígidas y el Microsoft Project; para proyectos bajo el paraguas de cualquier combinación de metodologías ágiles (donde el énfasis está en la comunicación y no en rellenar formularios de tareas) son demasiado engorrosos. Lo he visto instalar en dos o tres empresas por las que he pasado y en ninguna se llegó a usar realmente ni sirvió para nada (bueno si, para complicarnos un poco más el trabajo).

Como servicios alojados hay muchos donde elegir, los que más he usado son 5pm, Pivotal Tracker y por último Basecamp, sin duda de los mejores existentes hoy en día.

Por último mencionar soluciones que se ofrecen como servicio alojado para los que no disponen de servidor propio o no quieren complicarse la vida, pero a su vez su código fuente está disponible para instalarlo en nuestro propio servidor: ClockingIT, cuyo código fuente podemos descargar, y la que para mi es mejor en esta categoría, Teambox, programada en Rails igual que la anterior aunque para mi gusto con un código de mucha más calidad.

Conclusiones

Hay un amplio espectro de soluciones sencillas de utilizar para organizar mejor la comunicación y los flujos de trabajo en la empresa. ¿Por qué seguir en el caos? En próximos artículos comentaré mi experiencia de uso con algunas de estas herramientas.

Configurar un servidor Git usando Gitosis

2010-11-08T16:13:00.000Z

Tras un tiempo usando git en local contra un repositorio central subversion, es hora de migrar completamente y montar un servidor central de repositorios git utilizando Gitosis. Sigue leyendo para ver como hacerlo en un servidor Linux basado en la Ubuntu, aunque estas instrucciones son fácilmente adaptables a cualquier distro o Mac OS X.

Instalando lo necesario

Para su instalación, el servidor debe tener instalado el python y un paquete del PEAK llamado EasyInstall. Para comprobar que tenemos ambos instalados hay que ejecutar desde la consola:

python --version

El sistema debe responder con la versión instalada. Normalmente, en una distribución Ubuntu viene instalado por defecto. Para comprobar la disponibilidad del EasyInstall, se puede ejecutar:

python -c "import setuptools"

El sistema responderá con una línea en blanco si está instalado y con un ImportError: No module named setuptools si no se encuentra disponible. Por defecto, en una Ubuntu no viene instalado, por lo que habrá que hacerlo.

Lo primero es descargarlo en nuestro servidor; en la página de descarga hay que elegir el fichero .egg correspondiente a la versión de Python que esté instalada en el servidor. En mi distro, ésta versión es la 2.6.5, por lo que descargo el fichero cuyo nombre acaba en -py2.6.egg. Una vez descargado, lo instalo en la localización por defecto para los paquetes de Python. Para ello solo hay que hacer:

wget http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
sudo sh setuptools-0.6c11-py2.6.egg

Instalar Gitosis

Para instalarlo, hay que descargar el código fuente de la aplicación desde su repositorio git y ejecutar el script de instalación. Se puede realizar desde nuestra carpeta de usuario en el servidor donde realizamos la instalación:

git clone git://eagain.net/gitosis
cd gitosis
sudo python setup.py install

Crear clave de autentificación para el administrador del repositorio

La autentificación ante el servidor no se realiza con contraseña, sino usando el esquema de clave pública/privada RSA. Asumo que ya el usuario dispone de una clave de este tipo, sino se puede generar fácilmente con el comando:

ssh-keygen -t rsa

Hay que copiar el fichero de clave pública, normalmente situado en nuestra carpeta (de nuestra estación de trabajo, no el servidor) /home/<nombre de usuario>/.ssh/id_rsa.pub al servidor.

Configurando el servidor para utilizar Gitosis

Se requieren dos cosas para funcionar en el servidor: un usuario bajo el cual se ejecuta, y una carpeta donde almacenar los repositorios. Por convención se suele utilizar el usuario git, y la carpeta /srv/<midominio.com>/git, pero se puede instalar donde se quiera. Yo voy a utilizar la carpeta /var/git, por lo que ejecuto:

sudo adduser --shell /bin/sh --disabled-password --home /var/git git

Inicializando Gitosis

Para esto se usa un programa que viene con el gitosis, gitosis-init, el cual se ejecutará usando el usuario creado previamente. En este punto hay que recordar donde guardamos nuestra clave pública para indicárselo a dicho script.

sudo -H -u git gitosis-init < /ruta hacia nuestro/id_rsa.pub

Tras esto hay que realizar un pequeño fix para que podamos crear repositorios adicionales.

sudo chmod 755 /var/git/repositories/gitosis-admin.git/hooks/post-update

Hay que recordar cambiar /var/git por la ruta hacia la carpeta home que decidimos en su momento.

Configurando Gitosis

La configuración de esta aplicación se trata como un repositorio git. Debemos clonarlo en nuestra estación de trabajo (aquella desde la que copiamos nuestro id_rsa.pub), realizar los cambios necesarios y subir las modificaciones al servidor.

git clone git@dominio_de_nuestro_servidor.com:gitosis-admin.git

Accedemos a la carpeta local donde está la configuración y vemos un fichero de texto, gitosis.conf, y una carpeta, keydir, donde se halla una copia de nuestra clave pública, que es la que se usa actualmente para autentificar el servidor.

En esta carpeta se añadirán las claves públicas de las personas que deban acceder al repositorio, y en el fichero de configuración es donde se añaden los repositorios que se vayan creando y se establece el acceso de las personas a ellos. Incialmente este fichero tendrá esta pinta:


[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = ejosafat@nombre_de_mi_maquina.local

Esto significa que existe un grupo denominado gitosis-admin, con permiso de escritura en el repositorio del mismo nombre, y del que son miembros las personas especificadas en la línea members, donde separados por un espacio se indican los nombres de los ficheros de clave pública presentes en keydir cuyos usuarios pueden acceder al repositorio en cuestión.

Los cambios que se realizen como la adición de claves a la carpeta keydir o la información de configuración en el fichero se suben al servidor central utilizando el comando git push (tras haber realizado el git commit correspondiente en la versión local.)

De hecho el primer cambio que realizo es cambiar el nombre del fichero de claves para dejarlo en algo tan sencillo como ejosafat.pub, por lo que la configuración de los miembros administrativos, quedaría como:

members = ejosafat

Añadir nuevos repositorios

Para añadir nuestros repositorios, lo único que hay que hacer es crear la entrada correspondiente en el fichero gitosis.conf. Por ejemplo:


[group mi_proyecto]
writable = mi_proyecto
members = ejosafat juan pepe

Si queremos añadir usuarios con acceso de solo lectura, creamos otro grupo y utilizamos la directiva readable.


[group mi_proyecto_readonly]
readable = mi_proyecto
members = marcos lucas

Hay que recordar que cada vez que añadimos un usuario nuevo hay que añadir una copia de su clave pública a la carpeta keydir.

Una vez hemos hecho el commit y el push, el nuevo repositorio se creará en el servidor. Si ya existía un repositorio local con el código, nos vamos a la carpeta donde se encuentra y hacemos un:

git remote add origin git@dominio_de_nuestro_servidor.com:mi_proyecto
git push origin master

Si no existía ningun repositorio previo, podemos crear uno utilizando git init.

Notas sobre puertos ssh

Si nuestro servidor usa un puerto distinto del 22 para las conexiones SSH, debemos especificarlos en nuestra fichero ~/.ssh/config, de la forma:


Host dominio_de_nuestro_servidor.com
Port 1234

Conclusiones

Tras un tiempo de transición utilizando git contra un servidor subversion, es recomendable dar el salto definitivo para gestionar enteramente tus versiones con Git, tanto en local como en el servidor remoto. Créeme, lo agradecerás a la hora de trabajar con branches de desarrollo, algo muy importante tal como hablé en otro artículo.

Desarrollo estable - usar branches con git

2010-10-11T16:29:00.001+01:00

En la típica aplicación de internet ya desplegada en servidor(es) de producción, lo habitual en un momento dado es trabajar en solucionar los bugs que el cliente va detectando por un lado, y por el otro ir añadiendo nuevas funcionalidades que se van produciendo.

¿Qué pasa cuando estoy trabajando en una nueva funcionalidad, tengo la mitad de los ficheros de la aplicación modificados pero el cambio aún no está completo, y de repente surge un bug que hay que solucionar para ayer? Si hago las correcciones oportunas y desplego la aplicación en el estado actual (con una serie de cambios en otras áreas a mitad) es posible que el sistema deje de funcionar.

Eso me ha pasado alguna vez, pero afortunadamente es historia con un uso disciplinado de las ramas (branches) de desarrollo que ofrecen por lo general todos los sistemas de control de versiones.

Creación de branches en Git

A la hora de trabajar en una funcionalidad nueva, en lugar de hacerlo directamente sobre la rama principal de desarrollo, creo una rama nueva dedicada única y exclusivamente a esta funcionalidad. El comando para ello es:

git checkout -b nueva_funcionalidad

Este comando es un 2 en 1: crea una nueva rama con el nombre indicado y además hace un checkout de ésta, por lo que en este momento estaremos trabajando en la rama y no en la línea principal de desarrollo (en el git se llama master).

¿Qué queremos volver a trabajar en la rama principal para corregir un bug?

git checkout master

Si tenemos cambios sin commitear en la rama actual no nos dejará hacer el checkout, o bien los commiteamos o descargamos la rama principal en otra carpeta. De esta manera siempre mantendremos la línea principal de desarrollo estable mientras trabajamos en la nueva funcionalidad.

Fusionar

Una vez hemos terminado de programar la funcionalidad y nos hemos asegurado que pasa todos los tests (los nuevos específicos y los existentes), es hora de agregar nuestros cambios a la rama principal de desarrollo. Para ello debemos fusionarlas. Esto lo hacemos cambiando nuestra versión de trabajo a la rama principal y luego pedir la fusión:


  git checkout master
  git merge nueva_funcionalidad

Existen alternativas para especificar exactamente que commits de la rama nueva_funcionalidad fusionamos, pero a no ser que estemos trabajando en algo muy gordo que queramos ir añadiendo por partes lo usaremos rara vez, por lo que no detallaré esas otras alternativas.

Y si ya hemos acabado de trabajar en la rama de desarrollo, llegó el momento de borrarla. Tras el paso anterior donde hicimos la fusión, podemos hacer:


  git branch -d nueva_funcionalidad

Si no hemos hecho fusión ni nada o se queja de algo, cambiamos el switch -d por -D y listo.

Conclusión

La práctica de trabajar con ramas de desarrollo ha disminuido el número de situaciones incómodas en mi vida diaria como programador y no supone un esfuerzo extra en el trabajo, así que ¡no hay ninguna razón para que no las estés usando!

Vuelta de las vacaciones

2010-09-13T16:54:00.002+01:00

Ya de vuelta de las vacaciones, e inspirado por la peregrinación a Santiago de Compostela, en breve reanudaré la publicación de artículos. ¡No te los pierdas!

Utilizar Git con Subversion

2010-08-02T15:11:00.000+01:00

Inicialmente implantamos el uso de Subversion en la empresa porque habían varias personas ya familiarizadas con él y era la única opción que nos ofrecía Dreamhost.

Sin embargo el Subversion presenta algunos problemillas e ineficiencias por las cuales yo personalmente uso Git en mi máquina, dado que permite conectar con repositorios subversion sin problemas, manteniendo a nivel local todas las ventajas que me ofrece el Git.

Y aunque vamos a migrar enteramente a Git próximamente, entretanto trabajaremos con él localmente, mientras seguimos usando como repositorio central el Subversion de Dreamhost.

¿Por qué Git?

El uso de este sistema de control de versiones cada vez está más extendido, sobre todo en el mundo del OpenSource. Cada vez más proyectos están alojados en Github.

Es mucho más cómodo de usar incluso desde una consola de comandos. Y más listo: se acabó el dar ordenes explícitas con comandos subversion para borrar o mover archivos; podemos realizar esas operaciones con normalidad desde nuestra interfaz preferida, que Git se da cuenta por si mismo de que lo has hecho. Crear ramas (branches) se vuelve mucho más fácil también y menos costoso en espacio de almacenamiento.

Mayor control sobre los cambios realizados, pudiendo especificar con exactitud que cambios se suben al repositorio principal y cuales no, incluso dentro de un mismo fichero.

Git está pensado para entornos de trabajo altamente distribuidos, por lo que el repositorio reside en nuestra propia máquina, pudiendo trabajar sin necesidad de conectarnos al repositorio central, al que subiremos los cambios cuando los tengamos pulidos (y posiblemente seamos autorizados por alguien que supervise dichas operaciones), o nos conectaremos para pillar los cambios que hayan subido los otros.

Instalación de Git

Mac OS X

Desde la sección de descargas de la página, existe un enlace para la versión instalable para Mac (Leopard). Instalar como cualquier aplicación de Mac.

Aunque el git viene por defecto con el gitk y git-gui como herramientas gráficas, en el Mac podemos también descargar el GitX

Linux (Ubuntu)

En Ubuntu, hay que instalar los paquetes git-core, git-svn y para asegurarnos que no hay errores, subversion-perl.

Windows (XP)

Hay varias formas de instalarlo, quizás la más sencilla sea descargar e instalar msysgit..

Una vez descargado, tras el doble click pertinente para ejecutar el instalador y un par de pulsaciones en el botón Next para avanzar, llegamos a la selección de componentes para la instalación. Allí marcar un botón que dice Conext menu entries y luego otra vez Next. Cuando lleguemos a otra pantalla donde se nos dan más opciones a elegir, seleccionar Run Git from the Windows Command Prompt. La siguiente opción se deja como está (Checkout Windows-style, commit Unix-....).

Para usarlo, en el explorador de archivos pulsamos con botón derecho sobre la carpeta en la que queramos volcar nuestros repositorios, y seleccionamos la opción git bash here.

Trabajar con Git contra un repositorio central Subversion

Hablaré de las tres operaciones básicas a realizar, a saber: el checkout inicial del proyecto detro de una carpeta administrada por git, los commit tanto a nuestro repositorio local como al central (en Subversion), y las operaciones de actualización de nuestra copia con los últimos cambios subidos por nuestros compañeros de equipo.

Usaré la interfaz de línea de comandos para realizar dichas operaciones habituales.

Checkout

Si hemos creado el repositorio subversion con la estructura clásica (trunk, branches, tags), basta con hacer:

git svn clone --prefix svn/ -s http://direcciondemirepositorio.com/nombre_de_proyecto

Esto crea una carpeta denominada nombre_de_proyecto, en la cual se van a volcar todos los cambios realizados en el repositorio central hasta ese momento, preservando por tanto el historial.

Commit

En Subversion, cuando hacemos commit desde una carpeta y sin especificar ficheros concretos, sube todos los cambios que hayan presentes. La filosofía de Git es distinta: primero decimos que ficheros (o cambios dentro de ficheros) queremos meter en el próximo commit (git add -i para acceder a una herramienta interactiva donde indicar lo que queremos meter), y luego realizamos el commit propiamente dicho.

Ojo que en el Git cuando se hace un commit, se hace en el repositorio local. Cuando queramos subir los commit realizados al repositorio subversion, usaremos git svn dcommit

Update

Para actualizar hay dos maneras de hacerlo, una es bajar los cambios y después fusionarlos, y la segunda es una fusión de ambas y por tanto la más usada:

git svn rebase

Conclusiones

Aunque el git tiene sus detractores, y ya he leído varios artículos de gente que se iba a pasar al Mercurial, yo me siento mucho más cómodo con él que con el Subversion.

Tratar con el cliente

2010-07-02T14:38:00.000+01:00

Recapitulando

En el primer artículo de este blog hablé de la situación que me encontré al llegar a la empresa con la que colaboro principalmente en la actualidad, donde seguían el típico workflow de trabajo en la típica empresa que se dedica a hacer las típicas páginas web, es decir, caos y más caos.

Tras hacer un diagnóstico inicial confeccioné una lista de medidas a tomar (ver lista de medidas). La mayor parte de aquellos puntos están cumplidos, otros aún están en desarrollo. Hoy me voy a centrar en uno de ellos, quizás de los más difíciles de solucionar: la relación con el cliente.

Los problemas de siempre

Interrupciones: estás trabajando concentrado en un proyecto, cuando te piden que lo dejes todo de lado porque hay que arreglar no se qué en cualquier otro proyecto. Lo haces, vuelves al principal y vuelven a cortarte para decirte que hay que hacer no se qué en otro. Y así continuamente.

La neurociencia ha avanzado muchísimo en los últimos años, y se sabe muchas cosas de como funciona el cerebro, ya no es algo tan misterioso como nos decían de niños. Y una cosa que se sabe es que el contexto es fundamental. Tardamos entre 20 y 30 minutos en meternos de lleno en el contexto de una tarea compleja, una vez lo hemos alcanzado y además profundizamos en ese estado mental nuestro rendimiento es el máximo. Una simple interrupción de 1 minuto no es perder tan solo ese tiempo en la tarea, es perder todo el tiempo que invertimos en alcanzar ese punto de contexto.
¡Esto es urgente! Vale, eso me lo creo, pero....¿es prioritario? Ambos términos suelen confundirse por norma general.

Siempre se olvida que la urgencia del cliente no tiene porque ser nuestra prioridad. Para mi el sentido de lo urgente es directamente proporcional a cuánto facturas de media en un año a ese cliente.
Dejarte impresionar por los gritos del cliente. Muy relacionado con el punto anterior, suele pasar que un cliente enojado o nervioso porque quiere que tal o cual funcionalidad se implemente ya (olvidando que nos lo habían pedido el día anterior o incluso ese mismo día)

Yo personalmente llevo tantos años de jefe de proyecto que ya me he inmunizado a gritos y amenazas, pero esto no sucede siempre con tus jefes, los cuales llegan corriendo para que dejes el proyecto de cien mil euros en el que estás trabajando y añadas un formulario de contacto a la web de mierda del cliente que ha pagado mil, solo porque han estado chillándoles al teléfono. Y los que menos pagan suelen ser los más que chillan. A veces entran ganas de recordar mis tiempos de artes marciales y soltar algún ¡kiai! bien fuerte y profundo para amedrentarlos.
Presupuestos cerrados: esto es lo de siempre. El cliente llega con una idea más o menos difusa, con un listado de características que no se sabe muy bien para que lo quiere, si lo usarán o no, etc... pero hay que entregar un presupuesto cerrado, con tiempos definidos.

Y todos sabemos que el cliente no sabrá realmente lo que quiere o lo que necesita a medida que lo vayamos descubriendo juntos desarrollando y probando el proyecto, pero para entonces por lo general nos habremos pasado de tiempo y presupuesto, viendo como se reduce el margen de beneficios gradualmente hasta llegar a 0 o negativo en el peor de los casos, que además pasa de cuando en cuando.

Y como no, el coste oculto de las modificaciones a posteriori. El cliente viene, encarga proyecto, lo hacemos, y esperamos por su feedback y validación de lo hecho durante meses. Tras ese tiempo vuelve a interesarse por el proyecto y pretende que hagamos todos los cambios que nos pide, que aunque previstos en el presupuesto inicial, hacerlos después de 3 meses de haber terminado de programar supone volver a perder tiempo metiéndonos en el contexto del proyecto y además parar aquello en lo que estemos trabajando en ese momento.

Vias de resolución

Respecto a las interrupciones, he tomado varias medidas:
- Eliminar el teléfono de la mesa de trabajo. Para gran sorpresa de todos una mañana llegué al trabajo y con gestos enérgicos tiré del cable que lo conectaba al PTR y metí el teléfono en un armario perdido lejos de mí. La comunicación telefónica es altamente disruptiva, cuando un cliente quiere hablar directamente conmigo o me manda un email o deja recado y yo lo llamaré cuando a mí me venga bien, en el tiempo entre tareas. El mejor momento para el cliente de hablar no coincide por lo general con el mejor momento para mi. Entre yo y el cliente, ganan mis preferencias y mi productividad.
- Con los compañeros he desarrollado un código: si tengo los auriculares puestos, quiere decir que estoy en momento de máxima concentración. Esa duda o ese chiste me lo puedes contar cuando esté realizando otro tipo de tarea (leer correo, blogs, mientras voy camino del baño...)
- Facturarle al cliente el coste de las interrupciones. Teníamos un cliente que nos pedía cambios urgentes todos los días. Alguno de esos cambios en sí no llevaban más de 10 minutos, pero le facturábamos la hora entera. Nuestro interlocutor en el cliente era informático, y cuando arguyó que dicho cambio no llevaba una hora entera le expliqué que para hacer ese cambio debía cortar la tarea que estaba haciendo, meterme en el contexto de su proyecto, hacer el cambio, probar que va bien, hablar con él por teléfono para aclaraciones, subir al servidor de pruebas, esperar su confirmación, subirlo a producción, y tiempo para volver a meterme en el contexto de la tarea que interrumpí para atenderle a él. Lo entendió, y nunca más cuestionó los tiempos facturados.
¡Esto es urgente!, ante ese grito del cliente que pone nervioso a tu jefe el cual viene a tu mesa pidiendo que deje todo lo que estás haciendo porque hay que satisfacerle y total son 10 minutos.... ¿qué hacer ante esto? pues lo mismo que con las interrupciones, educar al cliente y hacerle ver tanto a él como a tu jefe los costes. Yo uso un par de ejemplos extraídos de como funcionan otros sectores (y de los que nadie se queja y todo el mundo da por hecho que funciona así):
- El ejemplo del taller de coches: ¿Alguna vez han tratado de llevar el coche al taller y decirle al mecánico que es urgente y necesitan el coche en el mismo día? Respondo yo mismo: NO. Si quieres que tu coche esté disponible para el fin de semana te asegurarás de preguntar desde el lunes en el taller, nunca se te ocurrirá llevarlo el viernes por la mañana. Igual si insistieras mucho y pagaras un pastón conseguirías que te lo arreglaran en un día, eso si, si la reparación no dependiera de piezas de repuesto no disponibles en ese momento. ¿Por qué nos bajamos los pantalones de esa manera en nuestro sector? Hay que acostumbrar al cliente a que funcionamos como otros sectores, que más inteligentemente que nosotros han sabido defender su trabajo y su manera de hacer las cosas.
- El ejemplo del cortador de piedra:
  Una vez fui a una fábrica de piedra a media mañana para comprar una encimera de baño. Elegimos la pieza, preguntamos cuanto tardaban en cortarla a las medidas pedidas: hora y media. ¡Estupendo! pensamos, así que le dijimos que podíamos esperar por la zona y así podíamos llevarnosla a mediodía.
  El señor dijo que imposible: sus operarios estaban en ese momento con una gran losa de piedra cada uno para cortar pertenecientes a otros encargos, y para atendernos tenían que dejar a medias lo que estaban haciendo, quitar la enorme piedra de su puesto de trabajo, poner la nuestra, ver lo que había que hacer, retirar la piedra, volver a poner la anterior y volver a recordar que es lo que había que hacer con ella.
  
  Conceptualmente, cuando estamos inmersos en un proyecto complejo donde tienes que manejar un universo de objetos y elementos interrelacionados en tu cabeza, parar tu trabajo para resolver esa pequeña urgencia es el equivalente de estar trabajando con una piedra del tamaño de una catedral y meterte en el follón de retirarla de tu mesa de trabajo, para poner la nueva piedra, y volver otra vez al follón de volver a colocar esa catedral para seguir trabajando con ella.
Presupuestos cerrados que al final se salen de madre, como siempre. Este es el pan nuestro de cada día cuando desarrollas a medida para terceros, es lo más complejo de resolver, junto con el desinterés de algunos clientes por el proyecto hasta 3 meses más tarde de haberlo dado tú por finalizado.

Respecto a lo primero, todos los últimos presupuestos que nos han pedido los hemos simplificado para ofrecer con un coste cerrado una serie de funcionalidades estrictamente definidas, explicándole al cliente que es mejor hacer algo básico que empiece a usar para que se de cuenta de lo que necesita realmente y a partir de ahí ir trabajando por iteraciones en las que se implementen poco a poco cosas que vaya demandando, facturando por horas. Así puede obtener justo lo que necesita controlando el dinero invertido en el proyecto.

En cuanto a lo de no darte feedback o solicitarte cambios meses después de haberlo finalizado, la política es: mientras trabajamos en tu proyecto te notificamos semana a semana de su estado, con despliegue en servidor de pruebas para ir probando. Paralelamente se le va pidiendo todo el material que nos tenga que suministrar. Si una vez finalizado sigue sin resollar, para cuando lo haga se le pondrá en cola respecto a las tareas que haya en ese momento. Aqui lo bueno es cobrar una buena cantidad de anticipo antes de comenzar el proyecto para que el cliente muestre bastante interés en finalizarlo cuanto antes.

Para esta última vía he desarrollado otro ejemplo, el de la compra/construcción de una casa. Cuando compras una casa o contratas la obra, una vez comprada o finalizada la obra, no esperas 6 meses para decirle al promotor/constructor que la instalación del agua va mal, o que la calidad de los materiales no es la acordada, o lo que sea. Ten por seguro que esto lo hará todo el mundo en la primera semana, porque saben que si lo hacen después el promotor/constructor se hará el loco o tardará una eternidad en resolverlo.

Conclusiones

Implementando estas medidas hemos conseguido algo de mejoría, aunque la conclusión final es que lo mejor siempre es dedicarse a productos propios antes que en proyectos a medida (sobre todo para el típico cliente en Canarias). La empresa donde trabajo está tomando esa orientación, y a nivel personal yo tampoco hago ya nada a medida, solo trabajo en mis propios productos.

Hasta conseguir un producto exitoso habrá que seguir comiendo, como siempre, por lo aún habrá que aguantar clientes durante un tiempo y por tanto mejor educarlos lentamente. ¿A alguien se le ocurren más ejemplos didácticos? Espero oir los tuyos.

Más scripts de apoyo

2010-06-17T15:11:00.003+01:00

Describiré brevemente en esta entrada una serie de scripts auxiliares que también me cree para apoyar toda la infraestructura de generación de un proyecto, pero sin entrar en detalles sobre el código. Este lo puedes descargar del RubyForge y está documentado.

Recapitulando

He mostrado los scripts que más nos alivian el trabajo a la hora de generar la infraestructura para un proyecto nuevo, tan solo queda automatizar pequeñas tareas asociadas. A continuación comento brevemente cada uno de ellos sin ahondar en explicaciones.

Objetivos

Crear un conjunto de pequeños scripts para automatizar pequeñas tareas rutinarias. En concreto:

Al crear los servidores virtuales para todos los usuarios, el Apache se queja de las carpetas no existentes. Para evitar esto, se debe hacer un checkout inicial del proyecto para cada usuario en su carpeta /home.
Crear una o varias bases de datos MySQL necesarias para el proyecto.
En la carpeta /etc del servidor de desarrollo está la lista de proyectos, utilizada por otros scripts para realizar backups u otras operaciones. Hay que añadir una entrada en esta lista para cada nuevo proyecto.
Los repositorios subversion generalmente se estructuran en torno a 3 ramas principales, trunk, branch y tags. Crear esta estructura inicial.
Cuando se genera el código inicial de un proyecto, por ejemplo Rails, hay que se agregar al repositorio los ficheros generados, excepto aquellos que variarán para cada desarrollador (caché, logs, configuración de base de datos local).
A veces se necesita actualizar del repositorio los cambios introducidos en todos los proyectos para estar al día.

Automatización

checkout_proyectos.rb <nombre proyecto>

Este script hace un checkout del proyecto especificado como argumento en todas las carpetas de los usuarios del sistema, lista que lee del fichero de configuración. De esta manaera el Apache no se quejará cada vez que carga la configuración indicando que hay hosts virtuales en los que no encuentra la carpeta, ya que el script para crear estos hosts visto en otro artículo crea uno para cada usuario, aunque este no haya creado la carpeta para alojar el código

crear_databases.rb <id de proyecto> [tipo de proyecto] [password de mysql]

Este script tiene como argumento obligatorio el nombre del proyecto, y como opcionales el tipo (php o rails) y la contraseña de root de mysql. Esto último argumento es opcional tan solo si no hay contraseña del usuario root de la base de datos. Ahorra un poco de tecleado o clicks a la hora de crear las bases de datos necesarias.

crear_entrada_lista.rb <id de proyecto>

Este script añade automáticamente la entrada correspondiente a un nuevo proyecto en el fichero con la lista de proyectos.

crear_estructura.rb <id de proyecto> [nombre de usuario]

Crea la estructura clásica de un proyecto en subversion (carpetas trunk, branch y tags)

generar_proyecto_rails.rb <ruta a carpeta>

A la hora de crear un proyecto y añadirlo al repositorio, hay que ignorar los logs, los ficheros de tmp y demás. Además hay que copiar el fichero database.yml con otro nombre para que cada desarrollador utilice el adecuado para su configuración. Todo esto y más (borrar el index.html de public, por ejemplo), ya lo hace este script.

update_projects.rb <usuario> [ruta hacia fichero con lista de proyectos]

Este lo uilizamos cuando queremos actualizar nuestra versión de todos los proyectos para estar al día.

Conclusión

Haber invertido tiempo en estos scripts nos ha ahorrado bastante tiempo y aburrimiento en nuestro departamento de desarrollo, y los utilizamos frecuentemente.

Sin embargo, recientemente he descubierto el Chef, potente framework de integración de sistemas que permite mediante recetas creadas (Ruby) desplegar todo tipo de servidores y ajustar su configuración de manera totalmente automatizada y eficiente.

Por otro lado me he pasado al Git como sistema de control de versiones, mucho más eficiente y cómodo que el Subversion.

Ya hablaré de todo esto más adelante, en próximos artículos voy a tratar un poco más de la parte humana de la automatización y la eficiencia.

Creación de servidores virtuales (II)

2010-05-19T12:44:00.000+01:00

Segunda parte del script de automatización de la creación de servidores virtuales y entradas dns correspondientes para un proyecto. Puedes ver la primera parte aquí.

Recapitulando

En el artículo anterior hablé de la creación de subdominios en el servidor de desarrollo para dar soporte al trabajo con los proyectos por parte de cada usuario.

Objetivos

Configurar servidor virtual en el Apache
Crear un script que automatize tanto la creación de la entrada DNS correspondiente (visto en el artículo anterior) a cada proyecto como la generación del servidor virtual en el Apache.

Paso a Paso

VirtualHost

Una vez creado el dominio a nivel local, el siguiente paso es configurar el Apache del servidor de desarrollo para que cuando reciba una petición a ese (sub)dominio sepa en qué carpeta se encuentra. El mecanismo para ello es el uso de la directiva VirtualHost.

Esta directiva no solo define la asociación entre un dominio o subdominio y una carpeta específica, sino que además permite establecer una configuración particular del servidor web para esa dirección.

Al instalar el Apache en la Ubuntu, éste crea un virtual host por defecto, denominado default. Yo hago los siguientes cambios para que después me funcionen los vh de cada proyecto. Estas modificaciones son fundadas en ensayos de prueba y error más que en el conocimiento de como funciona todo esto en el servidor web. Más de un sysadmin se tirará manos a la cabeza si lee esto.

Hay que editar el fichero /etc/apache2/sites-available y poner en la primera línea:

NameVirtualHost *

Luego, en la línea siguiente, donde pone:

<VirtualHost *:80

quito el 80. Así mismo quito la directiva NameVirtualHost * del fichero /etc/apache2/ports.conf, para eliminar redundancias.

Por otro lado, cuando se habilita un servidor virtual con la orden sudo a2ensite, lo que hace este comando realmente es crear un enlace simbólico en la carpeta /etc/apache2/sites-enabled apuntando al fichero donde hemos hecho la definición (en /etc/apache2/sites-available). En estos momentos existirá uno para el default, lo renombro para que se quede como 000-default, ya que asignar 3 dígitos iniciales al nombre del servidor virtual es la convención por defecto que uso.

Crear para un proyecto

Básicamente lo que hayo yo es copiar el fichero del servidor 000-default, renombrarlo como 001-nombredeproyecto. Dentro de éste creo una sección VirtualHost para cada usuario del sistema, donde se repite todo menos el nombre del subdominio (todos de la forma nombre_de_usuario.nombre_de_proyecto.it7) y la ruta hacia los ficheros de error del apache, que para cada servidor virtual los sitúo en la carpeta de cada usuario para que acceda a ellos fácilmente para diagnosticar errores.

Así, para un usuario determinado y un proyecto determinado, la directiva VirtualHost quedaría de la siguiente manera: (repitiendolo para cada usuario, todo en el mismo fichero):


 <VirtualHost *>
   ServerName ejosafat.imaco.it7
   DocumentRoot /home/ejosafat/ejosafat.imaco.it7
   <Directory /home/ejosafat/ejosafat.imaco.it7>
     Options FollowSymLinks
     AllowOverride All
     Options -MultiViews
   </Directory>

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
     AllowOverride None
     Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
     Order allow,deny
     Allow from all
   </Directory>

   ErrorLog /home/ejosafat/apache2.imaco.error.log

   # Possible values include: debug, info, notice, warn, error, crit,
   # alert, emerg.
   LogLevel warn

   CustomLog /var/log/apache2/access.log combined
   ServerSignature On
 </VirtualHost>

Diferencias entre rails y php en el vh

La configuración anterior sirve para el típico proyecto en php; tras haber convencido a mi empresa de las bondades del rails respecto al php, todos los proyectos nuevos que encajen en dicho paradigma de programación los desarrollamos en esa tecnología.

Para dichos proyectos, el DocumentRoot, que es la ruta hacia la carpeta donde se encuentra el proyecto, apuntaría a:


 DocumentRoot /home/ejosafat/ejosafat.imaco.it7/public

y si además nos diera por desplegar la aplicación utilizando el Capistrano, entonces habría que apuntar al servidor virtual a:


 DocumentRoot /home/ejosafat/ejosafat.imaco.it7/current/public

Automatización

Aquí he sido un poco chapuza, hay aspectos de Ruby que aún estoy aprendiendo, y lo de los paths y demás no lo controlo adecuadamente. El script lo he llamado crear_servidor_virtual.rb. Puedes hacer un checkout del proyecto y pillar todo el código en el RubyForge. En unos meses espero ya tener una versión mucho más pulida, adaptable, empaquetada como gema y haciendo uso del Bundler y estará alojada en GitHub.

Lo que he hecho es usar ERB para crear plantillas de la configuración DNS y del VirtualHost, para renderizarlas en la ejecución del script e incluirlas en los ficheros correspondientes de la carpeta etc.

Para recordar que modificaciones había que hacer en la configuración del servidor DNS puedes ver mi artículo anterior.

Las plantillas las situo (manualmente) en la carpeta del servidor que denomino /etc/scripts, donde se encuentran los ficheros de configuración o datos que usan mis scripts.

dns_zone.erb


 zone "<%= project_id %>.it7" {
   type master;
   file "/etc/bind/db.<%= project_id %>.it7";
 };

Ésta es para la inclusión de la nueva zona en el fichero named.conf.local.

db_local.erb


 ;
 ; BIND data file for local loopback interface
 ;
 $TTL 604800
 @ IN SOA ns.<%= project_id %>.it7. ejosafat.it7.info. (
          2  ; Serial
     604800  ; Refresh
      86400  ; Retry
    2419200  ; Expire
     604800 ) ; Negative Cache TTL
 ;
 @ IN NS ns.<%= project_id %>.it7
 @ IN A 192.168.50.53
 <% users.each do |u| %>
 <%= u %>    IN A 192.168.50.53
 <% end %>
 ns IN A 192.168.50.53
 @ IN AAAA ::1

Esta es para la generación del fichero db.nombredeproyecto.it7. Para cada usuario en el sistema se genera una entrada A para su subdominio correspondiente. No hace falta declarar la resolución inversa de la IP, eso solo hace falta hacerlo para el dominio principal, goldberg.it7 (ver artículo anterior)

virtual_host.erb

Y esta es la plantilla para crear el servidor virtual del apache, una entrada para cada usuario. Si el proyecto es rails, en el DocumentRoot añado la carpeta public a la ruta.


 <VirtualHost *>
   ServerName <%= user %>.<%= project_id %>.it7
   DocumentRoot /home/<%= user %>/<%= user %>.<%= project_id %>.it7<%= '/public' if type == 'rails' %>
   <Directory /home/<%= user %>/<%= user %>.<%= project_id %>.it7>
     Options FollowSymLinks
     AllowOverride All
     Options -MultiViews
   </Directory>

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
     AllowOverride None
     Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
     Order allow,deny
     Allow from all
   </Directory>

   ErrorLog /home/<%= user %>/apache2.<%= project_id %>.error.log

   # Possible values include: debug, info, notice, warn, error, crit,
   # alert, emerg.
   LogLevel warn

   CustomLog /var/log/apache2/access.log combined
   ServerSignature On
 </VirtualHost>

crear_servidor_virtual.rb

Como siempre, el script en sí no tiene mucha ciencia:


 check_usage(1, "Usage: crear_servidor_virtual.rb <id de proyecto> [type]")
  id_proyecto = ARGV[0]
  # El tipo por defecto será rails.
  type = ARGV[1] || 'rails'

El script se invoca con un ide proyecto y opcionalmente un tipo. Si no se especifica nada, se asume que es un proyecto rails. La otra opción permitida será php, aunque esto realmente no lo compruebo. Si el usuario no escribe nada como segundo argumento, el servidor virtual apuntará a la subcarpeta public del proyecto, y si pone cualquier cosa apuntará a la carpeta raíz del proyecto.


 users = IO.readlines(USERS_LIST_PATH).each(&:chomp!)
 if IO.read(NAMED_CONF_PATH) !~ /#{id_proyecto}/
    open(NAMED_CONF_PATH, 'a') {|f| f << Project.get_dns_zone(id_proyecto) << "\n"}
  end
 Project.create_db_local(id_proyecto, users)
 `sudo /etc/init.d/bind9 restart`

Tras leer la lista de usuarios, añadiré la entrada de zona al named_conf. Creo el fichero db oportuno para el dns y reinicio el servidor. El método create_db_local tiene esta forma:


 def self.create_db_local(project_id, users)
    # Cargar plantilla
    template = ERB.new(IO.read(DB_LOCAL_TEMPLATE_PATH))
    # Renderizar plantilla y grabarla en disco
    db_local = "#{DB_LOCAL_PATH}db.#{project_id}.it7"
    open(db_local, "w") {|f| f << template.result(binding)} if !File.exists? db_local  end

Simplemente renderiza la plantilla y escribe el fichero en disco a no ser que ya exista de antes.


 vh = ''
  users.each do |u|
    vh += Project.get_vhost({:project_id => id_proyecto, :user => u, :type => type.downcase})
  end
  # localizar último número
  sites = Dir.entries('/etc/apache2/sites-available').reject {|f| f =~ /^\.{1,2}$/ || f =~ /default/}
  # los 3 primeros caracteres del nombre del servidor virtual son el número de secuencia, leemos y asignamos el siguiente.
  last_number = sites.sort.last[0,3].succ
  # crear fichero
  new_vh = "/etc/apache2/sites-available/#{last_number}-#{id_proyecto}"
  open(new_vh, 'w') {|f| f << vh} unless File.exists? new_vh
  # enlazar en enabled
  `sudo a2ensite #{last_number}-#{id_proyecto}`
  # recargar apache
  `sudo /etc/init.d/apache2 reload`

Aquí creo el fichero con los servidores virtuales de apache correspondientes a cada usuario. Quizás lo que es más truculento es nombrar el fichero. En mi empresa (y en muchas otras) seguimos la convención de usar numeración consecutiva para los ficheros de servidores virtuales, por lo que primero tengo que detectar el número del último fichero generado para incrementarlo en uno para asignarselo al nuevo. El renderizado del VirtualHost específico para un usuario se hace en la llamada del método get_vhost:


 def self.get_vhost(options)
    # Cargar plantilla
    template = ERB.new(IO.read(VH_TEMPLATE_PATH))
    user = options[:user]
    type = options[:type]
    project_id = options[:project_id]
    template.result(binding)
  end

Conclusión

Con esto automatiza una de las partes más engorrosas y que menos me gustaba a la hora de generar la infraestructura necesaria para el desarrollo del proyecto, y por aquí todos son más felices cuando les digo que generen los servidores virtuales.
En próximos artículos hablaré de otros pequeños scripts accesorios que también me han facilitado esas tareas rutinarias y aburridas, haciéndome un programador más contento :-)

Creación de servidores virtuales (I)

2010-04-08T14:40:00.001+01:00

¿Cansado de crear a mano los servidores virtuales del Apache para cada proyecto con sus correspondientes entradas DNS en el servidor de desarrollo local? Yo lo estaba, así que decidí resolverlo con este script.

Recapitulando

El modus operandi en mi empresa a la hora de trabajar un proyecto es el siguiente: en el servidor de desarrollo, en la carpeta home de cada usuario, se crea una carpeta para cada proyecto, de la forma nombreDeUsuario.nombreDeProyecto.it7, por ejemplo ejosafat.ciu2010.it7; esa es la copia de trabajo subversion de cada uno.

Cada usuario visualiza su trabajo con el navegador accediendo a la url http://nombreDeUsuario.nombreDeProyecto.it7 correspondiente. Para que esto sea posible, se deben dar dos condiciones:

Que haya un servidor DNS que reconozca la url y encamine el navegador hacia el servidor de desarrollo.
Que haya creado un servidor virtual en el Apache que responda a esa dirección sirviendo los archivos de la carpeta correspondiente.

Primero veremos como sería la forma manual de hacerlo (incluyendo la configuración del servidor DNS en el servidor de desarrollo local) y después el script para automatizar dicha generación.

Dada la extensión de este artículo, lo dividiré en dos partes. En ésta hablaré de la configuración DNS, y en el siguiente la configuración de los virtual host en el apache y el script que automatiza la generación.

Objetivos

Configurar servidor DNS
Crear un script que automatice tanto la creación de la entrada DNS correspondiente a cada proyecto como la generación del servidor virtual en el Apache.

Paso a Paso

DNS

Para configurar el servidor DNS, hay un buen artículo al respecto en la guía del servidor de la Ubuntu 9.10. Resumiré aquí lo que me interesa para la configuración de mi servidor de desarrollo.

Lo primero de todo es configurar cuales serán los servidores DNS que consultará el propio servidor. Hay que editar el fichero /etc/resolv.conf, y sustituir lo que haya por la dirección IP del propio servidor, ya que será el que tenga que resolver las direcciones de los proyectos que trabajamos en el entorno local. A continuación, en caso de que el servicio DNS falle, ponemos la de otros servidores conocidos (en mi caso uso los de Telefónica generalmente).


  nameserver 192.168.50.53
  nameserver 194.179.1.100
  nameserver 194.179.1.101

El primer paso es configurar el servidor de desarrollo como forwarder de DNS. Es decir, que cuando le llegue una petición de resolución de nombres, si él no puede resolverla (cosa que pasará con cualquier dominio que no sea de los que usaremos para el desarrollo local), haga la petición a otro servidor DNS y cachee la respuesta, de tal manera que en sucesivas peticiones al mismo dominio externo obtengamos la respuesta de nuestro propio servidor, que ya conocerá la ip a la que resuelve el nombre, por haberla buscado anteriormente.

Lo primero es configurar para que reconozca el dominio personalizado que usaremos para conectar con el servidor de desarrollo en general, al margen de cualquier proyecto, bien sea por ssh o via web para utilizar el phpmyadmin, por ejemplo.

Hay que editar el fichero /etc/bind/named.conf.local y añadir lo siguiente (el nombre local de la máquina es goldberg, y el sufijo que usaremos para todos los dominios es it7):


  zone "goldberg" {
    type master;
    file "/etc/bind/db.goldberg.it7";
  };

y su resolución inversa correspondiente:


  zone "50.168.192.in-addr.arpa" {
    type master;
    notify no;
    file "/etc/bind/db.192";
  };

Hay que crear los dos ficheros referenciados, ambos en la carpeta /etc/bind. Para crear el fichero db.192, lo más cómodo es copiar uno que se habrá creado en la instalación del servidor, db.127, y modificarlo para dejarlo así:


  $TTL    604800
  @       IN      SOA     .goldberg.it7. ejosafat.it7.info. (
  1         ; Serial
  604800         ; Refresh
  86400         ; Retry
  2419200         ; Expire
  604800 )       ; Negative Cache TTL
  ;
  @       IN      NS      .
  53      IN      PTR     .goldberg.it7.

Para crear db.goldberg.it7, lo más sencillo también es copiar otro que ya existirá, db.local y modificarlo, para dejarlo de la siguiente manera:


  ;
  ; BIND data file for local loopback interface
  ;
  $TTL 604800
  @ IN SOA ns.goldberg.it7. ejosafat.it7.info. (
           2  ; Serial
      604800  ; Refresh
       86400  ; Retry
     2419200  ; Expire
      604800 ) ; Negative Cache TTL
  ;
  @ IN NS ns.goldberg.it7
  @ IN A 192.168.50.53
  @ IN AAAA ::1
  ns IN A 192.168.50.53

posteriormente, para cada proyecto que se vaya a emprender, hay que crear también la correspondiente entrada en /etc/bind/named.conf.local, de la misma manera. Por ejemplo, para un proyecto denominado prueba:


  zone "prueba.it7" {
    type master;
    file "/etc/bind/db.prueba.it7";
  };

Y hay que crear db.prueba.it7, para ello se puede copiar el fichero db.golberg.it7 y realizar los siguientes cambios:

sustituir goldberg por prueba
Añadir debajo de la línea @ IN A 192.168.50.53 una línea para cada subdominio (desarrollador que va a trabajar en el proyecto) de la forma <nombre de usuario> IN A 192.168.50.53. Por ejemplo, para eddy, usaríamos eddy IN A 192.168.50.53

Conclusión

De esta manera se pueden ir creando todos los dominios que necesite para el desarrollo de los diversos proyectos. Más de un administrador de sistemas se tirará manos a la cabeza leyendo lo anterior, ya que no hablo del incremento del número Serial, y probablemente haya otra forma más elegante de hacerlo, pero soy programador, no sysadmin, a mí así me vale!

En el próximo artículo configuraré el Apache para responder a esas direcciones y utilizaré un script para automatizar tan tediosa tarea.

Backup via FTP automatizado con Ruby

2010-03-19T15:23:00.000Z

Recapitulando

Ya están las carpetas de trabajo de los usuarios de la empresa en el servidor de desarrollo (Goldberg), el repositorio subversion local sincronizado con el de Dreamhost, y además se hace una exportación de todos los proyectos todas las noches. El siguiente paso es hacer una copia de seguridad de todo esto, junto con la configuración de Goldberg.

En la empresa donde trabajo actualmente, tienen un servidor Windows 2003 Server con una unidad de cinta que copia los contenidos de su disco duro y de algunos más en distintos ordenadores de la red interna (todos Windows, of course, a los usuarios de Mac y Linux que nos den!). Lo que voy a hacer es crear un script que coja el contenido de varias carpetas seleccionadas y las mande por FTP a una de las máquinas cuya información entra en la copia de seguridad.

Objetivos

Quiero que todas las noches se copien las carpetas importantes del servidor de desarrollo en otra máquina, via FTP.

Paso a Paso

La lista de carpetas a exportar las pongo en un fichero de texto ubicado en la carpeta /etc/scripts del servidor de desarrollo, con el nombre backup_folders. Las carpetas importantes en mi caso son:


  /etc (ficheros de configuración del servidor)
  /home/eddy  (carpetas de trabajo de los usuarios)
      .....
  /var/exported_projects (copia en limpio de los proyectos)
  /var/subversion (carpeta donde se encuentran los repositorios)

Por otro lado, tenemos en la oficina una máquina Windows con un servidor FTP instalado, sin cuentas, permitiendo la subida anónima de ficheros. La carpeta donde se almacenan las subidas entra en la copia en seguridad en cinta que realiza el servidor Windows 2003 Server de la empresa.

Automatización

El script backup.rb se encarga de realizar la tarea de comprimir las carpetas especificadas en el fichero /etc/scripts/backup_folders, especificado en la constante BACKUP_LIST_PATH, y enviarlas por ftp a una máquina especificada. Puedes bajarte estos scripts desde rubyforge.


  folder_list_file = ARGV[0] || BACKUP_LIST_PATH
  tmp_folder = ARGV[1] || '/tmp'
  Net::FTP.open('192.168.50.102') do |ftp|
    ftp.login
    File.open(folder_list_file).readlines.each do |line|
      line.chomp!
      puts "tar #{line}"
      line =~ /([_a-z]*)$/
      filename = $1
      `tar -cz #{line} > #{tmp_folder}/#{filename}.tgz`
      ftp.putbinaryfile "#{tmp_folder}/#{filename}.tgz"
      `rm #{tmp_folder}/#{filename}.tgz`
    end

El script no tiene mucha ciencia: abre una conexión ftp con la máquina en cuestión, y para cada una de las carpetas especificadas realiza la compresión en la carpeta temporal del sistema, envía el fichero tgz creado a la máquina FTP y tras esto lo borra de la carpeta temporal.

Tras meter una entrada en el crontab para que todas las noches llame al script, ya solo queda revisar los emails que envia el servidor de desarrollo para comprobar que la copia se está realizando correctamente y dormir tranquilo!

Conclusión

Voy a convencer a mi empresa para usar el Amazon S3 como backup alternativo, con lo que más adelante cambiaré todo esto. De momento me aseguro de tener lo esencial del servidor de desarrollo a salvo en otra máquina y en cinta, y sigo moviéndome adelante. Lo próximo: scripts para crear servidores virtuales de apache (incluyendo sus correspondientes entradas dns) para cada proyecto que se empiece.

En defensa de los derechos fundamentales en Internet

2010-03-19T10:13:00.000Z

Ante la inclusión en el Poyectroyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de Internet manifestamos nuestra firme oposición al proyecto, y declaramos que:

Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Exportación de repositorios con Ruby

2010-02-27T00:18:00.000Z

Recapitulando

En el artículo anterior, crée la infraestructura básica para los scripts de automatización de las tareas relacionadas con proyectos. Una vez solucionado el tema de sincronizar los repositorios subversion de Dreamhost y local, le toca el turno al script para exportar los proyectos y tener una copia en limpio que entre en la copia de seguridad de la empresa.

Objetivos

Tener un script que realice la exportación automática de todos los proyectos que se encuentran en el repositorio subversion, para tener una copia en limpio de ellos para entrar en la copia de seguridad diaria de la empresa.

Paso a paso

Previamente preparo una carpeta para alojar los proyectos exportados:


  sudo mkdir /var/exported_projects
  sudo chgrp www-data /var/exported_projects
  sudo chmod g+w /var/exported_projects

Para exportar un proyecto el comando a usar es:


  svn export http://urlrepositorio.com/proyecto/trunk /var/exported_projects/proyecto

Lo cual exportaría el proyecto en la carpeta del mismo nombre. Una vez más, hacer esto manualmente todos los días para todos los proyectos sería desquiciante.

Automatización

Basándonos en el código visto en el artículo sobre la automatización de la sincronización de repositorios subversion, basta añadir un método a la clase Repository para hacer la exportación. Puedes descargarte el código en el RubyForge.


  def export(options = {})
    `cd #{options[:folder]}; rm -rf #{options[:project_id]}; svn export --username #{options[:username]} --password #{options[:password]} #{@url}/#{options[:project_id]}/trunk #{options[:project_id]}` =~ /exported/i
  end

Este método acepta como parámetros la carpeta donde se almacenan los proyectos exportados (:folder), el id del proyecto (:project_id), el nombre de usuario para conectarse al servidor subversion y su contraseña (:username, :password), devolviendo verdadero o falso.

A continuación el script para realizar la exportación, mismo mecanismo que los anteriores scripts. Apoyándose en un fichero de texto que incluye un listado de proyectos activos, el script exportar_repositorios.rb sencillamente va proyecto a proyecto exportandolos en la carpeta especificada.

El script acepta como argumentos obligatorios el usuario y la contraseña con la que conectarse al repositorio, y como opcionales la ruta hacia el listado de proyectos y la carpeta donde exportarlos. No hay nada extraño en el script, salvo la línea:


  ENV['LC_CTYPE'] = 'en_US.UTF-8'

que tuve incluir porque tenía problemas con las diferencias de codificación entre el servidor de Dreamhost y el mio. Aquí el código del script:


  if $0 == __FILE__
    with_pleasant_exceptions do
      check_usage(2, 'Uso: exportar_repositorios.rb   [ruta hacia el listado de proyectos] [carpeta de exportación]')
      proyectos = Project.new(:list_path => ARGV[2], :export_path => ARGV[3])
      user = ARGV[0]
      password = ARGV[1]
      # actualizar repositorio para cada proyecto de la lista
      failed_exports = []
      ok_exports = []
      repository = Repository.new
      # Solucionar problemas en la exportación por incompatibilidad de caracteres
      ENV['LC_CTYPE'] = 'en_US.UTF-8'

      proyectos.list.each do |proyecto|
        # Problemas en el repositorio de Dreamhost hace que el project_id para la linea de comandos y el usado en el
        # nombre del repositorio difieran
        proyecto[:project_id] = 'seguridad' if proyecto[:project_id] == 'canariassegura'
        if repository.export(:folder => proyectos.export_path, :project_id => proyecto[:project_id], :user => user, :password => password)
          ok_exports << proyecto[:project_id]
        else
          failed_exports << proyecto[:project_id]
        end
      end
      puts "Proyectos exportados:\n"
      puts ok_exports
      puts "Proyectos no exportados:\n"
      puts failed_exports
    end
  end

Hay una línea en concreto que es para solucionar un problema que tuvimos en Dreamhost con un proyecto en concreto:


  proyecto[:project_id] = 'seguridad' if proyecto[:project_id] == 'canariassegura'

La incluyo por la coña más que nada, porque casi toda la gente que conozco tiene más de un muerto de estos en su armario! ;-)

Conclusión

Una vez metemos en el crontab la línea para llamar a este script y realizar una exportación todas las noches, lo siguiente es preparar un script que coja estos ficheros y los cuelgue via ftp en una máquina cuyo disco duro si que entra en la copia de seguridad diaria del servidor principal de la empresa. (para más información de contexto, ver el artículo introductorio de este blog)

Automatizando el volcado de repositorios

2010-02-18T11:03:00.000Z

Recapitulando

En el artículo anterior, establecí un repositorio en el servidor de desarrollo local, Goldberg, que se sincroniza con el repositorio principal situado en Dreamhost. Comenté los comandos del subversion necesarios para realizar dicha tarea; tales comandos, ejecutados manualmente y a diario, pueden consumir bastante tiempo, el cual es más rentable si lo invertimos en tareas creativas, complejas y divertidas, por lo que he desarrollado unos sencillos scripts que ejecutarán dichas tareas por mi.

Objetivos

Crear scripts para realizar la sincronización entre ambos repositorios. Serán ejecutados desde el crontab.
Crear la infraestructura de soporte para dichos scripts y los sucesivos que ire desarrollando en mis tareas de automatización.

Consideraciones

El lenguaje de implementación de los scripts es Ruby. ¿Por qué? Pues porque hace mucho tiempo que no me divertía programando, ya se me hacía pesadísimo, y este lenguaje devuelve la sonrisa a tu rostro a medida que te familiarizas con el y te enamoras del código que vas creando, mucho más compacto, más legible, más flexible, más.... que en los otros lenguajes que conozco. Actualmente estoy explorando otros, como el Clojure, para abordar otros paradigmas de programación de manera agradable también. Para aquellos que quieran aprender Ruby (lo cual recomiendo) se puede acceder de forma gratuita al libro (disponible online gratuitamente) Programming Ruby, del cual hay una versión (no gratuita) más reciente que incluye la versión 1.9 de este lenguaje. Los scripts están desarrolados con la 1.8.7. Más información sobre Ruby, en la página del lenguaje.

Inicialmente desarrollé las clases y scripts de manera "dispersa", por decirlo de alguna manera, mientras leía el libro de Brian Marick titulado Everyday Scripting with Ruby: for Teams, Testers, and You. Tras haber mejorado mis habilidades como scripter, decidí empaquetarlo todo en un módulo al que denomino Proyectos, que incluye los scripts que iré presentando en este blog así como las clases en las que se apoya.

He creado un proyecto en el RubyForge denominado autom-proyectos, donde puedes descargarte el paquete. En la página del proyecto verás como hacer checkout del repositorio y tener siempre la última versión del código que voy desarrollando en este blog.

s4t-utils

Para la estructuración del paquete me baso en librería mencionada en el libro de Brian Marick (comentado anteriormente). Esta utilidad no solo te genera automáticamente la estructura, sino que se incorpora a él para proporcionar una serie de facilidades de programación (ajustar paths, facilidades para el testing, etc...). Otra alternativa hubiera sido distribuirlo como gema, pero eso ya lo haré más adelante.

En la carpeta bin se sitúan los scripts que realizan las distintas acciones, y en la carpeta lib, los ficheros que forman el módulo Proyectos, que da soporte a dichas utilidades, con las clases Project y Repository (no estaba muy inspirado el día que elegí los nombres).

Así mismo tenemos la carpeta doc, con la documentación del módulo en formato html y que se puede regenerar en cualquier momento sitúandonos en la carpeta raíz del paquete y ejecutando:

rake rdoc

Por último, en la carpeta test encontramos los tests del módulo. A continuación voy a explicar los ficheros principales, pero no mostraré todo el código para no hacer esto eterno. Descárgate las fuentes en el RubyForge. Me limitaré a comentar algunos fragmentos y en bastantes de ellos incluyo los comentarios del código para explicarlo.

Puedes ejecutar los scripts desde la línea de comandos con Ruta hacia la carpeta del módulo/bin/volcar_repositorios.rb o ejecutar (como sudo) rake install desde la carpeta raíz del proyecto.

Módulo Proyectos (lib/proyectos.rb)

Aquí defino los valores predeterminados de configuración. Para personalizar no hay más que cambiar el valor de las variables. Así vale, aunque lo ideal a medida que se incluyan más rutas y se vaya generalizando es cambiar estas constantes por un fichero de configuración YAML.

Aquí se define también el método check_usage:


def check_usage(num_required_args, message)
  unless ARGV.length >= num_required_args
    puts message
    exit
  end
end

Este método es invocado por aquellos scripts que requieran argumentos obligatorios a la hora de ejecutarse. Si el número de argumentos presentes en la línea de comandos del script es inferior al de los que requiere, muestra por pantalla el mensaje especificado y termina la ejecución del script.

Project (lib/proyectos/project.rb)

Esta clase gestiona el acceso al listado de proyectos, de momento es muy simple pero con el tiempo evolucionará (y probablemente se renombrará, en realidad debería haberse llamado ProjectList o algo similar en su actual encarnación) para acomodar todo el modelado de la generación automática de proyectos.

Tiene tres atributos, que son las rutas hacia ficheros o carpetas relevantes. En la inicialización, si no se ha definido alguna de estas rutas se cogen los valores por defecto establecidos en la declaración del módulo Proyectos.


attr_accessor :list_path, :export_path, :dump_path

# No comprueba la existencia de las carpetas. Se manejarán las excepciones en cada caso.
# Los atributos tomaran el valor especificado por defecto en la definicion del modulo o los indicados en options.
# * :list_path => Fichero con el listado de proyectos existentes
# * :export_path => Carpeta para la exportacion de proyectos
# * :dump_path => Carpeta para el volcado de repositorios
def initialize(options = {})
  @list_path = options[:list_path] || PROJECT_LIST_PATH
  @export_path = options[:export_path] || EXPORTED_PROJECTS_PATH
  @dump_path = options[:dump_path] || SVN_DUMP_PATH
end

Y define un único método, que accede al listado de proyectos para devolverlo en forma de array. El fichero de lista de proyectos es un fichero de texto donde en cada línea se encuentra el identificador del proyecto, seguido de : y el número de la última revisión existente en el repositorio local. Cuando se inicia un proyecto nuevo, se añade una entrada a la lista con el identificador seguido de :0. Se puede ver un ejemplo en /test/data/project_list.


# Devuelve un array de proyectos, cada uno especificado por un hash con las claves
# * :project_id, que es la cadena identificativa del proyecto.
# * :revision, ultima revision almacenada en el repositorio del servidor de desarrollo local.
def list
  lista = []
  File.open(@list_path).readlines.each do |linea|
    proyecto = linea.chomp.split(':')
    lista << {:project_id => proyecto[0], :revision => proyecto[1].to_i}
  end
  lista
end

Repository (lib/proyectos/repository.rb)

Esta clase gestiona el acceso al repositorio subversion. Todas las operaciones las realiza invocando comandos del shell.

Tiene un solo atributo, que indica la url del repositorio. Si no se especifica un valor por defecto en la inicialización, coge el establecido por defectos en la definición del módulo Proyectos.


attr_accessor :url

# Crea una instancia vinculada a un repositorio especificado en la construccion
# o el establecido por defecto para el modulo.
# * url = url del repositorio, incluyendo la parte del protocolo.
def initialize(url = nil)
  @url = url || DEFAULT_REPOSITORY
end

El método que realiza el volcado de un repositorio especificado por un identificador, en la carpeta especificada entre dos revisiones. Lo único que hacemos es invocar el comando de sistema svnadmin dump


# Vuelca un conjunto de revisiones de un proyecto. El fichero se denominara svn. seguido del valor de :project_id
# options debe ser:
# * :project_id => Identificador del proyecto
# * :rstart => Revision de comienzo
# * :rend => Revision final
# * :folder => Carpeta donde se almacena el volcado
def dump(options = {})
  `svnadmin dump #{@url}/#{options[:project_id]} --incremental --revision #{options[:rstart]}:#{options[:rend]} > #{options[:folder]}/svn.#{options[:project_id]}`
end

Este es el método para cargar un volcado en un repositorio, necesita tan solo conocer la carpeta destino y el identificador de proyecto. Tira del comando svnadmin load


# Carga un fichero de volcado de transacciones de un repositorio subversion.
# options debe ser:
# * :folder => carpeta en la que se encuentra el volcado.
# * :project_id => cadena identificadora valida de un proyecto.
# El nombre del fichero que espera encontrar el metodo es svn. seguido por el valor de :project_id.
def load(options = {})
  `svnadmin load #{@url}/#{options[:project_id]} < #{options[:folder]}/svn.#{options[:project_id]}`
end

El siguiente método es el que permite obtener cual es la última versión en un repositorio. Se utiliza para comparar esta versión con la presente en el fichero de lista de proyectos y poder averiguar entre que revisiones debe hacerse el volcado.


# Devuelve entero indicando ultima revision del repositorio
# * project_id = cadena identificadora valida de un proyecto.
def last_revision(project_id)
  `svnlook youngest #{@url}/#{project_id}`.chomp.to_i
end

Los scripts

volcar_repositorios.rb (bin/volcar_repositorios.rb)

Este es el script que realiza el volcado de los repositorios de Dreamhost. Se sube este paquete y se ejecuta, incluyéndolo en el crontab. No voy a explicar como se hace, puedes verlo en este tutorial. Los comentarios explican lo suficientemente bien el código:


# Obtener lista de proyectos y revisiones
proyectos = Project.new(:list_path => '/home/cuentait7/etc/project_list', :dump_path => '~/svndumps')
repositorio = Repository.new('/home/cuentait7/svn')

 # Para cada proyecto realizar el volcado en la carpeta correspondiente
 proyectos.list.each do |proyecto|
   # Ver cual es la revisión actual, obteniendo la información del repositorio que se va a volcar
   actual = repositorio.last_revision(proyecto[:project_id])
   # Ver cual es la revisión de Goldberg, información obtenida de la lista de proyectos
   previa = proyecto[:revision]

   # Hacer el volcado entre la siguiente revisión a la que está en Goldberg y la actual
   if previa != actual
     puts "volcando #{proyecto[:project_id]}"
     repositorio.dump(:project_id => proyecto[:project_id], :rstart => previa + 1, :rend => actual, :folder => proyectos.dump_path)
   end 
 end

cargar_repositorios.rb (bin/cargar_repositorios.rb)

Primero establecemos la lista, el repositorio, la carpeta donde se realiza el volcado en Dreamhost....


proyectos = Project.new
repositorio = Repository.new('/var/subversion')
lista = proyectos.list
dh_folder = '/home/cuentait7/svndumps'

A continuación abro una conexión ssh, usando como identificador la clave que generé cuando instalé el servidor.


Net::SSH.start('greene.dreamhost.com', 'cuentait7', {:keys => ['/home/eddy/.ssh/id_rsa']}) do |ssh|
  puts "Conexión realizada con éxito"
  lista.each do |proyecto|

Para cada proyecto que hay en la lista, hay que:

Establecer las rutas hacia el fichero remoto y hacia el local.
dh_project_url = "#{dh_folder}/svn.#{proyecto[:project_id]}" local_project_url = "#{proyectos.dump_path}/svn.#{proyecto[:project_id]}"
Si existe un volcado del proyecto en cuestión lo descargamos.
if ssh.exec!("ls #{dh_project_url}") !~ /No such/ # obtener el fichero de Dreamhost ssh.sftp.download!("#{dh_project_url}", local_project_url)
Aquí utilicé sftp en lugar de scp porque para ficheros muy grandes se me cortaba.
Eliminar el volcado arriba.
ssh.exec!("rm #{dh_project_url}")
Cargarlo en el servidor de desarrollo local y actualizar el número de versión del proyecto en la lista.
repositorio.load(:project_id => proyecto[:project_id], :folder => proyectos.dump_path) # actualizar version proyecto[:revision] = repositorio.last_revision(proyecto[:project_id])
La lista está actualizada está en un array, la volvemos a escribir en el fichero.
File.open(proyectos.list_path, 'w') do |f| lista.each { |l| f << l[:project_id] << ':' << l[:revision] << "\n" } end
Subir la nueva versión del proyecto actualizado a Dreamhost.
ssh.scp.upload!(proyectos.list_path, '/home/cuentait7/etc')

Notas

En lugar de usar comandos de shell directamente, podría haber usado los subversion-bindings, disponible para varios lenguajes de programación entre ellos Ruby. El problema es que requiere que el usuario los tenga instalado en su sistema, por lo que opté por una solución autosuficiente. De hecho, las gemas de las que depende este módulo (net-ssh, net-scp, etc...) vienen también incluidas por la misma razón.

Ante todo soy pragmático, escribí estos scripts para usarlos en mi entorno de trabajo actual, por lo que hay muchas rutas a carpetas y ficheros en el código puestas a piñón fijo. A medida que necesite generalizarlo lo hiré haciendo, hasta entonces, ¿para qué preocuparse?

Tampoco hago manejo de excepciones. El usuario de los scripts se supone que es un programador o diseñador/maquetador que lanzará los comandos desde la consola de manera más o menos inteligente, y con la mínima capacidad de entender lo que pasa si se encuentra con algún error. Mi idea es que este conjunto de scripts evolucione hasta una interfaz web para que cualquiera de la empresa pueda lanzar los procesos de configuración de software necesarios para lanzar y desplegar un proyecto, será entonces cuando me preocupe de eso.

Conclusión

Ya tengo un par de scripts para automatizar la tarea de sincronización de repositorios, y la infraestructura base (módulo Proyectos) para seguir desarrollando más. Como paranoico del backup, y no satisfecho con la redundancia obtenida hasta ahora, la siguiente tarea es hacer una exportación (código en limpio, sin los ficheros de control .svn) de la última versión de los proyectos para que entre en la copia de seguridad diaria de la empresa, tarea que por supuesto será automatizada también. ¡Pero eso lo dejo para el próximo artículo!

Estableciendo un repositorio subversion local como backup del principal

2010-01-29T15:08:00.001Z

Recapitulando

Hemos estado siguiendo desde el primer artículo de este blog, el proceso que he seguido para ir modernizando los procesos productivos de la empresa donde trabajo y automatizar gradualmente el trabajo del día a día.

Tras instalar el servidor de desarrollo, denominado Goldberg, lo configuramos para conectarse via ssh sin usar contraseña al servidor contratado por la empresa en Dreamhost.

Es en Dreamhost donde se encuentran los repositorios subversion de los proyectos. El control de versiones del código es esencial para la salud del programador; podría contar la infinidad de veces que eso me permitió deshacer algún cambio que produjo más problemas que soluciones, o que me permitió ahondar en la posible fuente de algunos bugs, así como permitir el trabajo compartido en el mismo código evitando las miradas asesinas porque alguién sobreescribió los cambios de otra persona (algo que suele suceder cuando todo el mundo trabaja sobre la misma carpeta compartida en los mismos ficheros).

Objetivos

Nuestro objetivo es establecer la configuración de trabajo del control de versiones:

Repositorios principales situados en Dreamhost, para que cualquier miembro de la empresa pueda acceder desde cualquier punto (yo a veces trabajo desde casa, por ejemplo)
Tener una réplica de esos repositorios en el servidor de desarrollo local, tanto como copia de seguridad como para si cae la conexión en Dreamhost poder seguir trabajando con el local.

Configuración de los repositorios en Dreamhost

Crear un repositorio en Dreamhost es sencillo, no tienes más que utilizar la opción Subversion del menú Goodies, situado a la izquerda en el panel de control.

La convención que seguimos para la nomenclatura de los proyectos es asignarles un id formado por un nombre fácil de recordar, que puede ser simple o formado por palabras compuestas, unidas con o sin carácter subrayado, somos bastante flexibles al respecto. Ese id lo utilizaremos más adelante tanto para los repositorios locales como para los servidores virtuales del apache y la nomenclatura de las bases de datos.

Una vez creado el repositorio en Dreamhost, desde una consola seguimos la convención tradicional de crear tres carpetas principales, trunk, tags y branches. El por qué de esas carpetas y cual es su uso determinado es un poco largo de explicar aquí, en algunos proyectos son útiles y en otros solo usarás el trunk y no te complicarás la vida. A nivel personal, yo he tenido que usar el modelo completo de carpetas. Para una explicación más detalla, puedes googlear un poco o leerte el libro Pragmatic Version Control using Subversion, 2nd Edition. Aún así, si estás muy interesado en saber más, también puedes preguntarme ;-).

Cuando creamos el repositorio en Dreamhost, pasados unos minutos (depende de como esté de cargado el servidor) ya estará listo para su uso. Te llegará un mail notificándotelo. Para el siguiente paso, podemos hacerlo desde un acceso ssh al servidor de desarrollo (Goldberg), o desde nuestra propia máquina abriendo una ventana de terminal, en cuyo caso tenemos que tener instalado el Subversion en nuestra máquina, en el caso de trabajar en Linux instalar el paquete subversion; en un Mac, podemos instalarlo a través del MacPorts, en el caso de Windows, bueno, mejor cambia de entorno de desarrollo, para un programador no es el óptimo.

Asumiendo un proyecto que hemos identificado como prueba, ejecutamos:


  svn mkdir --message "Initial project layout" http://misvn.dreamhosters.com/prueba/trunk http://misvn.dreamhosters.com/prueba/branches http://misvn.dreamhosters.com/prueba/tags

El mensaje de creación inicial puedes ponerlo en español, si quieres ("Estructura inicial del proyecto"), e incluso puedes poner lo que quieras, yo suelo seguir esa convención. Generalmente tanto los mensajes del repositorio como los comentarios del código suelo escribirlos en inglés, por eso de ser casi un estándar en el mundo de la programación en internet, aunque el código que muestre en este blog siempre estará en español.

A partir de aquí, lo siguiente que hacemos es hacer un checkout de la carpeta trunk, y añadir los ficheros iniciales del proyecto, pero todo el proceso de generación inicial del proyecto lo veremos en otro artículo, para centrarnos en el aspecto de la sincronización del control de versiones.

Instalación y configuración del repositorio en el servidor de desarrollo local

El Subversion puede utilizarse como servidor directamente, por medio del proceso svnserve, pero ya que tenemos un Apache instalado es más cómodo y práctico utilizar éste para recibir las peticiones.

Si has seguido la serie de artículos desde el principio, ya habrás instalado los paquetes necesarios, si no, has de instalar el servidor Subversion y la librería necesaria para servir los repositorios a través del Apache. En cualquier caso, el comando para hacerlo sería:

sudo apt-get install subversion libapache2-svn

A continuación, creamos la carpeta donde se alojarán los repositorios locales:

sudo mkdir /var/subversion

Para cada proyecto, crearemos el repositorio, siguiendo con el ejemplo de nuestro proyecto prueba:

sudo svnadmin create /var/subversion/prueba
sudo chown -R www-data:www-data /var/subversion/prueba

Hay que habilitar cada usuario y asignarle una contraseña (ejemplo para el usuario eddy):

sudo htpasswd -c /etc/subversion/passwd eddy

Por último, hay que editar el fichero /etc/apache2/apache2.conf y añadir lo siguiente (tras lo cual reiniciaremos el Apache):

<Location /svn>
DAV svn
SVNParentPath /var/subversion
SVNListParentPath On
AuthType Basic
AuthName "Texto que quieras aquí"
AuthUserFile /etc/subversion/passwd
<limitexcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>

Una vez se hayan importado los repositorios, se puede conectar desde cualquier máquina cliente usando como url http://goldberg/svn/prueba

Volcado de repositorios desde Dreamhost a Goldberg

Vamos a conectarnos al servidor remoto (Dreamhost) para volcar los repositorios, luego los bajaremos via sftp y los cargaremos. Veremos primero la forma manual de hacerlo, y en el próximo artículo veremos un pequeño script en Ruby que nos automatizará esta tarea.

Lanzaremos una terminal para ejecutar los siguientes comandos:

ssh nuestrousuario@nuestroservidor.dreamhost.com

Una vez conectados a Dreamhost, para cada proyecto volcamos su repositorio en un fichero. Para nuestro proyecto denominado prueba:

svnadmin dump svn/prueba > prueba.svndump

El nombre del fichero no tiene por qué acabar en .svndump, esa es una convención que sigo yo. Por otro lado, comentar que este comando vuelca todas las revisiones del proyecto. Es más conveniente volcar solo las revisiones efectuadas posteriormente a nuestro último volcado, ya que esta es una operación que haremos periódicamente, utilizando para ello los modificadores al comando dump, --incremental y --revision <num>:<num>, donde num es el número de revisión (inicial y final). De esto hablaré en el próximo artículo cuando veamos el script para realizar esto automáticamente.

Una vez generados los volcados, los descargamos por sftp en una carpeta de Goldberg. Accedemos via ssh a Goldberg y accedemos a la carpeta donde hemos descargado los ficheros volcados, y para cada uno de ellos lanzamos el siguiente comando para cargarlo en nuestro repositorio local. En el caso del proyecto prueba:

svnadmin load /var/subversion/prueba < prueba.svndump

El comando svnadmin load carga un fichero de volcado de un repositorio en el repositorio local.

Notas

Existe otra forma de sincronizar los repositorios, mediante el svnsync, que sincroniza automáticamente los cambios. El problema es que el repositorio local que se sincroniza es de solo lectura, y nosotros queríamos usar el local no solo como copia de seguridad, sino como repositorio secundario en caso de que fallase la conexión con el mundo exterior o incluso posteriormente si queremos usar solo el local.

Conclusion

Una vez establecidos repositorios arriba y abajo, lo siguiente será automatizar el procedimiento de actualización de los repositorios, ya que realizar las cargas y volcados manualmente conlleva un coste muy alto: ¡imagina lanzar todos esos comandos aunque solo sea una vez al día cuando tienes 20 proyectos en marcha! Pero eso lo veremos en el próximo artículo.

Instalación del servidor de desarrollo (II)

2010-01-15T16:48:00.004Z

Recapitulando

En el artículo anterior, iniciamos la instalación del servidor de desarrollo con la distribución Linux Ubuntu Server 8.04. Realizamos una instalación básica, añadiendo los paquetes fundamentales que necesitamos y creamos las cuentas de usuario.

A continuación es necesario conectar el servidor con su entorno; por un lado necesitamos que se comunique con el servidor de la empresa en Dreamhost y por otro hay que facilitar el acceso al espacio de trabajo en el servidor a los distintos usuarios de la empresa.

Objetivos

Configurar el servidor de desarrollo ( Goldberg) para que se conecte via ssh con Dreamhost sin necesidad de preguntar por la contraseña. Imprescindible para que los scripts que automatizan las tareas no requieran la intervención del usuario.
Permitir a los usuarios trabajar en sus respectivas carpetas alojadas en Goldberg de manera transparente al sistema operativo que estén utilizando en sus máquinas cliente.

Conexión con Dreamhost

Accedemos via ssh a Goldberg, entramos como un usuario cualquiera (de ahora en adelante usaremos eddy en los ejemplos), y ejecutamos:


ssh-keygen -t rsa

Pulsar Enter como respuesta a las diferentes preguntas. Una vez generado, tal como configuramos el servidor en el artículo anterior, todos los ficheros creados desde cualquier usuario adquieren como grupo propietario www-data, y esto no lo consiente el agente ssh para el fichero de configuración, por lo que habremos de cambiar el grupo y hacer:


chgrp eddy .ssh/config

El paso anterior genera una clave pública que debemos copiar a dreamhost, con el comando (sustituir los datos de acceso a dreamhost por los correspondientes en el caso particular de cada uno):


scp /home/eddy/.ssh/id_rsa.pub cuentadeusuario@greene.dreamhost.com:~

Ahora conectamos con dreamhost para realizar las operaciones necesarias para habilitar la clave pública:


ssh cuentadeusuario@greene.dreamhost.com
mkdir .ssh
chmod 700 .ssh
cat id_rsa.pub > .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

Ahora ya podemos conectar desde Goldberg sin usar contraseña, añadiendo la opción -i /home/eddy/.ssh/id_rsa a los comandos ssh y scp.

Para ver más información sobre el acceso ssh, puedes consultar la guía del servidor ubuntu.

Hay que observar que esta forma de acceder no es muy segura porque estamos usando el ssh sin contraseñas de ningún tipo. Una forma más segura es usando el ssh-agent, aunque personalmente siempre lo he considerado un poco coñazo. Puedes ver como hacerlo en este artículo.

Compartir carpetas para usuarios con Linux

Para compartir las carpetas de cada usuario en Goldberg usamos el protocolo NFS. Primero instalamos en Goldberg lo necesario:


sudo apt-get install nfs-kernel-server

Luego editamos (en Goldberg) el fichero /etc/exports y añadimos al final la línea: /home *(rw,sync,no_root_squash)

Reiniciamos el servidor nfs:


sudo /etc/init.d/nfs-kernel-server restart

En la máquina de cada usuario, los pasos a seguir son, primero, instalar el paquete nfs caso de no estar instalado:


sudo apt-get install nfs-common

A continuación editamos el fichero /etc/fstab para añadir el nombre de la carpeta en el servidor y el nombre de la carpeta donde se van a visualizar lo compartido en la máquina cliente (en el ejemplo uso el nombre de dominio local usado internamente, y como usuario de ejemplo utilizo eddy):


goldberg.it7:/home/eddy /home/eddy/goldberg nfs rsize=8192, timeo=14, intr

Creamos la carpeta en la máquina cliente:


mkdir  /home/eddy/goldberg

Y por último montamos la carpeta, la forma más cómoda es dando la orden para montar todo lo que está indicado en el fichero fstab:


sudo mount -a

En Linux, los usuarios tienen un id de usuario y otro de grupo, ambos numéricos. Se denominan uid y gid. Para que no haya problemas de permisos al acceder desde la máquina cliente a la carpeta compartida, el uid/gid debe ser el mismo en ambas máquinas.

Para asegurarnos de ello, consultaremos el fichero /etc/passwd de ambas máquinas, donde veremos al lado del nombre de usuario el numerito en cuestión. Tenemos que hacer que coincidan en ambas máquinas, y en aquella donde lo hayamos cambiado, hay que volver a asignar esos ficheros al usuario con el nuevo uid/gid.

Hay dos formas de hacerlo:

Si el cambio lo hacemos en Goldberg, y existen otros usuarios creados con permiso para ejecutar órdenes como root (sudo), entramos como uno de ellos y ejecutamos:


sudo chown -R eddy:eddy /home/eddy

Si el cambio lo hacemos en la máquina cliente, donde probablemente seamos el único usuario, arrancamos la sesión en modo de entrada directa como root y sin contraseña para poder ejecutar la orden vista anteriormente. En el caso de una Ubuntu, supone seleccionar en el arranque entrar en Terminal a prueba de fallos. Gracias a David por este último apunte.

Es muy importante tener en cuenta que una vez que hacemos el cambio del uid/gid en el fichero de configuración, perderemos la capacidad de hacer sudo, por lo que en Goldberg debería haber otro usuario con capacidad de hacer sudo o bien en la distro de Linux utilizada en la máquina de cliente debe existir una opción para entrar directamente como root sin contraseña.

Compartir carpetas para usuarios con Windows y Mac OS X

Se realiza la exportación utilizando la aplicación Samba. Este paquete lo seleccionamos en la instalación inicial del servidor de desarrollo, como vimos en la entrada anterior de este blog.

Primero, accedemos a goldberg desde una terminal, y por si cometemos algun error, copiamos el fichero original de configuración con el comando:


sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.original

Una vez hecho esto, procedemos a realizar los siguientes cambios en /etc/samba/smb.conf:

sustituir workgroup = WORKGROUP por workgroup = IT7 (o el usado en la red local de Windows donde estemos realizando el despliegue).
sustituir wins server = w.x.y.z por wins server = 192.168.50.11 (o la ip usada en tu red local por el servidor de dominio de windows)
En la sección [homes], descomentar todas las líneas (eliminar el ;) y sustituir browseable = no por browseable = yes
read only = yes por read only = no
create mask = 0700 por create mask = 0775
directory mask = 0700 por directory mask = 0755
En la sección [global] añadir las líneas:
dos charset = UTF8
unix charset = UTF8
display charset = UTF8

Tras esto, guardar el fichero y añadir las contraseñas samba de cada usuario con:


sudo smbpasswd -a.

Aparece un prompt pidiendola, introducimos la misma que tiene el usuario en Goldberg.

Los usuarios de Windows y Mac no tienen más que navegar por el Entorno de Red hasta llegar al servidor Goldberg, al entrar veremos nuestra carpeta de usuario, y tras introducir el usuario y contraseña que tenemos asignados ya podremos usar la carpeta con normalidad.

Notas:

Otra opción hubiera sido tratar de conectar Goldberg al servicio Active Directory del servidor Windows presente en la red local, pero hubiera sido mucho más complejo, así que opté por una opción más sencilla.
Es bastante probable que algunas de las opciones indicadas en el smb.conf más arriba no sean necesarias. Mi fuerte no es la administración de servidores, así que opté por lo que vi que funcionaba sin analizarlo demasiado: si funciona, me vale.
Conecto el Mac OS X via Samba en lugar de NFS (que hubiera sido más natural al ser sistemas basados en UNIX) porque me daba bastantes problemas. Si alguien tiene información de como hacer la conexión de esa manera de forma sencilla, rápida y fiable, bienvenida sea!
El Mac OS X cuando trabaja con archivos montados en un volumen que no está formateado en el sistema HFS (sistema nativo de los MAC) crea unos meta-archivos llamados igual que el archivo con el que trabajemos pero anteponiendoles ._ . Si queremos evitar ese comportamiento, deberemos desactivarlo. Desconozco como hacerlo a nivel global (cuando trabajas con cualquier programa), pero para hacerlo con el TextMate (mi editor de código favorito) usaremos la siguiente orden desde una ventana de terminal en nuestro Mac:


defaults write com.macromates.textmate OakDocumentDisableFSMetaData 1

Conclusión

Ya tenemos el servidor de desarrollo preparado para que los usuarios trabajen en él, al igual que para conectarse con el servidor externo donde residen los proyectos y el software de control de versiones. El próximo paso consiste en instalar el Subversion, de tal forma que en el entorno local tendremos una réplica de los repositorios de código alojados en el servidor externo (Dreamhost).

Instalación del servidor de desarrollo (I)

2009-12-15T19:18:00.010Z

Oh My God!

Aunqué hablé a grandes rasgos del entorno del que parto a la hora de automatizar mía día a día, vamos a detallarlo un poco más.

Cuando llegué a la empresa donde trabajo actualmente, me encontré con el siguiente entorno de desarrollo:

2 PC haciendo de servidores:

(Serv1) Windows 2003 Server: Exchange, carpetas compartidas, Oracle, Copias de seguridad.
(Serv2) Windows XP Profesional: WAMP (Apache, MySQL, PHP), carpetas web.

Todas las máquinas cliente corriendo Windows XP Profesional SP2. Los proyectos web se alojaban en Serv2, en carpetas compartidas, y todo el mundo trabajaba directamente sobre ellos.

Esta configuración presentaba varios problemas:

Serv2, al estar basado en un Windows XP no es muy estable, y cada vez que la máquina se reinicia por una actualización automática del sistema operativo hay que acceder físicamente a la máquina e iniciar sesión para que arranque el WAMP.
Los servidores de producción usados generalmente están basados en sistemas Linux, por lo que era más fácil encontrarse con sorpresas desagradables a la hora de realizar los despliegues por las diferencias entre ambos sistemas operativos.
Al trabajar sobre los mismos archivos, no pueden haber dos personas tocando lo mismo simultáneamente, además del riesgo de machacar el trabajo realizado por otro en ese mismo día sin darnos cuenta.
Al carecer de control de versiones, cada vez que se realizaba un cambio se corría el riesgo de estropear alguna parte del sistema (...y como tampoco realizaban TDD -Test Driven Development-) y luego no poder volver a retroceder sin problemas al no recordar que partes de la aplicación se habían tocado. Por otro lado esto siempre produce la proliferación de archivos tipo "miarchivo.php.bak", "miarchivo.php.old", "miarchivo.old2.php", etc... Habitual conglomerado de copias que no se sabe muy bien que pintan ahí ni cual es la razón de su existencia.
Todo el entorno de red, a nivel de DNS y demás, estaba pensado para máquinas cliente con Windows, pero yo uso Mac OS X, y posteriormente entró otro programador que usa Ubuntu, y ninguno de los dos teníamos ganas de pelearnos con el Active Directory de Microsoft, el Exchange y demás.
La información sobre los proyectos y el código se encontraban diseminadas en un amplio conjunto de ubicaciones distintas, siendo bastante complejo en ocasiones encontrar cualquier dato necesario.
Los desarrollos estaban basados en código propio, sin el uso de ningun framework estándar. Aunque el código cumplía su función (más o menos) era dificil de ampliar.
Se perdía mucho tiempo en tareas rutinarias, restando tiempo a profesionales veteranos para realmente concentrarse en las cosas importantes.

Primeras medidas a tomar

En vista de la situación me formé un esquema a rasgos generales (comentado a grandes rasgos en el anterior artículo) y decidí que los primeros pasos serían:

Instalar un servidor de desarrollo basado en Linux.
Implantar el control de versiones en el flujo de trabajo habitual.
Concentrar la información de los proyectos en un único punto para facilitar su disponibilidad.
Comenzar a usar Rails para los proyectos con libertad de elección en cuanto a tecnología, y CakePHP (clon del rails) para aquellos donde estábamos limitados a usar PHP.
Contratar un servidor dedicado para el despliegue de las aplicaciones y tener mayor control sobre la tecnología usada. El alojamiento compartido está bien para el típico proyecto web, pero para temas más avanzados mejor tener toda la capacidad de decisión.

En este artículo nos centraremos en el primer punto, aunque algunas de las decisiones a la hora de instalar el servidor vienen motivadas por las reflexiones y descubrimientos que veremos en próximos artículos donde abordaremos los otros objetivos.

Instalar un servidor de desarrollo basado en Linux

Los nombres de dominios y direcciones IP dependerán de cada caso. Yo utilizaré los usados en la empresa donde trabajo actualmente, IT7 (aunque también colaboro con SAC y K-Nábora), aunque cambiando las direcciones IP para no revelar la configuración exacta de la red interna.

Para la instalación inicial partimos de una Ubuntu 8.04 server LTS, aunque se puede elegir alguna posterior. Tras arrancar el PC con el cd de la Ubuntu dentro, los pasos son:

Seleccionar idioma español.
Seleccionar instalar Ubuntu server.
Seleccionar España.
Seleccionar Sí ante la pregunta por el layout del teclado.
Presionar todas las teclas que va pidiendo y responder a las preguntas que hace sobre la presencia de determinadas teclas en el teclado.
Cuando pregunta nombre de la máquina, introducir goldberg
Seleccionar zona horaria.
En el particionado de discos, para no complicar la vida, seleccionar la opción Guiado - utilizar todo el disco
Elegir Si cuando pregunta si se desea escribir los cambios en el disco (formateado)
Crear cuenta de usuario. Introducir nombre completo, nombre de usuario y contraseña. Dejar la opción por defecto de No crear directorio cifrado.
Dejar en blanco la opción de usar proxy para obtener la información de paquetes.
Dejar opción por defecto de no realizar actualizaciones automáticas.

A continuación y por comodidad, el programa de instalación nos permite instalar varios conjuntos de paquetes preseleccionados en función de nuestras necesidades.

Seleccionaremos los siguientes:

LAMP server: Apache 2, MySQL 5 y PHP 5.
Mail server: necesario para que nuestras aplicaciones y scripts de mantenimiento puedan enviar correos.
OpenSSH server: para poder acceder al sistema desde cualquier máquina cliente de la oficina.
DNS server: como veremos en próximos artículos, para acceder desde el navegador a los proyectos en los que trabajamos, usaremos direcciones del tipo nombre de usuario.nombre de proyecto.it7 (por ejemplo eddy.laaldea.it7, dcabrera.laaldea.it7, etc...). Para ello las máquinas clientes tienen que conectarse a un servidor DNS que resuelva dichas direcciones, para lo cual usaremos este mismo servidor.
Samba file server: tras probar varias configuraciones de trabajo se encontró que la más cómoda era aquella donde los usuarios trabajaban sobre carpetas situadas en el propio servidor. Para clientes linux utilizaremos NFS, pero para máquinas Windows y Mac OS X accederemos por Samba.

Tras seleccionar lo visto anteriormente, continuamos con la instalación:

Introducir contraseña root de mysql.
Dejar opción por defecto de correo denominada Sitio de Internet.
En la configuración del correo, cuando pregunta por el nombre del host, usar goldberg.it7

Tras esto nos pide que retiremos el CD y reiniciemos. Una vez reiniciado, entramos con la cuenta creada y ejecutamos:


sudo apt-get update

para actualizar la información de paquetes disponibles en los repositorios, y


sudo apt-get upgrade

para actualizar los paquetes instalados. Es posible que se haya actualizado la imagen del kernel, por lo que ante la duda reiniciaremos el servidor.

Por comodidad utilizaremos el phpMyAdmin para gestionar el servidor MySQL, por lo que lo instalamos con


sudo apt-get install phpmyadmin

En la instalación del phpmyadmin, pregunta para que servidor ha de realizarse. Seleccionaremos apache2.
Como veremos cuando hablemos de la implantación del control de versiones, usaremos el servidor Subversion de Dreamhost, pero para mayor seguridad y en caso de no disponer de conexión a éste, vamos a configurar un repositorio que replique el principal en esta máquina. Para ello instalaremos los paquetes necesarios:


sudo apt-get install subversion libapache2-svn

Ahora hay que configurar la red. Durante la instalación, el programa habrá utilizado la opción de coger una dirección IP proporcionada por el router (DHCP). Aunque generalmente para una configuración de máquinas estable todas acabarán adoptando siempre las mismas direcciones, es mejor asegurarnos proporcionando una dirección IP fija al servidor. Para ello hay que editar el fichero donde se definen las interfaces de red. En mi caso, uso el editor vi.


sudo vi /etc/network/interfaces

Si como hemos dicho, durante la instalación se usó DHCP para configurar la red, veremos algo como esto:


# The primary network interface
auto eth0
iface eth0 inet dhcp

Esta última línea se sustituye para asignar una ip fija dentro del rango asignado para esto dentro de la red interna. La configuración actual de Goldberg queda como sigue (en sustitución de la línea mencionada):


iface eth0 inet static
address 192.168.50.63
netmask 255.255.255.0
gateway 192.168.50.20

A continuación guardamos el fichero y editamos el fichero donde se indican los servidores de direcciones de nombre que utilizará Goldberg. Éste va a ser el servidor DNS de la red interna, forwardeando las solicitudes de direcciones externas.

Como servidores adicionales DNS suelo usar los de Telefónica, por nada en especial, sencillamente porque de tanto configurar internet para familiares y amigos acabé aprendiéndome esas direcciones en concreto.


sudo vi etc/resolv.conf

Aquí pondremos (sustituyendo lo que haya)


nameserver 192.168.50.63
nameserver 194.179.1.100
nameserver 194.179.1.101

Ahora hay que crear los usuarios del sistema. Para cada uno de ellos haremos:


sudo adduser

Introducir contraseña, nombre y una vez creado procedemos con:


sudo adduser nombre de usuario www-data

(por ejemplo sudo adduser eddy www-data).

Con esto hemos añadido el usuario al grupo del servidor apache. Para los usuarios avanzados (generalmente los programadores) que requieran privilegios administrativos sobre el servidor, ejecutaremos


sudo adduser nombre de usuario admin

(por ejemplo sudo adduser eddy admin).

En un sistema Ubuntu, se crea una carpeta home de la que cuelga una carpeta para cada usuario del sistema (eddy, dcabrera, etc.). Además, se crea un grupo de usuarios con el mismo nombre de usuario para cada uno de ellos.

En el sistema de permisos de Linux, por defecto se establece como propietario de la carpeta el usuario, y como grupo al que pertenece el grupo del usuario. Hay que cambiar el grupo e indicar que pertenece al grupo www-data, que es el grupo al que pertenece el servidor Apache y así éste no tenga problemas a la hora de acceder a los archivos de trabajo de cada usuario. Además hay que fijar este grupo automáticamente para las nuevas carpetas y ficheros que se creen. Para ello, con cada usuario (utilizaré el usuario eddy para el resto de ejemplos):


sudo chgrp -R www-data /home/eddy
sudo chmod -R g+s /home/eddy

Añadimos parámetros globales de permisos de ficheros, para ello editaremos los ficheros /etc/profile y /etc/apache2/envvars y en ambos incluiremos la línea


umask 002

Y para finalizar por ahora, crearemos las carpetas para los scripts de automatización del día a día:


sudo mkdir /etc/scripts
sudo mkdir /usr/local/bin/scripts

Esta estructura es la utilizada a lo largo de los artículos, aunque tras terminar de leer Everyday Scripting With Ruby decidí que más adelante y a medida que desarrolle scripts más complejos utilizaría una estructura más estándar tal como se propone en el capítulo 19 (A Polished Script).

Donde estamos y hacia donde vamos

Por el momento ya tenemos un servidor instalado, aunque tal como está configurado en este momento aún no podemos alojar ningún proyecto web.

En el próximo artículo, prepararemos el servidor para conectar con el de Dreamhost y para compartir las carpetas home de cada usuario por la red (vía Samba y NFS) y acceder a ellas desde las máquinas cliente.

Arrancando

2009-12-02T15:43:00.006Z

Recientemente comencé un trabajo nuevo, y nada más llegar me encontré con lo que me encuentro por lo general en todas las empresas del sector web aquí en Canarias: un entorno de desarrollo ineficiente, donde se realizaban un montón de tareas repetitivas manualmente, todo el mundo trabajaba sobre la misma copia de código ubicada en un servidor central (Windows) y la información sobre los proyectos se hallaba dispersa (carpetas de claves, carpetas de proyectos, correos de usuarios, etc...).

Todo el código era desarrollado en PHP; todos los proyectos llevaban un gestor desarrollado por la propia empresa, cuya interfaz es muy buena, con una usabilidad excelente, pero la implementación no permite su generalización para cualquier proyecto sin tener que modificar un montón de ficheros a mano.

Me gusta hacer bien mi trabajo, que mi tiempo sea productivo en lugar de perderlo haciendo tareas que podría hacer un mono entrenado. He comprobado las bondades del desarrollo agil, el control de versiones y el TDD (Test Driven Development); he paladeado las mieles del trabajo creativo mientras una serie de scripts se encargan de realizar las tareas rutinarias, asi que me propuse realizar cambios en todo el sistema productivo de la empresa.

Me fijé como objetivo final trabajar en un entorno de desarrollo robusto, seguro y flexible, en el que pueda ser feliz trabajando y mejore la productividad de la empresa. Esto último le encantó a mis empleadores, por lo que he tenido via libre a la hora de implementar los cambios.

Para ello los pasos a seguir son:

instalar un servidor de desarrollo basado en un SO más estable (Linux).
contratar un servidor dedicado para en la medida de lo posible alojar los trabajos realizados y no estar con las miserias y desventuras de los hosting compartidos.
implementar un workflow basado en control de versiones.
implantar metodologías ágiles ("Getting Real").
implantar el desarrollo orientado a tests (TDD).
automatizar todas las tareas rutinarias.
progresivamente crear un sistema generador de proyectos para realizar con él las "típicas webs" y dejar el esfuerzo mental para los proyectos realmente interesantes.
para las aplicaciones basadas en PHP, implementar el CakePHP, framework clon del Rails que me resulta cómodo por mi afinidad con el RoR.
desarrollar los proyectos en Ruby on Rails preferentemente, sin descartar en cada momento usar otras tecnologías si son más adecuadas.
cambiar la relación de la empresa con los clientes.

En sucesivos artículos, iremos viendo todos los pasos que he ido (estoy) dando para cumplir estos objetivos y así automatizar mi dia a día, dedicando mi esfuerzo mental a la parte más compleja y/o creativa de la programación.

Espero que estas recetas puedan automatizar tu día a día también.

Siguiente: Instalación del servidor de desarrollo (I)

Automatizando el día a día

Cerrado por traslado

Estoy de mudanza

Herramientas de colaboración online (I)

El Caos: situación típica en muchas pequeñas empresas

Problemas de repartir la información en un montón de archivos dispersos

Problemas de tener la información dispersa en un puñado de emails

El Orden: usa alguna herramienta de colaboración online

Conclusiones

Configurar un servidor Git usando Gitosis

Instalando lo necesario

Instalar Gitosis

Crear clave de autentificación para el administrador del repositorio

Configurando el servidor para utilizar Gitosis

Inicializando Gitosis

Configurando Gitosis

Añadir nuevos repositorios

Notas sobre puertos ssh

Conclusiones

Desarrollo estable - usar branches con git

Creación de branches en Git

Fusionar

Tags

Conclusión

Vuelta de las vacaciones

Utilizar Git con Subversion

¿Por qué Git?

Instalación de Git

Mac OS X

Linux (Ubuntu)

Windows (XP)

Trabajar con Git contra un repositorio central Subversion

Checkout

Commit

Update

Conclusiones

Tratar con el cliente

Recapitulando

Los problemas de siempre

Vias de resolución

Conclusiones

Más scripts de apoyo

Recapitulando

Objetivos

Automatización

checkout_proyectos.rb <nombre proyecto>

crear_databases.rb <id de proyecto> [tipo de proyecto] [password de mysql]

crear_entrada_lista.rb <id de proyecto>

crear_estructura.rb <id de proyecto> [nombre de usuario]

generar_proyecto_rails.rb <ruta a carpeta>

update_projects.rb <usuario> [ruta hacia fichero con lista de proyectos]

Conclusión

Creación de servidores virtuales (II)

Recapitulando

Objetivos

Paso a Paso

VirtualHost

Crear para un proyecto

Diferencias entre rails y php en el vh

Automatización

dns_zone.erb

db_local.erb

virtual_host.erb

crear_servidor_virtual.rb

Conclusión

Creación de servidores virtuales (I)

Recapitulando

Objetivos

Paso a Paso

DNS

Conclusión

Backup via FTP automatizado con Ruby

Recapitulando

Objetivos

Paso a Paso

Automatización

Conclusión

En defensa de los derechos fundamentales en Internet

Exportación de repositorios con Ruby

Recapitulando