Autor: Iñigo Serrano

El séptimo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Se debe poder realizar traspasos parciales de un proyecto».

A veces pasa,que una vez preparado un traspaso, alguna tarea no funciona bien y hay que quitarla. Aunque no debiera de suceder en muchas ocasiones, porque significaría que algo no funciona en nuestro proceso, a veces pasa y hay que estar preparado.

Hay que estar preparado para este tipo de contingencias y tener definido cual es el procedimiento que se va a seguir. Quitar el código de la tarea de la etiqueta del repositorio, ya que esa tarea no va a ir y actualizar el estado de la tarea en el gestor de tareas.

El sexto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Los traspasos entre entornos deben estar automatizados completamente o realizarse lanzando un script o similar, nunca manualmente moviendo ficheros».

Todas las reglas anteriores están bien, pero tenemos que tener un mecanismo que nos asegure que hacemos las cosas bien, es decir que si queremos reproducir el traspaso no vamos a hacerlo en las mismas condiciones. Si dejamos pasos manuales es posible que alguien con prisas o que no conozca bien el procedimiento no lo realice bien y por ejemplo traspase ficheros de su ordenador, sin que estén en el repositorio.

Aparte de tener la seguridad de que hacemos las cosas bien también nos interesa el que el  proceso sea lo más rápido posible.

Es por ello que debemos buscarnos automatismos. Bien desde sencillos scripts de shell (en caso de Linux) hasta herramientas como AntHillPro o Jenkins

El quinto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Todas las tareas deben estar recogidas en el gestor de tareas».

El motivo de este punto es el saber en cada traspaso que es lo que se ha enviado, para ello debemos tener recogido en el gestor de tareas todas aquellas tareas que se traspasan, o que deben ser realizadas para poner el producto.

Esto nos permitirá saber en caso de problema todo lo que realizamos para poner ese desarrollo en producción.

Hay proyectos en los que nada más se termina una incidencia se pone en producción, pero hay otros proyectos en los que esto no es así. Yo he estado en alguno. Nunca entendí el motivo de no poner algo hecho en producción hasta bastante después de haberlo terminado (y hablo de meses).

Ya vamos avanzando en poner orden y tomar el control de la situación. Con los dos pasos anteriores ya debieras de tener lo más importante controlado. Que la aplicación haga lo que tiene que hacer.

Ahora, a mi modo de ver, debieras de empezar a mirar un poco los temas internos. Para mi lo primero a controlar es el código. Por eso es lo primero en el decálogo.

Es vital que tengas el control del código fuente, sino vas a tener problemas. Créeme, he estado en sitios en los que se ha perdido código y no es una situación agradable.

Debieras de organizar el repositorio de tal forma que te permita automatizar la compilación. Aunque no lo hagas al principio de todo, en algún momento querrás optimizar el proceso productivo y la automatización es esencial. Además el automatizar te garantizará que lo que tienes en el repositorio es lo correcto, y que están todos los ficheros que necesitas.

En este punto casi se podría seguir el orden del decálogo. Siempre adecuando las prioridades a lo que en el proyecto en el que estés veas que es más sangrante.

El cuarto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Las incidencias que se envían corregidas en el traspaso deben estar etiquetadas en el gestor de tareas con un número idéntico al número identificador del traspaso».

El objetivo de este punto es poder asegurarse que sabemos en cada traspaso que cambios de código implica, que lo tenemos con el punto tercer, y saber cada traspaso que incidencias resuelve. Para ello deberemos tener una correlación entre el contenido del repositorio y el contenido del gestor de tareas que utilicemos.

El tercer punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Los ficheros que se traspasan deben estar etiquetados en el repositorio de código con un número único identificador del traspaso.«

A la hora de realizar un traspaso, sobre todo cuando va a haber diferentes versiones es imprescindible el etiquetar en el repositorio que es lo que se envía en cada uno de ellos. De esta forma si hay algún problema podremos comparar el código y detectar fácilmente los cambios.

Así mismo si tenemos que realizar un parche podremos recurrir rápidamente a la etiqueta.

Hay que hacer una mención en este punto de etiquetar al punto anterior de construir el proyecto desde el repositorio. Obviamente si queremos tener la seguridad de que lo que hemos enviado es lo etiquetado, tenemos que construir el proyecto desde el contenido etiquetado, no desde la rama general.

El primer punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Lo que no está en el repositorio de código no existe«.

El motivo es muy simple, si algún fichero no está recogido en el repositorio de código es muy fácil que se pueda llegar a perder, bien por borrado accidental bien por rotura del soporte. O bien que no se pueda encontrar porque, aunque exista, no se sepa donde está. De cualquiera de las dos forma es como si no existiese, bien porque se ha perdido, bien porque no se encuentra.

En este aspecto lo mejor es tener un planteamiento claro y simple de donde están los ficheros necesarios para generar una versión del programa. Y ese sitio debe ser el repositorio.

El tener un repositorio de código nos permitirá:

• Tener una política de backups más sencilla, ya que el contenido está centralizado.
• Nos evitará el tener que andar buscando donde está un determinado fichero, porque debe estar en el repositorio.
• Nos permitirá tener diferentes versiones de un fichero.
• El tener definido un criterio sobre donde se encuentran los ficheros y cual es su organización nos permitirá ponerlo por escrito y hacerlo público para conocimiento del resto de compañeros involucrados.

He visto proyectos en los que se ha perdido código y no es una experiencia gratificante. Deja una sensación de incompetencia entre los propios afectados que no es agradable.

Hay diferentes opciones dentro de los repositorios de código, tales como Git, SVN, Rational Tem Concert y otras muchas más.

Hoy quiero hablar un poco de arquitectura de aplicaciones, concretamente de la distribución de información entre diferentes partes de la aplicación.

Si estamos diseñando la arquitectura de una aplicación en la que hay un intercambio de información entre componentes distribuidos muy alta, a diferencia de cuando el intercambio es bajo, hemos de buscar un método de ser muy eficientes, ya que una pequeña mejora nos puede suponer un gran beneficio. Esta situación se agrava si las comunicaciones no son muy fiables.

En el mundo Java, una de las primeras opciones que tenemos es la de serializar los objetos para poder transmitirlos. La serialización es un mecanismo que está implementado en el lenguaje desde hace mucho tiempo. El principal problema es que estás limitado al lenguaje Java y que si hay cambios en la definición de los datos, cosa que es casi seguro que suceda, puedes tener complicaciones.

Desde hace bastante tiempo está disponible el uso de XML para realizar ese intercambio de información. El problema con el XML es que da lugar a ficheros muy grandes, ya que están pensados para que puedan ser leídos por una persona. Si tenemos problemas con el ancho de banda, esto puede ser un serio problema.

Posteriormente al surgimiento de XML apareció JSON, que es menos pesado que el XML, pero sigue siendo relativamente grande.

Existe una opción que creo que es interesante. Se llama protocol Buffer y es de Google. Es una forma de transmitir información de una forma eficiente y multilenguaje. Muy interesante para comunicar las «tripas» de las aplicaciones.

Como he comentado alguna vez es interesante seguir a los mejores y a aprovecharse del camino que ellos ya han recorrido.