Categoría: Arquitectura & DevSecOps

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.

A la hora de industrializar el software hay una paso que es importante. Se refiere al traspaso del trabajo realizado a la infraestructura del cliente. Asumiendo que estás trabajando en una subcontrata. Da igual lo que has hecho en tu empresa, lo que cuenta es lo que entregas al cliente.

En este caso de los traspasos de software yo normalmente parto de un decálogo de índole técnico, para centrar a los compañeros, sobre todo los que tienen menos experiencia, de cuales son los objetivos que tenemos que perseguir, sin incurrir en excesivos tecnicismos de índole CMMI y similares.

Es un decálogo con planteamientos un poco lapidarios puestos adrede porque es muy triste cuando llegas a un sitio y te encuentras que tienen completamente descontrolado su proceso productivo, ocasionando graves problemas de calidad y de coste. Sobre todo cuando es muy sencillo de conseguir el tener un control básico, que hace que todo el mundo pueda vivir un poco mejor.

El decálogo es el siguiente:

1. Lo que no está en el repositorio de código no existe.
2. El contenido del traspaso se genera a partir del contenido del repositorio de código y solo desde el repositorio de código.
3. Los ficheros que se traspasan deben estar etiquetados en el repositorio de código con un número único identificador del traspaso.
4. 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.
5. Todas las tareas deben estar recogidas en el gestor de tareas.
6. Los traspasos entre entornos deben estar automatizados completamente o realizarse lanzando un script o similar, nunca manualmente moviendo ficheros.
7. Se debe poder realizar traspasos parciales de un proyecto.
8. Cada tarea recogida en el gestor de tareas debe contener toda la información para realizar el traspaso.
9. No se traspasa nada sin que se hayan superado los controles de calidad.
10. No se traspasa ningún proyecto sin que haya sido aprobado por el responsable del proyecto.

Iré explicando el porque de cada una.

¿Tenéis alguna norma más que apliquéis a los traspasos ?

Otro de los problemas típicos cuando defines una arquitectura para una aplicación web es controlar los botones de ir hacia atrás, hacia adelante o los favoritos.

Hay que tener en cuenta que los navegadores web estaban originalmente pensados para mostrar información básicamente textual, no para hacer aplicaciones con un estado entre página y página. Es por ello cuando haces aplicaciones web los dichosos botones son un fastidio.

Técnicas para resolverlas hay muchas, desde las más peregrinas que utilizaba hace mucho tiempo, de poner un numerito incremental en cada petición y en el servidor comprobar que siempre venia uno superior, hasta soluciones más elaboradas como las que se aplican en el GWT (Google Web Toolkit)

Cuando defines una aplicación web una de las cosas a tener en cuenta es el control del temblor del dedo. Me refiero a los usuarios que pinchan sobre una opción varias veces, porque no están seguros de si han dado bien, o ven que la aplicación no responde y se creen que se no les ha hecho caso. Es lo que yo llamo «el temblor».

Antiguamente cuando no se hacían las aplicaciones AJAX esto se solía controlar de las formas más peregrinas, desde poniendo una capa de bloqueo mientras se procesaba la petición, con lo que se conseguía un doble efecto, eliminabas la posibilidad de pulsación múltiple y además dabas al usuario una indicación de que le habías recibido su petición y estabas trabajando en ella.

Hasta manteniendo un numero incremental por cada petición y controlando en el servidor que siempre te venia un valor superior al que tenias guardado.

Con la generalización de las aplicaciones AJAX esto se puede conseguir de una forma menos manual, ya que se dispone de la posibilidad de bloquear las peticiones hasta que se reciba la respuesta del servidor.

¿Utilizáis alguna otra técnica para controlar «el temblor»?

En esta entrada quiero comentaros una herramienta que he descubierto no hace mucho y que me está gustando bastante. Tiene relación con la industrialización del desarrollo del software y los scripts para el mundo Java, principalmente.

La mayoría hemos utilizado Ant para crear nuestros scripts. Está bien, pero tiene un inconveniente principal. Te tienes que crear tu los scripts y definir el flujo de trabajo que quieres, desde cero. Es decir es una herramienta muy versátil, pero costosa.

Existe otra opción, que es usar Maven, que te proporciona el flujo de trabajo ya definido, utilizable solo con definir un fichero de configuración, pero que tiene el inconveniente de si quieres modificar ese flujo porque no te sirve tal cual, ya que es bastante costoso.

Ambas herramientas tienen un inconveniente en común y es que se configuran mediante ficheros XML, lo cual no siempre es lo más adecuado. Son ficheros muy grandes, y para un entorno de programadores sería más adecuado el uso de notaciones más cercanas al script.

Existe una herramienta que conjuga lo bueno de estas dos herramientas, y además con una sintaxis de lenguaje de programación. Se llama Gradle. La conocí por esa actitud de sigue a los mejores que tengo, ya que es la que utilizan ahora en el proceso de construcción de aplicaciones Android.

Existe un plugin para eclipse, que solo he utilizado una vez, ya que me hacia algunas cosas «raras», parece que cacheaba el script de gradle. Tampoco le he vuelto a dedicar más tiempo, porque tenia que ejecutar el script en una máquina sin eclipse.