Estamos desarrollando el nuevo software de tarificación RMS, que es una aplicación “Desktop” que se comunica con una serie de servicios de Peoplecall (RIA) para gestionar un Callshop: Tarificar las llamadas de los clientes, gestionar la atención al cliente y calcular los márgenes y beneficios del local.
Esta nueva versión está completamente reescrita porque la anterior ya se nos habia quedado un poco obsoleta.
Actualmente estamos en el Sprint#4 de los 6 que hay previstos para esta release, la version final será la 2.1.0. En este desarrollo hemos aplicado todo lo que hemos ido aprendiendo estos últimos años : Desarrollo en Java, Tests, Metodología Scrum, Integración Contínua, etc.
Desde el principio nos habia preocupado el como organizar las actualizaciones en la maquina del usuario. Si queremos aplicar el concepto de evolución, el mecanismo de actualización del software es crucial.
Para decidir como hacerlo, primero preguntamos a amigos y conocidos sobre “actualizaciones” y mas o menos habia coincidencias :
- Las de Microsoft : “Que pesaos!”, te obligan a apagar el pc aunque no te venga bien, y si estás viendo una película te sale un mensaje en medio de la pantalla para que apagues el PC.
- Las del Firefox : Si llevas un par de semanas sin abrirlo, preparate!, y si tienes muchos plugins, luego te salen un montón de pestañas informandote de todo lo que se ha actualizado. Si vas corriendo a ver un mapa o una dirección … fastidia (ver Why people don’t upgrade their browser)
- Las del iTunes : Tradicionales, te avisan de que tienes una nueva actualización, y lo que realmente haces es instalar de nuevo encima una instalación completa. Hay quien lo tiene mas currado (pej. uTorrent) con lo que descarga y reinicia muy rápidamente, pero basicamente te hacen pasar por el proceso de instalación cada vez que actualizan.
- Las del Google (Chrome, GTalk) : ¿Se actualiza?, hay quien nisiquiera se da cuenta, la mayor queja está en que lo hace sin consultar y sin avisar, aunque te da una serie de pistas de lo que hay de nuevo en la página de inicio, basicamente lo hace todo sin tu permiso y casi aunque no quieras.
Así que con esto, nos pusimos a discutir que mecanismo queríamos implementar.
Nuestro producto (El RMS para callshops) es una aplicación de punto de venta y tiene unos condicionantes especiales que nos ayudaron a decidir, como por ejemplo la eventualidad del personal que la utiliza, su posible inexperiencia en informática y el impacto negativo de las versiones antiguas del software sobre la evolución de las API a los que accede, así que optamos por implementar un mecanismo de actualizaciones completamente automatizado, tipo Chrome.
¿Como funciona?
Al instalar el programa, en realidad se instala un “launcher”, apenas unos 400KB, la mision de este launcher es comprobar que la JVM está accesible y manejar las actualizaciones.
Cuando se ejecuta el launcher, descarga desde Peoplecall un archivo que le indica cual es la version correcta del binario y la url desde donde se la puede descargar.
Si la version existente en disco es menor que la última, arranca un proceso en background para descargar la nueva versión pero arranca la version actualmente en disco, de modo que el usuario no tiene que esperar a que se descargue nada, la próxima vez que se ejecute el programa, ya se iniciará la nueva versión.
El único aviso que recibe el usuario es un “baloon” de 10 segundos que le indica que el nuevo binario ya está en el disco, a modo informativo, el usuario no tiene que hacer nada.
Canales
El “launcher” tiene tres canales de actualizaciones: “Stable”, “Beta” y “Dev”, por defecto el canal que sigue es el “Stable”, que salta de version cuando hay una nueva version estable, y el Dev es basicamente una nueva cada snapshot.
Continuous Deployment
Para proveer el software hemos puesto un repositorio de maven, el Nexus (http://nexus.sonatype.org/) , con un repositorio funcionando como proxy del que tenemos para desarrollo. (No podemos utilizar el mismo porque están en subredes diferentes con niveles de seguridad diferentes)
De este modo, según desarrollamos nuevas versiones, el Hudson (Integración contínua) va subiendo los artefactos (jar) al Nexus de desarrollo, cuando decidimos que una nueva version debe ser desplegada en producción, modificamos el archivo de versiones en el canal correspondiente.
Cuando los launchers actualizan este archivo (lo hacen en background) , requerirán al Nexus la version nueva, el cual la servirá o la pedirá al Nexus de desarrollo si no la tiene.
De esta forma podemos asegurar que el binario se actualiza en el cliente en dos o tres ejecuciones del programa.
Curiosidades
El launcher está hecho en un lenguaje de scripting llamado “AutoIt” en unas 300 líneas, intentamos hacerlo con VBS, pero es increible lo mal documentado que está. Y la instalación del launcher está hecha con el paquete de instalación NSIS, que es sencillito.
Nos queda portar el launcher a Linux y Mac.
Hemos intentado el Java Web Start, pero francamente … acojona. Hemos tenido problemas intermitentes y fallos que al final se arreglaban reinstalando. Creo que el JWS esta muy bien para entornos de intranet donde es posible controlar (mas o menos) que hay instalado en el ordenador del usuario.
Pero …
Lo bueno que tiene esta solución es que el parque de usuarios estará siempre en la misma versión, ya que no depende de una elección del usuario, todo sucede de forma automática, y tampoco entorpece el uso del programa (todo sucede en background)
El mayor problema radica en precisamente su mayor ventaja: que todo el mundo se actualiza automáticamente, con lo cual, si desplegamos un artefacto con bugs o añadimos mejoras que nadie quiere … la hemos liado!!
Pero de esto se trata el Agilismo, de escuchar al usuario, de la evolución contínua en la dirección correcta y en el asumir que el producto está vivo y actuar en consecuencia, asi que … si queremos ser Ágiles … ya tenemos tres tazas !
Lo del despliegue continuo que habéis montado está muy chulo.
Respecto a lo de actualizar sin pedir permiso... buff, es peliagudo, claro. Porque creo que tiene mucho que ver con quién es tu cliente. Si tu cliente sabe que está usando un producto que no está hecho "a medida", en exclusiva para él, sino que, "hablando en scrum", comparte el backlog con otros dueños de producto, entonces me parece genial lo que hacéis. Sería la versión "desktop" de un SaaS.
A mi nunca me han preguntado para incorporar ciertos cambios en Gmail, eso sí, la mayoría son "opcionales". Los puedes incorporar en tu configuración o seguir como hasta el momento. Otra cosa son defectos de los que probablemente ni me haya percatado que se han resuelto.
Todo caso, quizás sería una mejora el preguntar al usuario si quiere aceptar el "upgrade" si se trata de un gran cambio de versión. Como cuando Gmail me dió la opción de pasar de la Beta a la versión definitiva. ¿No fue así?
Otra cuestión que se me ocurre es, ¿qué haréis cuando una nueva funcionalidad requiera un componente que obligue a cambiar el propio instalador? ¿Iríais a un modelo iTunes para evitar problemas de plataforma?
Enhorabuena, Herme. Estáis haciendo un producto estupendo. Deberíais haber presentado vuestro caso a la #agilespain2010.
Un abrazo,
JMB
Publicado por: Jmbeas | 09/05/10 en 16:18
Gracias por la enhorabuena !
Lo que ocurre es que el RMS depende mucho de servicios remotos de Peoplecall, por eso no es fácil mantener clientes en diferentes versiones.
En el caso de aplicaciones Web, es normal que se actualice sin pedir permiso, entre otras cosas porque es muy complicado mantener dos webapps diferentes salvo para cambios de interface o de estilo.
Y en el caso de aplicaciones de escritorio, como un editor de textos, es normal que el usuario no actualice si no quiere, y que por supuesto se pida permiso, ya que la interacción con servicios remotos es cero.
En nuestro caso, creemos que el cliente basicamente quiere que "funcione siempre" y que vayan apareciendo cosas nuevas (aunque sutiles y nada drásticas) de vez en cuando y si tenemos que parchear bugs dos o tres veces en un mes .. que no le importune.
El caso de actualizar el lanzador es mas complejo, no sabemos realmente que hacer.
Una solución puede ser hacer un "lanzador del lanzador" mucho mas sencillo y que no se actualice nunca, pero siempre queda algo sin actualizar.
Otra puede ser que el lanzador se baje su nueva version y añada un script para que en el próximo arranque se renombre el fichero ("a la Windows Update")
.. en fín, que ahí estamos., ah! y lo del #agilespain2010 no se me habia ocurrido !
Muchas gracias por el comentario y un abrazo !
Herme
Publicado por: Herme García | 09/05/10 en 22:05