archivo

Archivo de la etiqueta: Subversion

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.

La implantación de procedimientos dentro de un departamento de desarrollo de software produce beneficios y por tanto un retorno de la inversión.

El principal inconveniente que encuentra es la reticencia del personal a cumplirlos ya que en su mayoría piensan que toda esa burocracia es una pérdida de tiempo.

El primer error es pensar que se trata de burocracia o por lo menos en el sentido negativo en el que se suele entender ese término, obligarte a seguir una serie de pasos para realizar determinadas acciones no es burocracia, son procedimientos. Esto no quita que el diseño de los procedimientos deba ir acorde con las posibilidades que tiene el departamento, si se va más allá de lo que se puede abarcar, estamos ante una situación contraproducente (no se terminarán por seguir los procedimientos y además se producirá una reducción de la eficiencia).

No es necesario empezar a procedimentarlo todo de la noche a la mañana. Lo mejor es ir poco a poco, que el personal se vaya acostumbrando a esta otra forma de trabajar, más ordenada, que permite, por todos, una mayor control de las acciones que se realizan.

Los procedimientos irán acompañados de herramientas (o por lo menos es aconsejable). En mi organización los procedimientos internos del departamento de desarrollo y nuestra interacción con el resto de departamentos del área TIC se realizan básicamente con 5 herramientas:

– Un Service Desk como componente que integra todo el conjunto de incidencias y peticiones en producción.
– Redmine como sistema de gestión de proyectos: planificación de tareas e interfaz con el repositorio documental (en nuestro caso Alfresco, aunque perfectamente se podría haber utilizado la propia herramienta como gestor documental).
– Alfresco, como repositorio documental.
– Mantis para el reporte de incidencias en la fase de pruebas de la aplicación.
– Una software de agenda compartida, para la gestión de nuestras citas y reuniones.

Como comenté antes, no se trató de implantar un conjunto de procedimientos de la noche a la mañana, sino que se hizo paulatinamente, asimismo no todas las herramientas se implantaron a la vez, ni el grado de uso de las mismas fue intenso desde el primer momento. Ha sido el tiempo y también determinadas decisiones de los responsables de informática los que han consolidado los procedimientos y las herramientas.

No son las únicas herramientas que utilizamos en el departamento de desarrollo ya que la realización de determinados procesos, requieren de otras herramientas complementarias que nos aportan, además una serie de ventajas:

– Subversion: Como sistema de gestión de fuentes y sus versiones.
– Artifactory: Como repositorio de librerías dependientes.
– Hudson: Para la automatización del proceso de compilación, generación del desplegable e interacción con Sonar (tenemos previsto próximamente el uso de Hudson para realizar el despliegue completo de una aplicación).
Sonar: Para el análisis estático de código.
– Enterprise Architect: Diseño de modelos (requisitos, casos de uso, etc…) y de documentación a partir de los mismos.

Como he comentado antes, los procedimientos requieren herramientas y las herramientas procedimientos, los unos sin los otros no terminan por producir buenos resultados.

Los procedimientos deben estar por escrito y ser dados a conocer por quienes los tienen que cumplir y se debe hacer un seguimiento de su implantación, por lo menos hasta que se consiga que la organización asimile la nueva dinámica de funcionamiento.

¿Por dónde se empieza? Supongamos que ya tenemos definida una dinámica de trabajo en cuanto al propio proceso de codificación de software, si no es así, ese debe ser el inicio (es decir, habría que establecer un framework de desarrollo, la selección de un IDE, de un sistema de gestión de versiones, una herramienta de integración continua, etc…, unos entornos de preentrega, un sistema de atención interna de dudas, sugerencias, etc… en el proceso de desarrollo (así como la persistencia de aquellas que sean más interesantes, para permitir la consulta futura), etc…

A partir de ahí, el siguiente paso debe ser controlar hacia dónde se enfoca la dedicación de los empleados, lo que hace necesario la existencia de una herramienta de imputación horaria. Esta gestión de incurridos es fundamental si la función principal de tu organización es la prestación de servicios a terceros. En el caso de mi organización no tenemos ninguna herramienta de esas características porque somos principalmente clientes de los trabajos (lo que ha hecho que no sea algo prioritario).

A continuación se debe trabajar en la gestión de las entradas de incidencias y peticiones por parte de terceros, así como su planificación. De esta forma se consigue dar un orden al trabajo, saber qué esta haciendo cada cual en cada momento y poder planificar los recursos humanos en el tiempo, de manera que se reduzca el número de tiempos muertos y cada persona se utilice, en la medida que sea posible, en aquellos proyectos y actividades donde se pueda aprovechar de mejor manera su potencial.

Lo comentado en el párrafo anterior se puede hacer en paralelo, con la obligación de que cada reunión con un cliente tenga como resultado final un acta (siguiendo en la medida de lo posible un mismo formato y que se almacena de la misma forma para todos los proyectos), que además debe ser enviada a los mismos. Como podéis ver, estos procedimientos que no requieren gran esfuerzo implantarlos, producen beneficios innegables. Solo requiere pequeños cambios en algunas de las rutinas de los empleados (el desarrollo de software es mucho más que tener abierto Eclipse toda la jornada laboral).

Una vez llegado a este punto resulta recomendable integrar el sistema de imputación horaria con el sistema de planificación de proyectos para tener el tiempo real que se ha invertido en cada tarea.

Sabemos cuánto se ha presupuestado cada proyecto, cuánto se lleva invertido en cada uno y aproximadamente el grado de avance en los mismos. Con esas variables es posible conocer el estado de los costes de cada proyecto, algo fundamental para detectar desviaciones a tiempo y tomar medidas (de nada sirve detectar que hay problemas si no se toman decisiones al respecto).

¿Por dónde se sigue? A partir de aquí, entrarán en juego, las preferencias personales. En mi caso, yo potenciaría el establecimiento de una normativa documental en los desarrollos apoyada en una herramienta CASE. Los desarrolladores odian documentar, principalmente porque no se sabe documentar (duele, pero es la verdad) y porque no se tiene un procedimiento, técnica y mecánica para hacer que ese proceso “insufrible” sea menos doloroso, es decir, que haga que el proceso de documentación sea más eficiente y productivo. Si con documentación vas a tener problemas con el cliente de todas maneras, ya sabemos todos los problemas que se tiene cuando se carece de ella, donde al final el cliente meterá casi tantos goles por la escuadra como quiera, ya que él dispone de todas las cartas y tú de ninguna. Además, la documentación puede guiar el proceso de desarrollo, cuestión de acostumbrarse a trabajar con ella y además permite dar un acabado a los proyectos que puede dar lugar, en muchos casos, a marcar la diferencia entre un proveedor y otro.

¿No crees en los procedimientos? Prueba a implantar alguno, hazle un seguimiento y mide los resultados, lo mismo cambias de opinión.

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.

Todo lo que sea huir de métodos artesanales en los procesos de desarrollo de software supone tiempo y dinero o lo que es lo mismo dinero y dinero.

1) Intenta que todos los desarrollos de la empresa sigan un mismo framework siempre que sea posible (en ocasiones las imposición de una determinada arquitectura o tecnología por el cliente lo impide, pero en el resto de casos, siempre que se pueda, haz uso del framework). El framework además es recomendable que esté recogido en un libro blanco de desarrollo (que va más allá del framework, lógicamente) y mantener ese libro blanco actualizado. Este framework único facilita la movilidad de los programadores entre proyectos y la mantenibilidad de los sistemas. No tengas miedo en actualizar el framework o el libro blanco, si aparece o encuentras alguna librería, componente, arquitectura, etc… mejor que la que usas, más estable, más robusta y/o que te permite una mayor productividad no dudes en cambiar el framework, eso sí, debe hacerse con prudencia y con un espacio de tiempo razonable entre cambio y cambio.

2) Intenta que el framework se base en estándares.

3) Si además del framework base, se tienen componentes software concretos y completos que resuelven problemáticas cada uno de ellos en diferentes tipos de proyectos, mejor que mejor.

4) Si se tienen productos completos que simplemente requieren su personalización en función del cliente, todavía mejor.

5) Siempre se habla de reutilizar código, pero si se consiguen reutilizar requisitos de proyectos o lo que es lo mismo la experiencia, también resulta de gran importancia. Para esto hay que documentar y establecer mecanismos que permitan localizar en la documentación de proyectos lo que se quiere y de esta forma obtener conocimiento.

6) La documentación de los proyectos queda obsoleta por la evolución de los mismos y resulta muy costosa mantenerla, por lo tanto, lo mejor es tener poca documentación pero buena y mantenerla actualizada. Por otro lado, toda aquella documentación que se pueda automatizar bienvenida sea y toda aquella documentación que se pueda sustituir mediante la aplicación de ingeniería inversa sobre cualquiera de los elementos del programa, sustitúyase.

7) Si existe software de gestión de versiones, MAVEN y herramientas software para definir entornos de integración continua, utilícense. Eso sí, bien. De nada te vale tener los fuentes en SVN si no tienes una buena política de etiquetado, de nada te vale usar MAVEN si no estrujas su potencial para automatizarte tareas, etc…

8) Independientemente de que se definan buenas prácticas hay que verificar que se siguen. Si puedes ten uno o más arquitectos que vayan sondeando el estado tecnológico de cada proyecto.

9) Ten documentado como es el proceso de implantación de software en tus clientes, permitirá ahorrar mucho tiempo.

10) Nunca es una pérdida de tiempo cada minuto que dediques a probar la aplicación antes de entregarla al cliente.

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.

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

– Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

– Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

– Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

– Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

– Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

– Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

– Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.