Curso MISyC: Tópicos Avanzados en ingeniería de Software Herramientas para la administración ágil de un proyecto de software María Consuelo Franky lfranky@javeriana.edu.co 1
Administración de las tareas del proyecto ilustración con ANT 2
Importancia de Ant como manejador del proyecto El ANT del cualquier proyecto Java es necesario para manejar con flexibilidad todas las tareasrelacionadas con el proyecto: compilación empaque publicación en el servidor generación de documentación javadoc generación de referencias cruzadas testing compilación por aspectos...etc. El ANT permite manejar el proyecto de forma independiente de los ambientes de programación 3
Principales tareas del Ant Contiene: definición de propiedades definición de filesets, zipefilesets, paths principales objetivos (targets) para manejar un proyecto Java EE: clean: elimina archivos generados compile: compilación de todos los fuentes java war: empaca las páginas de la aplicación jar: empaca todos los componentes ejb ear: empaca toda la aplicación en un archivo.ear deploy: publica la aplicación test: tests funcionales (con TestNG) javadoc: genera documentación de los fuentes java 4
Ejemplo del Archivo build.xml Atributos del proyecto: nombre, tarea por defecto, y directorio base Definición de propiedades, filesets, y paths <?xml version="1.0"?> <project name="demowithskeleton" default="deploy" basedir="."> <!-- external file of properties --> <property file="${basedir}/build.properties"/> <!-- global properties --> <property name="project.name" value="demowithskeleton"/> <property name="src.model.dir" value="src/main"/> <property name="lib.dir" value="lib"/> <property name="packaged.archive" value="dist/${project.name}.ear"/> <property name="deploy.dir" value="${jboss.home}/server/default/deploy"/> <property name="javac.debug" value="true"/> <property name="javac.deprecation" value="false"/>... <! - filesets --> <fileset id="lib" dir="${lib.dir}"> <include name="*.jar"/> </fileset> <! - paths --> <path id="build.classpath"> <fileset refid="lib"/> </path> 5
Objetivos init y compile dependencia entre objetivos (targets) un objetivo se implanta mediante tareas (tasks) además de las tareas predefinidas se pueden definir nuevas (taskdef) <! - target init --> <target name="init" description="initialize the build"> <mkdir dir="${jar.dir}"/> <mkdir dir="${ear.dir}"/> <mkdir dir="${war.dir}"/> <mkdir dir="${dist.dir}"/> </target> <! - target compile (usa un path) --> <target name="compile" depends="init" description="compile the Java source code"> <javac classpathref="build.classpath" destdir="${jar.dir}" debug="${javac.debug}" deprecation="${javac.deprecation}" nowarn="on"> <src path="${src.model.dir}"/> <src path="${src.action.dir}"/> </javac> </target> 6
Objetivos para reunir el contenido del jar y del war <! - target jar--> <target name="jar" depends="compile" description="build the JAR structure"> <copy todir="${jar.dir}/meta-inf"> <fileset dir="${basedir}/resources/meta-inf"> <include name="ejb-jar.xml"/> </fileset> </copy> </target> <! - target war --> <target name="war" depends="compile" description="build the WAR structure "> <copy todir="${war.dir}"> <fileset dir="${basedir}/view"/> </copy> <copy todir="${war.dir}/web-inf/lib"> <fileset dir="${lib.dir}"> <includesfile name="deployed-jars-war.list"/> </fileset> </copy> <copy todir="${war.dir}/web-inf" file="${basedir}/resources/web-inf/web.xml"> </copy> </target> 7
Objetivo para reunir librerías y descriptores del ear <! - target ear --> <target name="ear" description="build the EAR structure"> <copy todir="${ear.dir}"> <fileset dir="${lib.dir}"> <include name="jboss-seam.jar"/> </fileset> </copy> <copy todir="${ear.dir}/lib"> <fileset dir="${lib.dir}"> <includesfile name="deployed-jars-ear.list"/> </fileset> </copy> <copy todir="${ear.dir}/meta-inf"> <fileset dir="${basedir}/resources/meta-inf"> <include name="application.xml"/> <include name="jboss-app.xml"/> </fileset> </copy> </target> 8
Objetivo para empacar el jar, el war y el ear <! - target stage --> <target name="stage" depends="jar,war,ear"/> <! - target archive --> <target name="archive" depends="stage" description="package the archives"> <jar jarfile="${dist.dir}/${project.name}.jar" basedir="${jar.dir}"/> <jar jarfile="${dist.dir}/${project.name}.war" basedir="${war.dir}"/> <jar jarfile="${dist.dir}/${project.name}.ear"> <fileset dir="${ear.dir}"> <exclude name="${project.name}_jar/**"/> <exclude name="${project.name}_war/**"/> </fileset> <fileset dir="${dist.dir}"> <include name="${project.name}.jar"/> <include name="${project.name}.war"/> </fileset> </jar> </target> 9
Objetivos para publicar el ear <! - target datasource --> <target name="datasource"> <fail unless="jboss.home">jboss.home not set</fail> <copy file= "${basedir}/resources/${project.name}-ds.xml" tofile="${deploy.dir}/${project.name}-ds.xml"/> </target> <! - target deploy--> <target name="deploy" depends="archive,datasource" description="deploy the packaged archive"> <fail unless="jboss.home">jboss.home not set</fail> <copy todir="${deploy.dir}" file="${dist.dir}/${project.name}.ear"/> </target> 10
Obejtivo para ejecutar tests <! - target builtest --> <target name="buildtest" > <copy todir="${test.dir}"> <fileset dir="${basedir}/resources"> <exclude name="meta-inf/persistence*.xml"/> <exclude name="import*.sql"/> <exclude name="${project.name}-*-ds.xml"/> <exclude name="components-*.properties"/> </fileset> <fileset dir="${basedir}/view"/> </copy>... </target> <! - target test --> <target name="test" depends="buildtest" description="run the tests">... <testng outputdir="${basedir}/test-report"> <jvmarg line="-dsun.lang.classloader.allowarraysyntax=true"/> <classpath refid="test.path"/> <xmlfileset dir="${test.dir}" includes="*test.xml"/> </testng> </target> 11
Objetivo para generar la documentación javadoc <! - target javadoc --> <target name="javadoc" depends="compile"> <mkdir dir="${dist.dir}/apidoc"/> <javadoc classpathref="build.classpath" destdir="${dist.dir}/apidoc" use="true" protected="true" version="true" windowtitle="${project.name} API Documentation" doctitle="${project.name} API Documentation" link="http://java.sun.com/j2se/5.0/docs/api"> <packageset dir="${src.action.dir}" defaultexcludes="yes"> <include name="*/**"/> </packageset> <packageset dir="${src.model.dir}" defaultexcludes="yes"> <include name="*/**"/> </packageset> </javadoc> </target> 12
Categorías de tasks ofrecidos por ANT Archive Tasks :empaque de archivos Audit/CoverageTasks : genera estadísticas de paquetes Java Compile Tasks Deployment Tasks Documentation Tasks EJB Tasks Execution Tasks : ejecuta comandos File Tasks : crear, copiar, eliminar, expresiones regulares, Java2 Extensions Tasks Logging Tasks Mail Tasks Miscellaneous Tasks Pre-process Tasks Property Tasks Remote Tasks : ftp, telnet, SCM Tasks : tareas sobre diversos manejadores de versiones Testing Tasks : Junit, TestNG, 13
Configuración y manejo de las bitácoras del proyecto ilustración con Log4j 14
En desarrollo: Importancia de manejar la bitácora de un proyecto registra las banderas y la información de excepciones que permiten depurar el proyecto En mantenimiento: las banderas y la información de excepciones permiten corregir bugs por medio de compilación por aspectos o por intercepción pueden generarse banderas que ayudan a corregir bugs (por ejemplo el manejo de conexiones a la base de datos) En operación: las banderas muestran información de auditoría (usuario, IP, hora, clase java, mensaje, ) por intercepción se pueden generar datos sobre tiempos de servicios Desventaja: pueden afectar el tiempo de respuesta de la aplicación 15
loggers: Apache Log4j : elementos jerarquía del espacio de la bitácora que permite mostrar unas banderas y ocultar otras utiliza la misma jerarquia de los paquetes Java (por ej: puede haber un logger com.enterprise.booking) cada clase Java tiene un logger asociado por defecto (por ej: com.enterprise.booking.class1) hay un logger raiz sin nombre nivel de un logger a cada logger se asocia un nivel de criticidad de banderas que puede mostrar: DEBUG < INFO < WARN < ERROR < FATAL el logger raíz por defecto tiene nivel DEBUG pero puede indicar otro; los demás pueden o no indicar nivel (caso no: heredan el nivel del ancestro más cercano) cada pedido de mostrar una bandera a un logger debe indicar el nivel de criticidad del pedido: el logger mostrará la bandera solo si el nivel del pedido es >= que el nivel del logger 16
appenders: destino "fisico" a donde se enviarán las banderas de los loggers tipos de appenders: console file GUI component remote socket server JMS NT Event Logger remote UNIX Syslog daemon logger com.acme.proy1 logger com.acme.proy1.clase1 logger root logger com.acme.proy1.seg appender1 appender2 appender3 appender4 logger com.acme.proy1.seg.clase2 Relación entre loggers y appenders a cada logger se le pueden asociar uno o varios appenders cada bandera solicitada a un logger se enviará a todos sus appenders y a todos los appenders de los loggers ancestros ej: si el logger raiz está asociado a la consola, todos los demás loggers también enviarán sus banderas a la consola esta aditividad hacia los ancestros se interrumpe cuando un appender configura la propiedad de Append en false 17
layout de un appender: es el formato de las banderas que usará el appender convenciones del formato similares a las de printf de C ejemplo: "%r [%t] %-5p %c - %m%n" imprime bandera 176 [main] INFO org.foo.bar un mensaje. donde: %r número de milisg desde el comienzo del programa %t thread que imprime la bandera %p nivel de la bandera %c logger origen de la bandera %m mensaje de la bandera %n cambio de línea 18
Como se usa la bitácora log4j desde una clase Java (Java EE 5 con Seam) Facilidades de Log proporcionadas por Seam importación de clases seam: import org.jboss.seam.annotations.logger; import org.jboss.seam.log.log; en los EJB hay inyección estática (1 sola vez cuando se instancia la clase) @Logger private Log log; permite mostrar banderas que combinan parámetros y variables de contextos (expresiones EL): log.info("cancel booking#0 for#{user.username}", booking.getid()); el método sobre el log indica nivel de criticidad de las banderas:debug(),info(), trace(), error(), fatal() pueden mostrar stacktrace cuando hay una excepción el log está asociado a la consola (logger root asociado a appender consola) pero puede configurarse para asociarse a un archivo separado 19
Configuración de appenders: ejemplo JBoss agregar al archivo jboss-log4j.xml bajo el directorio del servidor server/default/conf un appender de tipo file para una nueva aplicación "booking": <!-- BOOKING appender for booking application: a size based file rolling appender --> <appender name="booking" class="org.jboss.logging.appender.rollingfileappender"> <errorhandler class="org.jboss.logging.util.onlyonceerrorhandler"/> <param name="file" value="${jboss.server.home.dir}/log/booking.log"/> <param name="append" value="false"/> <param name="maxfilesize" value="1000kb"/> <param name="maxbackupindex" value="12"/> <layout class="org.apache.log4j.patternlayout"> <!-- Patron utilizado en BOOKING: Date Priority [Category] (User) Message\n --> <param name="conversionpattern" value="%d{absolute} %-5p [%c{1}] (%X{user}) %m%n"/> </layout> </appender> ver en jboss-log4j.xml otros ejemplos de appenders (asociados a JMS, email, socket, etc.) 20
en el patrón de banderas hay un atributo user no estándar para log4j; la aplicación debe asignarle valor (igual puede hacerse para mostrar la IP del usuario, ) el logger raiz de la aplicación (ej: com.enterprise.booking) se debe asociar al appender BOOKING previamente definido; además se le asigna un nivel de banderas (ej: DEBUG limita a banderas con nivel debug o superior): <!-- com.project logger is associated to BOOKING appender; limited to DEBUG level --> <category name="com.enterprise.booking"> <priority value="debug" /> <appender-ref ref="booking"/> </category> 21
para disminuir las banderas de los paquetes utilitarios, a sus loggers se les asocia un nivel alto <!-- Limit the org.apache category to INFO as its DEBUG is verbose --> <category name="org.apache"> <priority value="info"/> </category> el logger root tiene nivel y appenders asociados: <root> <priority value="debug"/> <appender-ref ref="console"/> <appender-ref ref="file"/> </root> 22
dar valor al atributo user desde la aplicación: asignarle a user el valor del nombre del usuario que hizo login: import org.apache.log4j.mdc;... @Resource javax.ejb.sessioncontext ctx;... Principal callerprincipal = ctx.getcallerprincipal(); String username = callerprincipal.getname(); MDC.put("user", username); efecto final: las banderas registradas en booking.log informan hora, prioridad, clase, usuario, mensaje: 10:24:39,582 INFO [LoginAction] (cfranky) logout 10:24:48,644 INFO [LoginAction] (cfranky) login 10:24:48,644 INFO [LoginAction] (cfranky) username from principal=sysadmin 10:24:48,644 INFO [LoginAction] (sysadmin) ==== NEW LOGIN FOR USER=sysadmin 10:24:48,660 INFO [LoginAction] (sysadmin) maxinactiveinterval in seconds=1800 10:24:48,660 INFO [LoginAction] (sysadmin) sessiontimeout parameter, value=300 el mismo patrón de banderas puede aplicarse al appender CONSOLE para que la consola produzca la misma información 23
Disciplina de desarrollo iterativo de casos de uso a través de ramas de un Manejador de versiones ilustración con Subversion 24
Importancia de manejar el repositorio de versiones del proyecto Los SCM (Software Configuration Management systems) permiten la integración del trabajo de los miembros del proyecto Guardan la historia de todas las versiones del software del proyecto permiten regresar de manera consistente a una versión anterior los elementos versionados son directorios y cualquier tipo de archivo incluyendo documentos, fuentes y binarios puede mostrar la historia de cambios sobre un elemento Maneja las versiones sucesivas en un tronco permitiendo abrir ramas con versiones que divergen del tronco permiten aislar el desarrollo de las ramas del desarrollo del tronco permiten que la versión de una rama pueda ser integrada al tronco 25
Arquitectura de Subversion (sucesor de CVS) tomado de [Collins 2004] 26
Esquema de trabajo con Subversion tomado de [Duvall 2010] 27
Conceptos de Subversion (SVN) Repositorio sistema central donde se guardan todos los datos del proyecto en forma de directorios y archivos se mantiene la historia de cada dato los usuarios pueden leer datos del repositorio => bajar porción del repositorio a la máquina del usuario, para una versión seleccionada escribir sobre datos del repositorio => subir datos de la máquina del usuario al repositorio, para la versión actual tomado de [Collins 2004] 28
Manejo del control de concurrencia en las escrituras sobre el repositorio todos los usuarios pueden leer un mismo archivo A (bajándolo a sus máquinas) sin necesidad de poner candados sobre el repositorio todo usuario puede modificar su copia local del archivo A en forma independiente de los demás usuarios cuando un usuario u escribe la nueva versión del archivo A sobre el repositorio: si el repositorio todavía contiene la versión de A que leyó el usuario u, la escritura tiene éxito si el repositorio contiene una versión de A distinta de la leída por el usuario u, este usuario debe leer la nueva versión y mezclarla con la suya, antes de volver a intentar a escribir (actualización/resolución de conflictos + escritura) 29
La escritura de una porción del proyecto (incluyendo varios directorios/archivos nuevos/modificados/eliminados) es atómica Cada escritura exitosa crea una nueva revision del repositorio c/revisión es una nueva versión de todo el árbol del proyecto ejemplo: revisiones 0, 1, 2, 3 tomado de [Collins 2004] 30
Desarrollo en ramas del repositorio Las ramas permiten desarrollar c/ caso de uso (o resolver c/bug) de forma independiente y paralela al finalizar el desarrollo del CU la rama se integra al tronco se recomienda que cada rama tome una copia de todo el tronco y no de una parte Las ramas permiten desarrollar versiones separadas de un producto de software tomado de [Collins 2004] Estructura recomendada para el repositorio SVN maneja copias ligeras el tag (marca o etiqueta) toma foto del proyecto=> no debe modificarse tanto branch (rama) como tag deberían ser copias del tronco tags 31
Disciplina para trabajar con ramas de Subversion Tareas del administrador para crear una nueva rama (tipicamente para un nuevo caso de uso) TAREA 1- TOMAR EL TRONCO ACTUALIZADO: RESPONSA- BLE Administrador del repositorio ACLARACIONES El tronco siempre está estable suponiendo que todo cambio se maneja en una rama. Comandos desde el cliente de Subversion en Eclipse Aplicar al proyecto el comando Team > Update 2- MARCAR LA VERSION ACTUAL DEL TRONCO CON UNA ETIQUETA Administrador del repositorio Con la etiqueta se logra tener una versión de referencia de cómo estaba el tronco antes de la modificación. Aplicar al proyecto el comando Team > Branch/Tag : 3- ABRIR UNA RAMA A PARTIR DEL TRONCO: Administrador del repositorio Sólo un usuario administrador crea la rama. Aplicar al proyecto el comando Team > Branch/Tag Ver detalles en [Franky&Diaz&Olaya 2010] 32
Tareas del desarrollador para trabajar el requerimiento en la rama TAREA 1- TOMAR EL TRONCO ACTUALIZADO: Hacer un update del proyecto RESPONSA- BLE Cada desarrollador del grupo que está a cargo del cambio. ACLARACIONES El tronco siempre está estable suponiendo que todo cambio se maneja en una rama. Comandos desde el cliente de Subversion en Eclipse Aplicar al proyecto el comando Team > Update 2- SELECCIONAR LA RAMA A TRABAJAR idem Aplicar al proyecto el comando Team > Switch to another Branch/Tag 3- TRABAJAR EN LA RAMA A medida que se trabaja en la rama hacer periódicamente las siguientes acciones: a) Incorporar últimos cambios del tronco hacia la rama. b) Modificaciones y pruebas de la rama. c) En caso de éxito de las pruebas, hacer commit de la rama idem Mientras se construye en la rama se tienen en cuenta cambios que va teniendo el tronco. Al incorporar cambios del tronco hacia la rama pueden surgir conflictos sobre la rama,. Cuando son varios desarrolladores en la misma rama, eventualmente deben resolver conflictos entre ellos cuando hacen commit en la rama PARA INCORPORAR CAMBIOS DEL TRONCO HACIA LA RAMA: Usar comandos Team >Show History y Team > Merge Cuando se resuelvan todos los conflictos debe hacerse commit de toda la rama. 4- FIN DEL TRABAJO EN LA RAMA el desarrollador solicita que el Administrador del repositorio incorpore la rama al tronco.. el Administrador del repositorio es el responsable de modificar el tronco 33
Tareas del probador de una rama TAREA RESPONSA- BLE ACLARACIONES Comandos desde el cliente de Subversion en Eclipse 1- TOMAR EL TRONCO ACTUALIZADO: Probador Aplicar al proyecto el comando Team > Update Hacer un update del proyecto 2- PRUEBAS DE LA RAMA Idealmente el probador debe ejecutar un deck de pruebas de regresión (sobre la rama) que garanticen la compatibilidad hacia atrás. Probador El probador trabaja en la rama para hacer las pruebas. El probador utilizará los siguientes comandos: Seleccionar la rama como el proyecto a trabaja: Team > Switch to another Branch/Tag 34
Tareas del administrador para integrar la rama al tronco TAREA 1- TOMAR EL TRONCO ACTUALIZADO: Hacer un update del proyecto RESPONSA- BLE Administrador del repositorio ACLARACIO-NES No debería haber cambios pendientes sobre el tronco, suponiendo que todo cambio se maneja en una rama. Comandos desde el cliente de Subversion en Eclipse Aplicar al proyecto el comando Team > Update 2- EL ADMIINISTRADOR INTEGRA LA RAMA AL TRONCO a) Selecciona el tronco como el proyecto a trabajar b) Marca con una etiqueta el tronco (antes de integración) c) Integra la rama al tronco, resolviendo posibles conflictos Administrador del repositorio Con la etiqueta del tronco antes de integrar la rama se logra tener una versión de referencia de cómo estaba el tronco antes de la integración. Con la etiqueta del tronco después de integrar la rama se obtiene la nueva versión del tronco. NOTA: se necesita rol administrador para crear etiquetas Aplicar los siguientes comandos: Seleccionar el tronco como el proyecto a trabajar con Team > Switch to another Branch/Tag Para poner etiquetas sobre el tronco: con el comando Team > Branch/Tag Para integrar la rama hacia el tronco: con el comando Team > Merge d) Marca con una etiqueta el tronco (después de integración) 35
Referencias [Collins 2004] "Version Control with Subversion: For Subversion 1.5", Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato, O'Reilly, 2004. [Duvall 2010] "Continuous Integration: Patterns and Anti-Patterns", Paul M. Duvall, Dzone RefcardZ, 2010. http://wwwdzone.com [Franky&Diaz&Olaya 2010] "Protocolo para trabajar con repositorios SVN por medio de ramas". Universidad Javeriana, 2010. http://sitiogforgeconstrucolectiva/gf/project/tiggerrummy/docman/?sub dir=3 36