archivo

Archivo de la etiqueta: SVN

Para este año que comienza, en mi departamento deberíamos plantearnos seriamente un par de objetivos (entre otros muchos). Uno de ellos ya se ha puesto en marcha, aunque todavía no está ejecutado y es la automatización de los despliegues en el entorno de desarrollo y otro que deberá venir después de este que son las entregas en el entorno de pruebas.

En ambos casos la idea es sencilla, situando los fuentes en la rama correspondiente del SVN y teniendo alojadas las librerías dependientes en Artifactory, el proveedor a través de Hudson solicitaría el proceso de compilación y despliegue. En ese proceso un Sonar que tendríamos habilitado en cada entorno (hasta ahora solo lo tenemos en pruebas) recogería las métricas fruto del análisis estático de código y un plugin para Hudson que se está terminando de implementar instalaría la aplicación en el Tomcat adecuado.

Puede parecer que es poco, pero cumpliendo ambos objetivos estoy seguro que mejoraremos en productividad. En el caso del entorno de desarrollo porque daremos a los proveedores la posibilidad de probar el producto en nuestro entorno independientemente de la fase de construcción en la que se encuentre (algo importante porque así se reducirá el número de entregas rechazadas por causas dependientes del entorno) y en el caso del entorno de pruebas porque ahorraremos tareas a nuestro equipo de calidad y a nuestros compañeros del departamento de producción.

En el caso del entorno de pruebas, el problema inicialmente estaba en que los proveedores no debían conocer determinadas claves de acceso (por ejemplo la contraseña del usuario de conexión en base de datos), pero eso queda resuelto ya que las claves se pueden alojar en un fichero independiente y los proveedores simplemente apuntar a él.

Todavía quedaría otros aspectos en los que trabajar, como por ejemplo intentar automatizar la ejecución de determinados scripts en base de datos, el alta o modificaciones en la configuración en terceros entornos, como por ejemplo, Alfresco, etc…, pero independientemente de que trabajemos en esto, si conseguimos realizar de manera adecuada los dos objetivos planteados, notaremos sin duda, los resultados.

En mi organización tenemos aproximadamente 160 aplicaciones en producción, de las cuales, un buen número de ellas tiene tratamientos de mantenimiento correctivo y evolutivo. A esto hay que sumar que el número de personas que realizan las tareas de revisión de la calidad del proyecto de desarrollo de software es reducido en proporción al volumen de trabajo que entra y que además se van a redefinir sus funciones ampliando el alcance de las tareas que venían realizando hasta ahora, centradas principalmente en la instalación de las aplicaciones y parches en el entorno de pruebas (a partir de los fuentes que tenemos en SVN y de los artefactos que tenemos en Artifactory, haciendo uso de Hudson/Maven) y coordinación con los diferentes departamentos implicados y proveedores, la realización de pruebas funcionales y seguimiento de las incidencias detectadas en las mismas, coordinación entre Dirección de Proyectos y Departamento de Sistemas en el proceso de paso a producción, creación del tag correspondiente a la versión que se ha subido a producción en el SVN y coordinación con el responsable de Arquitectura en la subida de las librerías a Artifactory. A todo esto hay que añadir determinadas tareas adicionales que se les encargan en diferentes momentos y que requieren también el correspondiente esfuerzo.

La ampliación de las funciones que vienen realizando se va a centrar en los siguientes aspectos:

– Participación en fases más tempranas del desarrollo de software (no a partir de la entrega), con el objeto principalmente de perfilar junto a los proveedores y la Dirección de Proyectos, unos planes de prueba que se ajusten a las características de la aplicación que se va a poner en producción (ya sea una nueva o un evolutivo importante de otra anterior).

– Esta participación más temprana, podrá permitir además que asuman tareas de seguimiento, medición y control de la calidad del proceso.

– El montaje de un ecosistema de herramientas de pruebas que permita incrementar el rango de pruebas que se realizan (verificación estática de código, incrementar el volumen de pruebas relacionadas con la seguridad, accesibilidad, etc…), la automatización de determinados tipos de pruebas, integrar dichas aplicaciones entre sí y con el software utilizado en mi organización para la gestión de incidencias en el proceso de desarrollo (Mantis), etc…

– “Externalizar” en los proveedores de servicios de desarrollo de software la realización de determinados tipos de pruebas, proporcionándoles esquemas de verificación que deben seguir (algunos de los cuales se podrán evaluar de forma automática).

– Participar en la creación de una infraestructura que fomente la reutilización de artefactos y componentes de mayor nivel por parte de los sistemas de información.

– Definición junto al Departamento de Desarrollo y de Producción de mi organización del Plan General de Calidad de los proyectos de desarrollo de software, que junto al libro blanco de desarrollo y otras directrices de carácter general, regirán no sólo la dinámica de funcionamiento del equipo de calidad, sino del proceso de desarrollo en su conjunto.

Uno de los grandes problemas de las organizaciones que tienen externalizado el proceso de desarrollo de software es la disponibilidad del código fuente de las aplicaciones. Pasa en demasiadas ocasiones que cuando se quiere realizar un mantenimiento de un sistema no se tiene acceso a todo el código fuente, lo que dificulta o impide (depende del tipo de sistema y del estado de los fuentes) la realización de dicha tarea y puede provocar cautividad respecto de los proveedores.

Por este motivo resulta fundamental disponer del código fuente de las diferentes versiones de los sistemas de información y eso no se consigue exclusivamente implantando un gestor de fuentes como por ejemplo SVN, sino que hay que arbitrar una serie de mecanismos. Me voy a centrar en los desarrollos en tecnología Java, aunque estas ideas son perfectamente válidas (directa o con ligeras variaciones) con otras tecnologías.

Lo más importante es que romper con las entregas de las aplicaciones mediante empaquetados, como por ejemplo la entrega de .war, ya que si este proceso lo realiza el proveedor no tendremos ningún tipo de garantía de que los fuentes almacenados en nuestro gestor (SVN) se corresponden con lo que nos han entregado. Por tanto el proceso de compilación y despliegue debe recaer en nosotros y no en el proveedor.

En el caso de mi organización, el proveedor tendrá los fuentes actualizados en nuestro SVN, las librerías dependientes accesibles en repositorios públicos y/o en nuestro repositorio (Artifactory) y la especificación de la aplicación en un fichero .pom.xml. El proceso de compilación, despliegue, etc… lo realizamos haciendo uso de Hudson (sobre Maven). No quiero decir ni que el procedimiento que venimos utilizando sea el mejor o que las herramientas elegidas sean superiores a otras, lo que realmente es importante es controlar, sea por el mecanismo que sea, que lo que se instala se corresponde con lo que tenemos en el repositorio de fuentes.

Todo lo anterior hay que acompañarlo con una correcta política de etiquetado y comentarios de las diferentes versiones en el gestor de fuentes ya que facilitará en gran medida la recuperación de versiones anteriores.

Aunque de momento se permite según nuestro libro blanco de desarrollo, desde mi punto de vista no es una buena política almacenar el .war junto a los fuentes de la versión, además de por el espacio que ocupa, por el riesgo de que no se corresponda con los fuentes. Sin embargo sí que me parece una buena política guardar en el SVN junto a cada versión la documentación que describe a la misma (en el caso de que la versión sea lo suficientemente significativa como para almacenar la documentación con la misma), sé que puede resultar incongruente con lo que he dicho de los .war, ya que también existe el riesgo de que no se corresponda con la versión y al que lo piense le tengo que dar la razón, no obstante, considero más complicado asociar en un futuro qué documentación se corresponde con qué versión que generar un empaquetado de una determinada versión. Con esto no quiero decir que la documentación no se almacene donde corresponda, es más, aconsejo que persista en un lugar diferente al gestor de fuentes, lo que sí me parece recomendable es que junto a la versión se haga una foto de la documentación que se corresponde a la misma y se almacene en el gestor de fuentes.

De un tiempo a esta parte en mi departamento, se ha tomado la decisión de comenzar a procedimientar determinados procesos que tenían lugar dentro del mismo, algo que por otra parte era necesario ya que muchas tareas llegaban a los técnicos que las tenían que ejecutar por múltiples medios (correos electrónicos, Service Desk, teléfono, oralmente, etc…), lo que por un lado impide medir la carga real de trabajo, por otro impide priorizar tareas de manera adecuada y por último daba lugar a que se perdiesen determinadas peticiones e incidencias.

De esta manera se han dado los pasos adecuados para centralizar todas las peticiones e incidencias a través del Service Desk, tanto las que procedan de usuarios por diversos motivos (microinformática, aplicaciones, etc…), las de consumo interno dentro del Departamento de Informática, así como las que procedan de proveedores de servicios TIC que tengan contratadas determinadas tareas, como por ejemplo desarrollo de software (el proveedor, con la autorización pertinente de la Dirección del Proyecto, puede también reportar incidencias (por ejemplo, se ha caído tal servidor de aplicaciones) o realizar peticiones (por ejemplo, solicitar la asociación de un determinado usuario a un proyecto en SVN).

Una vez que se ha tomado la decisión de centralizar peticiones e incidencias en el Service Desk, toca delimitar su competencia con otras herramientas que utilizamos dentro del departamento, como por ejemplo Redmine (esto es más sencillo, ya que aunque Redmine gestiona peticiones, son aquellas relacionadas con la actividad interna de un proyecto concreto) y Mantis, que gestionaba peticiones e incidencias para procesos concretos del departamento de desarrollo (generalmente peticiones relacionadas con la solicitud de recursos sobre alguna de las herramientas que componen nuestra infraestructura de desarrollo e incidencias producidas en el proceso de paso a producción de las aplicaciones). En este nuevo marco, Mantis quedará como bugtracker dentro del proceso de desarrollo de software, de uso interno en cada proyecto.

El principal problema de los inventarios es que tienden a quedarse obsoletos y esto pasa con cualquier inventario que quieras hacer, ya entren, salgan o se modifiquen elementos del mismo, con más o menos frecuencia (evidentemente el grado de obsolescencia del inventario es mayor cuanto más movimiento tenga).

Para mantener un inventario actualizado hay dos opciones (la primera de ella puede ser muy costosa, en función de lo que se quiera inventariar):

1) Contratar a tantas personas como sean necesarias para mantener el inventario al día (la dedicación no tendría que ser completa, pero sí debería ser su mayor prioridad que el inventario esté siempre actualizado).

2) Integrar el mantenimiento del inventario, dentro de los procesos que pueden modificar su estado. Por ejemplo, si tenemos un software que gestiona las compras, una vez realizada la compra este software debería actualizar el inventario.

En el proceso de desarrollo de software hay muchos inventarios que mantener:

– Fuentes.
– Componentes.
– Documentación.
– Librerías.
– Participantes.
– Planificaciones.
– Contrataciones (si se externaliza el proceso de desarrollo) y su ciclo de vida.
– Sistemas de información, etc…

Y además necesitan estar integrados entre sí, ya que no se debe entender una versión de un sistema de información sin al menos las librerías (no funcionaría), componentes reutilizables (no funcionaría) y la documentación del mismo.

En los departamentos TICs de las organizaciones es fundamental tener el inventario software actualizado (y otros inventarios: hardware, relación elementos físicos con elementos lógicos, etc…) y la única forma de conseguirlo, por la naturaleza de los desarrollos de software, es integrar el mantenimiento de los inventarios dentro del proceso de desarrollo de software. Cuanta más rica sea la integración, mayor calidad tendrá el inventario y un mayor conocimiento de lo que es todo el proceso de desarrollo de software en su conjunto.

Incluso teniendo integrados en su mayor parte los elementos que conforman un desarrollo, se requiere siempre un esfuerzo para que el mantenimiento del inventario sea de calidad. Ese esfuerzo consiste en utilizar además de los elementos que se recomiendan en la organización, como pueden ser: SVN, Artifactory, Redmine, Alfresco, etc…, en seguir las políticas y procedimientos de la organización. Es decir, si la política de la organización es que semanalmente se actualice la planificación y avance del proyecto en Redmine y no se sigue, perderemos la visión del estado de los proyectos (la gestión del proyecto en sí: planificación, participantes, incurridos, etc… es otro inventario), algo que es fundamental en los procesos de construcción y mantenimiento del software.

En mi departamento seguimos dando pasos pequeños, pero firmes para tener una infraestructura de desarrollo de software en condiciones.

– El uso de Subversion ya es generalizado, por lo que tenemos un control absoluto sobre los fuentes de las aplicaciones.
– El uso de Artifactory también es generalizado, por lo que también tenemos un control absoluto sobre las librerías que se utilizan y las tenemos en un espacio distinto a los fuentes.
– El uso de maven para las entregas e implantación también es generalizado y se está generalizando la implantación mediante Hudson.
– Tenemos un libro blanco de desarrollo que de un tiempo a esta parte ha orientado los desarrollos a una arquitectura y una tecnología común, lo que facilita la reutilización y el mantenimiento. En la actualidad se está retocando dicho libro para actualizarlo tecnológicamente, acotar un poco más el abanico de posibilidades y soluciones a utilizar y modificar drásticamente la forma de documentar los proyectos, basándonos en una herramienta CASE (independientemente de que haya documentación extra-CASE).
– La metodología de peticiones de entregas y de comunicación de incidencias en las pruebas con las empresas desarrolladoras también se está generalizando.
– La documentación de los proyectos está centralizada en un ECM (en nuestro caso Alfresco), con una estructura de carpetas por proyectos. Esta forma de organizar la documentación va a variar con la nueva versión del libro blanco que como he comentado se va a basar en el uso de una herramienta CASE.
– Se ha terminado de implantar una herramienta para gestionar los proyectos de manera que no tengamos la gestión en diversas herramientas y soluciones. A partir de ahora vamos a tratar de que la gestión de todos los proyectos esté centralizada en Redmine. Probablemente más adelante “truquemos” Redmine para comunicarlo con Alfresco, para añadirle alguna característica como la gestión de incurridos, etc…

Todavía nos queda mucho camino por recorrer, pero creo que la dirección que hemos tomado es adecuada. Mi único mérito en todo este asunto ha sido escuchar y dejarme aconsejar por gente que sabe mucho, muchísimo de lo que es el proceso de desarrollo de software. También hay que destacar la acogida que ha tenido esta infraestructura entre mis compañeros porque sin su colaboración nada hubiera sido posible.