Hace tiempo que tenía en mente hacer una web de juegos. Al final me he decantado por juegos en Flash.

La verdad es que últimamente ando bastante liado con otras cosas que no tienen nada que ver con los juegos, pero este Sábado pasado, a medio día, me puse un reto personal. Me dije: “A ver si soy capaz de hacer la web antes de que acabe el fin de semana”.

Así que, dicho y hecho. Ha nacido NextGameGen.

He hecho toda la web (incluso la parte que se encarga de subir los juegos) entre el Sábado por la tarde (unas 4 horas), el Domingo por la mañana (otras 4 horas) y el Domingo por la tarde/noche (otras 8 horas). Como no podía estar el 100% del tiempo delante del ordenador, cuando estaba era en plan superintensivo.

La verdad es que estoy bastante contento con el resultado. En 16 horas una web de juegos desde cero. Únicamente le he dedicado 45 minutos más hoy, para añadir los botones de compartir en Facebook & amigos, poner algo de publicidad, y corregir 4 bugs tontos.

Sé que hay muchas cosas mejorables (todo llegará), y que hay un par de bugs invisibles para el ojo humano, pero de momento el que quiera ya puede jugar. La web es 100% funcional.

Incluso recomienda algunos juegos relacionados, según el juego al que juegues (el algoritmo es bastante mejorable).

Pues nada más, ahora voy a ver si aumento las visitas de mi web con ShareUsers, que para los que no lo conoceis, es una web cojonuda para intercambiar enlaces de forma gratuita y automática y conseguir muchas más visitas (ya os contaré más sobre esto).

Lo dicho, podéis viciaros un rato en la web de juegos, y aquí estoy para cualquier crítica o sugerencia que querais hacer

Hola amigos, soy Coco y hoy os voy a contar la diferencia entre poner un comentario con FIXME y poner un comentario usando TODO.

• FIXME: debe ser usado cuando es un hack, una constante hardcodeada o algo crítico, y que debe ser eliminado antes del próximo release. Normalmente los FIXME, bien usados, sirven para avanzar en el desarrollo y prototipado de la aplicación.
• TODO: debe ser usado cuando supone una mejora, o cuando hay que realizar algún cambio mas o menos complejo, pero uno no tiene ganas de hacerlo en ese momento (hay gente que abusa mucho de esto, y mejor no miro a nadie).

Recuerda, si es algo crítico y el software no puede ser publicado sin corregir eso, usa FIXME, por el contrario, si el comentario que pones, no afecta para nada el buen funcionamiento del programa, y el programa va a seguir funcionando bien, puedes estar cómodo dejando el comentario como TODO.

Antes de nada debo decir que sigo sin haberlo implementado, así que hablo de ideas que tengo en mente, y no de un caso real.

Aunque en el artículo anterior hacía una introducción más detallada al tema de deployment/despliegue continuo, vuelvo a repetir el concepto:

El concepto en plan radical, es que cada vez que se haga un cambio en el código, automáticamente tu servidor de producción se actualice.

Esto es un poco hardcore, lo sé, porque muchas veces se introducen bugs, y se molesta a los usuarios innecesariamente, así que este sistema debe ser lo suficientemente inteligente para tratar de evitar esto en la mayor medida posible. Es mejor post-poner un par de dias un release, que molestar a cientos de usuarios con un bug.

Una vez dicho esto, y partiendo de la base de que ya se tiene un SCV (sistema de control de versiones), un sistema de build y un sistema de tests (tests unitarios, de integración y tests de casos de uso sobre la web, por ejemplo con selenium), el procedimiento para hacer despliegues continuos podría ser el siguiente:

• Dado un nuevo build
  • Si los entregables no se han generado correctamente, fin de la historia, no hay deployment posible
  • Si algún test (test unitario, de integración, de casos de uso, o de lo que sea) ha fallado o no se ha podido realizar, no hay más que hablar, tampoco hay deployment
• Si el build está bien, entonces se crea un backup de todo el servidor de producción (bases de datos, scripts, etc…)
  (La idea de este paso, como se verá luego, no es tanto hacer un backup real, como tener una replica similar a producción)
  • Si hubiera algún fallo generando los backups, nuevamente fin de la historia
• Una vez se tiene el backup, hay que descargarlo y verificar que funciona. Esto significa, idealmente, hacer un clon de producción, es decir:
  • Descargar el backup que hemos creado en una máquina virtual “limpia”
  • Instalar el backup (tanto código como datos)
  • Pasar un subconjunto de tests, lo suficientemente grande para saber que la instalación ha funcionado, y lo suficientemente pequeño para que este paso no tarde demasiado (quizá algunos tests unitarios y varios casos de uso)
• En este punto, debemos usar el último build que hemos obtenido en el primer paso y…:
  • actualizar el clon de producción
  • pasar nuevamente todos los tests de este nuevo build sobre ese clon de producción y ver que todo funciona bien (si algo falla, el nuevo build no se podrá desplegar y tendremos que mirar que ha ocurrido). Estos tests, deberían incluir:
    • tests unitarios
    • tests de integración
    • tests de consistencia de tablas (ver que la base de datos resultantes es la que tiene que ser)
    • tests de consistencia de datos (ver que no nos hemos pulido datos que estaban antes en producción)

Llegados a este punto, si todo ha funcionado,  sabemos que nuestro build puede instalarse por encima de un clon de producción y pasar TODOS los tests, es decir, que si el propio proceso de clonar producción funciona, repetir este proceso en producción debería nuevamente ser determinista y darnos el mismo resultado (usease, que nuestro build funcione y no cause problemas en producción).

Así pues, los pasos a realizar ahora por nuestro sistema automático de deployment, serían:

• Subir el build a producción (de hecho, este paso se puede ir haciendo en paralelo a los pasos anteriores)
  • Este paso incluye descomprimir el build y prepararlo (si es que hay que preparar algo), pero sin tocar nada que pueda afectar a producción aún
• Poner producción en modo “estamos actualizando, disculpen las molestias”
• Hacer el backup real de las bases de datos y/o cualquier archivo que pueda ser susceptible de ser cambiado (idealmente backup de todo)
• Ejecutar el script de auto-upgrade que tengamos, y actualizar tanto las bases de datos como el sistema de ficheros (tal cual se ha hecho en el clon de producción)
• Desactivar el mensaje de “estamos actualizando”
• Mandar un e-mail a quien corresponda avisando de que el sitio ha sido actualizado
• Y finalmente lanzar los tests para verificar que efectivamente todo funciona bien
  • Si por un casual alguno de estos tests falla, es que algo en nuestro sistema de clonado de producción/autodeployment está podrido, y nos dejará bien  jodidos. Nótese que tener un fallo en este punto es igual de chungo que haber hecho un release como los de toda la vida y ver que algo ha fallado, indicaría que algo en nuestro sistema de build/test está igualmente podrido… Este tipo de fallos no debería de ser normal.

Nótese que si algo falla en estos pasos (sobre producción), el sistema debería ser capaz de reestablecerse con el último backup realizado.

Después de haber comentado todo esto, también hay que tener en cuenta, que algunos pasos dependen mucho del tipo de sitio que se tiene, porque no es lo mismo hacer un backup de 50 megas, que de 5 teras, o de 2 peta bytes.  Si el volumen de información es muy grande, pues habrá que depender de los otros sistemas de backup que se dispongan, y usarlos convenientemente, con el fin de minimizar los tiempos de deployment.

En este tipo de casos, tampoco se podrá realizar un clon de producción para validar que el upgrade funciona, pero en vez de eso se puede coger sólo un subconjunto de los datos de producción (por ejemplo 1000 entradas, o 1 millón, yo que se). El tema es validar que todo funciona antes de subirlo.

Imagino que también cambia mucho el tema de si se trata de un servidor único, o son varios servidores. En el caso de que sean varios los servidores a los que afecta el  nuevo release, es posible que sea mejor introducir el nuevo build en uno de ellos, y si después de X tiempo no hay incidencias, que se propage a los demás.

Otra cosa que me gustaría comentar antes de finalizar el artículo, es que no quiero que se me malinterprete. En un caso práctico no tiene sentido hacer actualizaciones en el servidor para cada submit que se hace en el sistema de control de versiones.  Entre otras cosas, porque tampoco todos los tests pueden ser automáticos, a veces combiene hacer tests manuales. Así que probablemente lo que realmente tiene sentido y valor, es que para cada build se sepa si puede ser instalado en producción sin problemas o no (y para eso poder generar un pseudo-clon de producción es esencial), así como disponer de un botón que te haga deployments automáticos. Incluso puede tener sentido, que el sistema haga los deployments una vez al día o cada dos días, o incluso cada semana, durante las horas de menos visitas.

Para finalizar, debería quedar claro que cada cual debe adaptar estas ideas a sus recursos (sobretodo de tiempo) y sus necesidades, y sobretodo que los sistemas de despliegue automático y contínuo se pueden (y probablemente se deben) ir construyendo poco a poco.

Ale, pues nada más, espero vuestras críticas y comentarios, si es que a alguien le quedan fuerzas después de haber leido esta entrada

PD: puff, creo que voy a tardar un par de días en traducir esto a inglés… madre de Dios, que tocho que me ha quedado

Deployment es una palabra que no me atrevo a traducir, porque la he usado tanto en inglés, que ninguna de las traducciones que se me ocurren me suena bien (acepto sugerencias).

Deployment es el proceso por el cual se saca el nuevo producto. Por ejemplo, si tu tienes subida una web al servidor y actualizas a la última versión, esa actualización sería el deployment.

Digamos que el deployment continuo, es el siguiente paso lógico tras implantar un sistema de builds continuos. Es decir, partiendo de un build válido (que ha sido generado correctamente y ha pasado todos los tests), el siguiente paso asumiendo que todo ha funcionado bien, sería subir los cambios al servidor para que todo el mundo pueda disfrutar de los cambios que hemos realizado.

Por supuesto, antes de actualizar el servidor, tenemos que estar seguros de que todo va a funcionar bien, no queremos subir algo que cause o pueda causar molestias a los usuarios, por eso va a ser importante disponer de todo tipo de tests que validen lo que hemos hecho.

Las ventajas de subir los cambios continuamente son varias, pero yo destaco estas tres:

• los usuarios de tu sitio web van a disfrutar antes de las últimas mejoras y nuevas funcionalidades
• vas a tener feedback de tus usuarios al poco de haber implementado las cosas, y no 3 meses más tarde, con lo que podrás seguir mejorando o corrigiendo las cosas
• tendrás un proceso automatizado de actualizar el servidor, con lo que ahorrarás tiempo a largo plazo

Entre las desventajas más importantes, yo destacaría que hacer todo esto tiene un coste y un tiempo asociados, aunque lo he estado pensando y no es tan elevado como uno pueda imaginar, si se están haciendo las cosas bien.

Seguramente me dejo cosas en el tintero, tanto en ventajas como en desventajas, pero el concepto me parece excelente, y creo que hoy día puede marcar la diferencia entre unas webs y otras.

Finalmente me gustaría comentar que este post ha surgido porque he estado pensando en como implementar esto para el curso de mecanografía y automatizar así los deployments. De momento aún no lo tengo, pero ya he pensado como podría hacerlo, y seguramente en el siguiente post comparta mis ideas sobre el caso práctico, a ver que os parece.

Enlaces muy recomendables:

• Wikipedia: Continuous Integration
• Blog de Eric Ries: Continuous Deployment at IMVU: Doing the impossible fifty times a day
• Blog de Timothy Fitz: Continuous Deployment at IMVU: Doing the impossible fifty times a day

Otros enlaces:

• Wikipedia: Software Deployment

Entre ellos, Gonzalo dice:

Si habeis trabajado con desarrollo en base a tests no entiendo el comentario de que porque se llevan mal con el tiempo, la verdad.
Los tests ahorran muuuucho tiempo, tanto en la fase de depuración y estabilización de un proyecto como a la hora de añadir funcionalidad.
Y otro punto que los hacen críticos, los tests unitarios salvan proyectos que sin ellos estarían abocados al fracaso.

Me doy por aludido, puesto que creo que Gonzalo se refiere al comentario en el que digo:

Testeo y “tiempo razonable” no se suelen llevar bien

Así que en vez de un comentario he pensado que sería mejor poner este tema encima de la mesa, y compartir mis ideas sobre el testeo.

Realmente a lo que me refería es que muchas veces no es posible hacer un buen testeo o un testeo exhaustivo de una determinada funcionalidad en un tiempo razonable.

Mi opinión es que hacer más o menos tests depende siempre del tipo de proyecto. Por poner dos casos extremos, no es lo mismo hacerte un miniprograma para ti, que por ejemplo renombre todos los archivos de un directorio usando algún tipo de patrón, que por ejemplo hacer un programa que va a controlar la trayectoria de un misil.

No sólo depende del tipo de proyecto si no también de los plazos del proyecto y de los recursos con los que se cuente. No es lo mismo un equipo de un desarrollador, que un equipo con 5. Tampoco es lo mismo disponer de 7 meses para hacer un parser de XML, que disponer de 2.

Hay muchos elementos que influyen.

Volviendo a la discusión anterior, sobre que tests y tiempo razonable no se llevan bien, básicamente esto significa que si tu proyecto es de andar por casa, tus recursos son limitados o tu tiempo es escaso, probablemente puedas y debas posponer algunos tests.

Estoy de acuerdo con Gonzalo con que los tests traen muchos beneficios, pero esos beneficios, desde mi punto de vista son a medio y largo plazo. A corto plazo los tests beneficiosos son aquellos que te permiten ir desarrollando la aplicación y probando lo que tu crees que van a ser los casos más comunes.

Soy partidario de hacer tests desde el primer momento, de  hecho, en otro comentario mío se puede leer:

Mi opinión (al menos es lo que yo hago) es que hay que ir haciendo tests para probar las cosas conforme se desarrolle
[...]
cuando se encuentra un bug (o bien por uno mismo, o por un usuario), mi punto de vista es que hay que añadir un test-case que lo reproduzca

Se pueden escribir páginas y páginas sobre el testeo de software, sobre metodologias de programación, sobre si hay o no que llegar al 100% de cobertura de código… el caso es que escribir un buen artículo que cubra todos estos aspectos en un tiempo razonable, tampoco lo veo posible…

¿Haceis tests a menudo? ¿lo considerais perder el tiempo?

¿Cuales son vuestras prácticas habituales?

Como siempre, vuestras ideas y opiniones son bienvenidas en los comentarios y/o posts en vuestros respectivos blogs.

La verdad es que los conceptos de Ingenieria del Sofware son bastante sencillos. Cómo planificar proyectos (principalmente usando diagramas de Gantt),  qué tipos de herramientas utilizar (sistemas de control de versiones, sistemas de build, sistemas de bugtracking, herramientas para hacer diseño UML…), y metodologias para desarrollar (XP, agil, … documentar codigo, hacer tests de caja negra, de caja blanca, …), y probablemente alguna otra cosa que no me viene a la cabeza.

Por suerte o por desgracia, acabé haciendo las prácticas en Trymedia Systems S.L. (empresa en la que finalmente me quedé trabajando 4 años, y que durante ese tiempo pasó a ser propiedad de Macrovision Corp. y actualmente de Real Networks). Afortunadamente, mi paso por Trymedia me ha acabado dando una buena perspectiva de ingenieria del software.  Por lo que he hablado con otra gente que iba conmigo a la universidad, creo que actualmente siguen sin haber muchas empresas (al menos en España) donde las cosas se estén haciendo “bien” (desde el punto de vista de ingenieria del software).

Volviendo a la universidad y las asignaturas de Ingenieria del Software, el problema de la universidad no era que no dieran los conceptos en teoria, la de conceptos que se veían en teoria; el verdadero problema era que las prácticas estaban mal planteadas, y claro si puedes sacar buena nota en las prácticas sin siquiera aplicar ninguna cosa vista en teoria, pues me parece que algo estaba mal diseñado en esa asignatura. Claro, luego en las prácticas cada cual se sacaba las prácticas a su manera, y acababas pensando: “menuda chusta de asignatura, aparte de darle trabajo a estos profesores, esto no sirve para nada”.

Nada más lejos de la realidad…