Posts Tagged ‘puesta en producción’

La puesta en producción

16 noviembre 2009

Se acerca el día “D”. Voota empieza su andadura esta semana y, como no puede ser de otra manera, estamos llenos de emoción. Y cuando digo emoción, me refiero a lo contentos que estamos y a las ganas que tenemos de verlo funcionando, no a que tenemos los pelos como escarpias por el miedo a la puesta en producción. Veamos algunos consejillos para que esto no ocurra.

Ante todo, ¡orden!

Para que la subida (o puesta en producción) sea un éxito, es fundamental hacer una buena planificación, preparar el proceso unos días antes. Una buena idea es tener un checklist de cosas a preparar/revisar antes de ponerse manos a la obra. Podría ser algo tan simple como:

  • Asegurar que los servidores están correctamente actualizados.
  • Comprobar los datos. Todos están correctamente cargados con la información adecuada.
  • Backups. Asegurarse de que todos los subsistemas se están copiado adecuadamente según la política de backup.
  • Todas las aplicaciones están listas (este punto debería llevar implícito toda una fase de pruebas funcionales)

Otra cosa importante es planificar el día y la hora correctamente. Si se planifica la subida a última hora del día, ante cualquier imprevisto, se condena uno a una de dos: dejar el trabajo a medias, o a hacer horas extras. Lo mejor es hacerlo a media mañana con tranquilidad y sin estrés. Lo mismo pasa con el día. Si se realiza la subida un viernes, se está exponiendo el sitio a que se pasé 3 días offline.

Sube pronto, sube a menudo

Hoja de ruta (roadmap) de Voota

Hoja de ruta (roadmap) de Voota

Una de las máximas del desarrollo ágil es que los “sprints” deben de ser cortos. Esta semana Voota sale con lo esencial, es decir, un sistema de opiniones sobre políticos con un ranking para ver los más votados. Hemos querido reducir tanto que ya tenemos programado otro “sprint” de 7 días para subir la semana que viene. En su Trac se puede ver la hoja de ruta de Voota.

Sólo errores, ¡por favor!

No se puede concebir un desarrollo de software que no tenga incidencias, bugs o errores (depende quien los nombre). Son fallos en el desarrollo que se producen a todos los niveles (datos, aplicación, sistemas, …). Es por esto que es imprescindible una fase de pruebas de software, durante la cual se van identificando y corrigiendo estos fallos. Hasta aquí todo bien, el problema es que, inevitablemente, al revisar las aplicaciones siempre aparecen funcionalidades nuevas con las que se podría dotar al sitio. La tentación de informar como incidencia una nueva funcionalidad que se le ocurre al encargado de hacer la revisión es muy grande.
Es importante no caer en esta tentación a menos que se detecte una funcionalidad importante no detectada en la fase de definición. En este caso debería incluirse en la definición con su correspondiente estimación y retrasar la subida todo lo que sea necesario. Nunca “colarla” como un error. Lo único que se conseguiría con esto es degradar la calidad del software.

Ya está, ¿y ahora qué?

Ramificaciones para gestionar subidas en Voota

Ramificaciones para gestionar subidas en Voota

Un problema clásico de las puestas en producción es el siguiente. Se sube una versión a producción, por ejemplo, “milestone0.5”. Inmediatamente se comienza con el desarrollo del “milestone0.6”, pero dos días después se descubre un error importante en la versión en producción (“mileston0.5”). Si no se ha tenido la precaución de guardar el estado de todos los programas en el momento de hacer la subida, el problema no se podrá solucionar hasta que el “milestone0.6” esté listo. Es por esto importante hacer una “foto” con el estado del proyecto en el momento de la subida. Cualquier gestor de fuentes del mercado (subversion en el caso de Voota) permite crear ramas (branching).
Una rama en el gestor de fuentes es como tomar una foto del estado del proyecto, con la ventaja que se puede cambiar de una rama a otra cuando se necesite.

¡ Vamos, pues, a por el siguiente punto kilométrico !

Anuncios