Desarrollo del equipo y gestión de artefactos en WebSphere Integration Developer v6.2

Este artículo discute la gestión del control de fuentes y el control de versión de los módulos dentro de WID v6.2. Se trata de una versión actualizada de Team Development with WebSphere Integration Developer and WebSphere Process Server del año 2006, que se basaba en WID v6.0.2. Nosotros usamos Subversion como la herramienta de gestión de control de fuentes.

Introducción

Este documento analiza los procedimientos de gestión de control de fuentes (SCM) en relación con WebSphere Integration Developer (WID) v6.2. Además, también potenciamos las capacidades de desarrollo del equipo en relación con WID y Eclipse usando Subversion como el mecanismo para la gestión remota de control de fuentes.

Comenzamos con las generalidades de los aspectos fundamentales del desarrollo del equipo y discutimos la estructura de un módulo WID. Además, se describen procedimientos que demuestran como interactuar con el servidor de Subversion dentro de WID (lo que incluye los elementos esenciales de gestión de control de fuentes de Subversion). También se analizan los temas avanzados de Subversion.

Asumimos que usted ya tiene algo de experiencia con WID y los aspectos fundamentales de la gestión de control de fuentes. Este artículo se basa estrictamente en la interacción desde el lado del cliente entre WID y Subversion. La configuración del servidor es un tema avanzado que escapa al alcance de esta discusión.


Generalidades de un proyecto WID y del desarrollo colaborativo

Estructura del proyecto WID

Todas las aplicaciones WID consisten de un módulo SCA y un conjunto opcional de dependencias de biblioteca de servicios. El módulo SCA incluye todos los artefactos centrales necesarios para implementar y ejecutar la aplicación. Estos artefactos centrales pueden llegar a incluir, pero no se limitan a, objetos de negocios, interfaces, mapas y procesos de negocios. Cuando la aplicación se implementa e instala, se genera el código Java basándose en la lógica del artefacto central.

Todos los módulos SCA también incluyen un conjunto de módulos de staging generados. Como los módulos de staging definen las dependencias JEE y los contenidos web opcionales, generalmente no es necesario que el usuario los modifique. Como los módulos de staging no incluyen la lógica BPM creada, no son visibles en la perspectiva Business Integration, pero se los puede visualizar en la perspectiva denominada JEE o en la denominada Resource.

Los nombres de los módulos de staging se basan en el nombre base del módulo SCA. Por ejemplo, asuma que un módulo SCA denominado HelloWorld existe en el espacio de trabajo WID. Luego de que se construye el módulo SCA, se crean los siguientes módulos de staging:

  • HelloWorldApp
  • HelloWorldEJB
  • HelloWorldWeb
Figura 1. Módulos de staging para una aplicación WID
Módulos de staging para una aplicación WID

Tenga en cuenta que ModuleNameWeb sólo se creará si el módulo SCA tiene definidos enlaces de punto final de servicio web en el módulo SCA. En general, sólo el módulo SCA y las bibliotecas dependientes necesitan que se las gestione en control de fuentes. Pero, en ciertos casos, es posible que usted también deba gestionar los módulos de staging.

Artefactos generados y de autor

Se dice que los artefactos creados por el usuario en WID son de autor. Si el usuario crea un objeto de negocios o una interfaz WSDL nueva, existirá el archivo .wsdl o .xsd correspondiente en el espacio de trabajo. En algunos casos, un sólo tipo de artefacto consiste de múltiples archivos de respaldo. Por ejemplo, cuando usted crea un proceso BPEL nuevo, algunos archivos de autor, que incluyen los archivos .bpel, .bpelex y Artifacts.wsdl, se crean en el espacio de trabajo. Cada uno de estos archivos es de autor, ya que todos ellos son necesarios para que se pueda crear el módulo exitosamente.

Luego de crear un módulo en WID, se genera el código Java para los artefactos de autor durante el proceso de implementación. Generalmente, los artefactos generados son clases Java basadas en la lógica definida en los artefactos BPM de autor. Como los artefactos WID generados no son necesarios durante el desarrollo de la aplicación, no es necesario gestionarlos en control de fuentes.

En WID v6.0.2, existían muchas inconsistencias entre los artefactos de autor y los generados. Algunas actividades de generación de artefactos ocurrían durante el tiempo de creación, mientras que otros artefactos se generaban durante la instalación de la aplicación. Se pudo mejorar este proceso en gran medida en WID v6.2, ya que todas las actividades de generación de artefactos ahora ocurren durante la implementación y la instalación de la aplicación. Por lo tanto, no aparecen archivos Java generados en un módulo SCA de WID v6.2.

A diferencia de los módulos SCA, los módulos de staging son únicos en cierta forma. Los módulos de staging aparecen en el espacio de trabajo luego de que se crea el módulo SCA. Debido a esto, no es necesario gestionar los módulos de staging dentro de SCM, siempre que no incluyan ningún tipo de contenido personalizado o cambios al descriptor de implementación de JEE. Si usted agregar contenidos de autor a un módulo de staging o si realiza modificaciones personalizadas a la implementación de JEE, los módulos de staging afectados también se deberán gestionar en control de fuentes para que se puedan preservar estos cambios. Si usted agrega contenidos personalizados al módulo de staging Web, como un HTML o páginas JSP, el módulo ModuleNameWeb se deberá gestionar en el repositorio de control de fuentes remotas. Para evitar cualquier tipo de confusión, considere la creación de un módulo Web independiente para todos los contenidos web personalizados, en vez de confiar en el módulo de staging denominado ModuleNameWeb.

Propiedades derivadas y no derivadas

Las propiedades de derivación de un artefacto están muy relacionadas con los artefactos de autor y generados. Un artefacto puede ser derivado o no derivado, según lo que se especifique en las propiedades de derivación del archivo en la vista Physical Resources (Recursos físicos) o en la perspectiva Resource (Recurso), como se puede observar a continuación.

Figura 2. Propiedades de derivación de un artefacto
Propiedades de derivación de un artefacto

En algunos productos SCM, como CVS, las propiedades de derivación de una carpeta o de un archivo determinan si un artefacto se gestiona o no en el sistema SCM. Aunque CVS ignora todos los artefactos derivados, Subversion no cumple con este patrón. Todos los archivos en el espacio de trabajo, sin importar sus propiedades de derivación, estarán comprometidos con el repositorio de manera predeterminada. Usted puede configurar filtros en las preferencias de Subversion para excluir archivos y que no se los gestione en control de fuentes. Afortunadamente, en WID v6.2, esto no suele ser necesario, ya que la generación de artefactos no ocurre hasta la implementación o la instalación de la aplicación.

Los artefactos derivados no aparecen en los módulos SCA de WID v6.2. Por lo tanto, nunca se deberían modificar las propiedades de derivación de los artefactos. En las versiones anteriores de WID, las propiedades de derivación de los artefactos se podían modificar sin que ello tuviese muchas consecuencias. Pero en WID v6.2 esto ya no es tan así. Los generadores WID borran inmediatamente todos los artefactos específicos a WPS cuyas propiedades se modifican a derivadas del espacio de trabajo. Esto ocurre porque WID entiende que los artefactos derivados son generados, y los artefactos generados sólo deberían estar presentes durante el momento de la implementación o la instalación. Por lo tanto, si un artefacto pasa a ser derivado, WID asume que este archivo se debe generar y, por ello, no debería existir en el espacio de trabajo.

Lo que se aprende de todo esto es muy simple: las propiedades de derivación para los artefactos WID v6.2 se hacen cumplir estrictamente en el módulo SCA primario y nunca se los debería modificar.

Editor de implementación de módulos (y cómo se relaciona con el módulo de la aplicación)

En las versiones anteriores de WID, las propiedades de implementación del módulo (como, por ejemplo, la seguridad de los servicios web y las modificaciones al descriptor de implementación de JEE) se tenían que realizar en el descriptor de implementación del módulo de staging de la aplicación.

Esto ocasionaba dos problemas. En primer lugar, la reimplementación del módulo sobrescribía todas las modificaciones personalizadas que se habían realizado en ModuleNameApp. Por lo tanto, solía ser necesario reconfigurar todas las modificaciones personalizadas. En segundo lugar, al realizar estos cambios, el módulo de la aplicación incluía cambios de autor y, por lo tanto, se lo tenía que gestionar en control de fuentes. Lo ideal consiste en limitar los módulos y los artefactos en control de fuentes a sólo aquellos estrictamente de autor.

Desde WID v6.2, varias propiedades de implementación se pueden configurar a través del editor de implementación del módulo ubicado en el módulo SCA primario. El editor de implementación del módulo guarda las modificaciones en ibm-deploy.scaj2ee en el módulo SCA, que realiza el mapeo hacia el descriptor de implementación de JEE durante la implementación. Aunque el editor de implementación del módulo no tiene todas las propiedades del descriptor de implementación, en la mayoría de los casos, debería ser más que suficiente para sus requisitos de implementación.

Se puede abrir el editor de implementación del módulo presionando el botón derecho del mouse sobre el nombre del módulo y seleccionando Open Deployment Editor (Abrir editor de implementación).

Figura 3. Editor de implementación del módulo
Editor de implementación del módulo

Desarrollo del equipo con WID y Eclipse

Complementos WID para el cliente de Subversion

Para interactuar con el servidor de Subversion, usted necesita instalar un componente cliente en su entorno WID. Existen dos complementos cliente de Subversion que se pueden usar dentro de WID: Subclipse y Subversive. Aunque ambos complementos tienen conjuntos de características similares, se dice que Subversive es la ruta estratégica oficial para Eclipse. Por lo tanto, usamos el complemento Subversive para todos los escenarios que se discuten en este documento.

El complemento cliente de Subversion no se incluye en la lista de complementos predeterminados de Eclipse o WID. Por lo tanto, se lo debe instalar. Luego de instalar el complemento, usted podrá interactuar completamente con el repositorio de Subversion desde WID.

Las secciones Appendix (Anexos) y Reference (Referencias) incluyen información sobre la configuración del complemento cliente de Subversion.

Perspectivas y vistas dentro de WID

Existen varias perspectivas y vistas en WID y Eclipse que resultan muy útiles para el desarrollo colaborativo. Las siguientes cuatro son críticas para el desarrollo del equipo:

  • Business Integration (Integración de negocios)
  • Resource (Recursos)
  • Team Synchronizing (Sincronización del equipo)
  • SVN Repository Exploring (Exploración del repositorio SVN). Debe tener en cuenta que, si no está usando Subversion, el nombre de esta perspectiva puede ser diferente
Figura 4. Perspectivas que se usan para el desarrollo del equipo dentro de WID
Perspectivas que se usan para el desarrollo del equipo dentro de WID

Perspectiva Business Integration

La perspectiva Business Integration es la parte integral de WID, ya que el diseño del artefacto, el desarrollo y la integración del componente ocurre aquí. Además, la mayoría de las actividades de desarrollo del equipo (desproteger, confirmar, actualizar) se puede llevar a cabo a través de esta vista.

Vista Physical Resources
Como parte de la perspectiva Business Integration, la vista Physical Resources le ofrece una lista de los artefactos y los recursos relevantes para los módulos y las bibliotecas WID. La vista Physical Resources es similar a la vista Project Explorer (Explorador de proyecto) en la perspectiva Resource, excepto porque sólo se muestran módulos SCA (no se muestras los módulos de staging).

Aunque no es tan importante en v6.2, la vista Business Integration incluye una opción denominada Show Files (Mostrar archivos) que visualiza todos los archivos de autor correspondientes a un artefacto. Por ejemplo, un proceso BPEL guarda su lógica de flujo de proceso en un archivo .bpel. Pero existen otros archivos de respaldo (.bpelex, .mon y Artifacts.wsdl) que son necesarios para que el proceso BPEL se cree de manera adecuada. La opción Show Files resaltará los cuatro archivos.

Use la opción Show Files de la siguiente manera:

  1. Desde la vista Business Integration, presione el botón derecho del mouse sobre el artefacto y seleccione Show Files (Mostrar archivos).
Figura 5. Show files
Show files
  1. Algunos artefactos, como los procesos BPEL, tienen múltiples archivos de respaldo. Cuando usa la opción Show Files, usted podrá ver la siguiente ventana. El filtro Artifact Secondary Files (Archivos secundarios del artefacto) sólo le muestra el artefacto principal. Si usted hace clic sobre Yes (Sí), este filtro se desactivará y se resaltarán todos los archivos de respaldo.
Figura 6. Desactivación del filtro
Desactivación del filtro
  1. Tenga en cuenta que los archivos se encuentran resaltados en la vistaPhysical Resources.
Figura 7. Recursos de HelloWorldProcess
Recursos de HelloWorldProcess

Perspectiva Resource

La vista Project Explorer debajo de la perspectiva Resource incluye Eclipse y ofrece una lista de todos los módulos y los artefactos que se encuentran en el espacio de trabajo (lo que incluye a todos los módulos de staging).

Perspectiva Team Synchronizing

La vista Synchronize (Sincronizar) dentro de la perspectiva Team Synchronizing le permite sincronizar el espacio de trabajo con el repositorio remoto. Además, le permitirá visualizar todos los cambios entrantes y salientes relevantes y, por lo tanto, usted podrá identificar todos los conflictos de fusión apropiados.

Perspectiva SVN Repository Exploring

La perspectiva SVN Repository Exploring le ofrece una lista de todos los módulos o los proyectos que se gestionan en Subversion en la actualidad. Si su proyecto usa un proveedor diferente de SCM, es posible que exista una perspectiva similar.

Los proyectos en la perspectiva SVN Repository Exploring se ordenan según su número de revisión más reciente, aunque también es posible visualizar las revisiones de los módulos y desprotegerlas desde control de fuentes. También es posible desproteger las ramas o las etiquetas definidas para un módulo en particular a través de la vista SVN Repositories (Repositorios SVN). Usted puede usar la vista History (Historial) para visualizar todos los cambios realizados en un módulo determinado.

Vista SVN Repositories
Ésta es la vista principal en la perspectiva SVN Repository Exploring. El árbol de revisión denominado HEAD se visualiza de manera predeterminada e incluye todos los módulos fundamentales junto con sus respectivos troncos, ramas y etiquetas que figuran en el repositorio.

Vista SVN Repository Browser (Navegador de repositorio SVN)
De manera similar a la vista SVN Repositories, esta vista le muestra la fecha y hora de la última modificación, quién la realizó, quién es el propietario del artefacto y cuál es el tamaño del archivo.

Vista History
La vista History visualiza toda la historia de revisión y todo el registro de cambios correspondientes a un módulo o a un artefacto determinado. Esta vista es similar a la vista SVN Repository Browser, excepto porque los artefactos se clasifican por número de revisión en vez de por el nombre del módulo.

Desarrollo del equipo con mediaciones y módulos WESB

Cuando crea un flujo de mediación en WID v6.2, usted tiene la opción de optimizar el flujo de mediación para el desarrollo del equipo. De manera predeterminada, el flujo de mediación se guarda en un solo archivo .medflow para todas las operaciones. Por lo tanto, si usted tiene un flujo con cinco operaciones, toda la lógica existirá dentro de un solo archivo .medflow.

Si la lógica del flujo de mediación se guarda en varios archivos, existirá un archivo .medflow para cada mapeo de operación. Esto resulta beneficioso para el desarrollo colaborativo, ya que cada desarrollador puede ser asignado a un flujo de operación. Tenga en cuenta que, si su flujo de mediación sólo usa una sola operación, la activación de la opción de desarrollo colaborativo no le ofrecerá ningún beneficio.

Figura 8. Opciones de desarrollo del equipo del flujo de mediación
Opciones de desarrollo del equipo del flujo de mediación

Existen varias estipulaciones al momento de guardar mediaciones como diversos flujos:

  • Los mapeos de la operación del flujo de mediación deben existir en el mismo módulo, sin importar si la opción de desarrollo del equipo está activada o no. No cree un módulo independiente para cada flujo de operación.
  • Todos los usuarios deberían desproteger el módulo de control de fuentes. Como cada operación cuenta con su propio archivo .medflow, nunca aparecerán conflictos de fusión en la lógica del flujo de mediación. Sin embargo, pueden ocurrir conflictos de fusión si varios usuarios modifican los artefactos de flujo de no mediación.

Recomendaciones generales para trabajar en un entorno de equipo

Gestión de módulos SCA, bibliotecas y módulos de staging

  • La funcionalidad de desarrollo del equipo se mejoró muchísimo en WID v6.2. Casi todas las interacciones con el servidor SCM se pueden realizar en la perspectiva Business Integration. El paradigma de derivados versus no derivados también se simplificó muchísimo. Todos los artefactos en el módulo de servicio ahora son de autor (no derivados), mientras que todos los artefactos generados y las clases Java (como, por ejemplo, aquellos archivos creados desde una aplicación BPEL) se generan durante la implementación o la instalación de la aplicación.
  • Cuando use bibliotecas, recuerde que la modificación de un BO o de un WSDL compartido puede tener efectos secundarios inesperados que afecten a otros módulos o componentes que también usa dicha biblioteca.
  • Durante la implementación, los generadores WID crean módulos de staging y, generalmente, no se los tiene que gestionar en control de fuentes.
  • Es posible que sea necesario gestionar el módulo de staging denominado ModuleNameApp en el control de versión en algunos casos excepcionales en los que el editor de implementación del módulo no tenga una característica que suele existir en el descriptor de implementación de JEE denominado ModuleNameApp.
  • Es posible que también sea necesario gestionar el módulo de staging denominado ModuleNameWeb en control de fuentes si incluye código personalizado (como, por ejemplo, interfaces de clientes web). En aquellos casos en los que se agreguen contenidos web personalizados, considere la creación de un proyecto Web independiente para los contenidos web dinámicos personalizados. De lo contrario, será necesario gestionar el módulo ModuleNameWeb generado en control de fuentes.

Propiedades de derivación de un artefacto

  • Nunca cambie explícitamente el indicador de derivado en las propiedades del artefacto. A diferencia de lo que solía ocurrir en v6.0.2, las propiedades de derivación son más transparentes en v6.2 y el usuario no las debería modificar. De hecho, si un artefacto WID no derivado (es decir, de autor) pasa a ser derivado, WID borrará el archivo permanentemente del módulo SCA. Esto ocurre porque los generadores de WID v6.2 asumen que un archivo derivado es un archivo generado. Desde la perspectiva de WID, los archivos generados sólo se pueden crear durante la implementación o la instalación. Por lo tanto, WID asume que este artefacto derivado está ahí por error y lo borra del espacio de trabajo. Tenga en cuenta que este comportamiento sólo se presenta en los módulos SCA Los demás módulos (como, por ejemplo, los proyectos Web o Java) pueden incluir artefactos derivados que no se borrarán durante la implementación.
  • Considere usar la opción Show Files en la vista Business Integration para ver una lista de los archivos de respaldo correspondientes a un componente en particular.

Módulos de comprobación desde el control de versión

  • Cuando trabaje con un módulo gestionado en SCM, asegúrese de desproteger todo el módulo del repositorio remoto. Nunca desproteja un artefacto individual (como, por ejemplo, un único archivo WSDL o XSD) de un módulo gestionado en control de fuentes.
  • Aunque varios usuarios pueden desproteger un módulo de manera simultánea, sólo una persona debería tener acceso de escritura al módulo en todo momento. El cumplimiento de estas prácticas puede evitar la ocurrencia de tediosos conflictos de fusión. Si usted necesita realizar cambios a un módulo y desea evitar que otros usuarios realicen cambios, considere bloquear el módulo para que sólo lo pueda modificar la persona que tenga el acceso de escritura correspondiente.

Sincronización con el repositorio remoto

  • Siempre sincronice los cambios con el repositorio antes de realizar cualquier tipo de confirmación o actualización. Aunque no se requiere una sincronización completa antes de confirmar o actualizar artefactos, hacer esto le ofrecerá una lista completa de todos los cambios realizados y también podrá evitar que usted sobrescriba accidentalmente artefactos que otros usuarios hayan guardado.
  • Si ocurren conflictos de sincronización, los desarrolladores deberían fusionar los cambios manualmente en vez de confiar en las técnicas de fusión basadas en texto que usan las herramientas de fusión de WID. Aunque la fusión basada en texto funciona bien con el código Java, esta práctica no resulta tan útil para los artefactos WID basados en XML. Si usa las herramientas de fusión para combinar dos procesos BPEL, usted fusionará código XML sin procesar o texto simple, lo que se opone a los editores GUI estándar que existen para muchos artefactos WID.
  • Cuando un artefacto se elimina de la copia de trabajo local y el módulo se confirma en el repositorio, también se lo eliminará de la revisión de HEAD. No obstante, dependiendo del conjunto de las funciones de SCM, es posible que el artefacto siga existiendo en el repositorio como parte de un conjunto de revisión anterior.

Control de versión del módulo

  • Tenga cuidado porque los módulos sólo “conocen la versión” cuando se los implementa por medio de serviceDeploy. Los módulos con control de versión que se exportan como archivos EAR a través de WID o se agregan a UTE por medio de Add/Remove Projects (Agregar / Eliminar proyectos) no contemplan las propiedades de control de versión de un módulo.
  • Considere gestionar la versión inicial (es decir, 1.0.0) desde el tronco en control de fuentes. Todas las versiones posteriores se deberían colocar en sus propias ramas debajo del tronco raíz.
  • Trate de entender que, en la actualidad, WID no exige el cumplimiento de un patrón incremental de control de versión del módulo. En cambio, el control de versión del módulo es absolutamente arbitrario y lo asigna el usuario. Esto significa que, teóricamente, usted puede tener un módulo 5.2.5 que incluya contenidos anteriores al módulo 1.0.0.
  • Cuando se confirman módulos con control de versión como ramas, usted debe especificar el número de la versión del módulo en el nombre de la rama. Además, usted debe agregar comentarios apropiados en la rama que identifiquen el número de la versión. Esto ayudará a los demás usuarios, que les ofrecerá información sobre la versión que están comprobando.
  • No use el control de versión del módulo en demasía. Lo ideal es que cada versión de un módulo cumpla con un propósito específico (por ejemplo, un módulo con control de versión que se ocupa del tráfico durante las operaciones por temporada). El control de versión del módulo nunca debería remplazar el control de versión de SCM y la historia de revisión. Permita que el sistema de gestión de control de fuentes se ocupe de los cambios de desarrollo típicos de todos los días.

Desarrollo del equipo con Subversion

Preferencias de Subversive

Las preferencias se pueden visualizar o modificar desde Window (Ventana) > Preferences (Preferencias) > Team (Equipo) > SVN. Para todos los ejemplos que se usan en este documento, usamos las opciones predeterminadas de Subversive, lo que debería ser suficiente para la mayoría de los usuarios. Por favor, revise la documentación relativa a Subversive para obtener mayor información sobre las opciones y la configuración de las preferencias.

Figura 9. Preferencias complementarias de clientes Subversive
Preferencias complementarias de clientes Subversive

Aunque es posible modificar algunas preferencias, siempre conserve la opción predeterminada para usar el archivo .project para el nombre del proyecto, en vez de usar el nombre de la carpeta. Aunque es posible modificar esta configuración, los módulos WID confían en el nombre definido en el archivo .project, que también lo usa sca.module, sca.modulex y otros artefactos en el módulo. Al leer el nombre del módulo desde el archivo de metadatos .project, en vez de desde una carpeta definida por el usuario, se pueden evitar las discrepancias de nombre del módulo. Esta configuración se puede encontrar en Preferences > Team > SVN > Repositorio (Repositorio).

Figura 10. Preferencia del archivo .project de Subversion
Preferencia del archivo .project de Subversion

Disposición y estructura del proyecto de Subversion

Los proyectos en Subversion están organizados en el repositorio en una estructura de árbol jerárquico. Existe una gran variedad de formas de organizar sus módulos en Subversion dependiendo de las necesidades de su proyecto y la complejidad de la solución. Para el caso de todos los ejemplos que se incluyen en este documento, optamos por colocar cada módulo o biblioteca en el directorio raíz, pero no existe una forma correcta y una incorrecta de organizar sus módulos en el repositorio de Subversion. Es posible que los proyectos más pequeños se beneficien si se colocan todos los módulos y todas las versiones en una sola carpeta. Mientras que en el caso de las soluciones empresariales complejas, es posible que sea necesario contar con diversas ubicaciones para el repositorio. En cualquiera de estos casos, la estructura de disposición del proyecto dentro del repositorio debería ser consistente.

Tronco, ramas y etiquetas

Dentro de un módulo gestionado, usted tendrá un tronco que sostendrá la base o la versión activa del módulo, al igual que ramas y etiquetas opcionales. Cuando un módulo se gestione inicialmente en SCM, los artefactos se gestionarán en el tronco. Todos los módulos o las bibliotecas WID gestionadas en el repositorio contienen su propio tronco.

Es posible que usted necesite realizar una copia del tronco para conservar un árbol de desarrollo independiente. Para esto son útiles las ramas. Las ramas incluyen una ruta de desarrollo independiente para un módulo en particular y se las suele usar cuando usted necesita gestionar diversos flujos de desarrollo para un módulo. Aunque los artefactos de las ramas se pueden llegar a transformar en algo funcionalmente diferente del tronco, todas las ramas siempre comienzan como una copia del tronco u otra rama. Por ejemplo, usted puede crear una rama que contiene una lógica de proceso diferente para manipular transacciones durante la temporada de ventas por las fiestas, quizá ofreciendo descuentos especiales o incentivos de compra. De igual forma, la ramificación también suele resultar útil en WID al momento de implementar el control de versión del módulo. Sin embargo, usted sólo debería crear ramas cuando tenga una línea de desarrollo independiente. La ramificación nunca debería remplazar la historia de revisión correspondiente a un módulo en particular.

Las ramas, al igual que las etiquetas, tienen su propio conjunto gestionado de artefactos y su historia de revisión. Las etiquetas son muy similares a las ramas, excepto porque se encargan de gestionar una foto de un proyecto o un módulo y no permiten que los usuarios confirmen ningún cambio. A continuación, discutimos las diferencias entre las ramas y las etiquetas.

Etiquetado versus ramificación

El etiquetado es similar a la ramificación dentro de Subversion. Una etiqueta es una foto de un proyecto en un momento determinado. Por ejemplo, es posible que usted desee crear una etiqueta para una versión de producción específica una vez que se haya finalizado con todo el desarrollo del código.

Es posible que considere que las etiquetas son muy similares a las ramas. De hecho, si usted utilizase las herramientas de Subversion de línea de comandos para crear etiquetas, se daría cuenta de que no existe ninguna diferencia en la forma en la que se crea una etiqueta o una rama. Fundamentalmente, son lo mismo. Esto quiere decir que no existen diferencias técnicas entre las etiquetas y las ramas. Simplemente, se las clasifica de manera diferente de acuerdo con su uso específico. Si los usuarios no confirman los cambios a una foto, seguirá siendo una etiqueta. Sin embargo, si los cambios se confirman a una foto o etiqueta, se transformará en una rama.

Números de revisión del repositorio

Cuando un módulo o un artefacto se confirman al repositorio, se asigna un número de revisión al módulo y a sus artefactos. Cada número de revisión representa una foto histórica de un artefacto. De manera predeterminada, la revisión más actual, o HEAD, aparecerá en la vista del repositorio. Sin embargo, se podrá acceder a todas las revisiones anteriores por medio de la perspectiva SVN Repository Exploring.

Figura 11. Números de revisión del repositorio para artefactos gestionados
Números de revisión del repositorio para artefactos gestionados

Agregado de proyectos WID a Subversion

Es posible agregar proyectos al repositorio remoto a través de la vista Business Integration. Aunque el procedimiento que discutimos aquí es específico a Subversion, conceptos similares son aplicables si se usa otro sistema de control de versión (como, por ejemplo, CVS o Clearcase). Los proyectos agregados a Subversion aparecerán en la revisión HEAD del repositorio.

Para agregar su proyecto local a control de fuentes, haga lo siguiente:

  1. Desde la vista Business Integration, presione el botón derecho del mouse sobre el nombre del módulo y seleccione Team > Share Project... (Compartir proyecto...)
Figura 12. Compartir proyecto
Compartir proyecto
  1. Seleccione el tipo de repositorio (en este caso, estamos usando Subversion). Haga clic sobre Next (Siguiente).
Figura 13. Compartir proyecto: SVN
Compartir proyecto: SVN
  1. Cree o seleccione el repositorio en el que se debería gestionar el módulo.
    • Si ningún otro proyecto en su espacio de trabajo actual se gestiona por medio de Subversion, usted debe seleccionar Create a new repository location (Crear una nueva ubicación de repositorio). Ingrese la URL del repositorio y las credenciales de autenticación. En Advanced (Avanzado), asegúrese de que la casilla de verificación Enable Structure Detection (Activar detección de estructura) esté marcada y tenga la siguiente configuración:
    • Caso contrario, seleccione Use existing repository location (Usar la ubicación de repositorio existente). Haga clic sobre Next.
Figura 14. Activación de la detección de estructura
Activación de la detección de estructura
Figura 15. Uso de la ubicación existente del repositorio
Uso de la ubicación existente del repositorio
  1. Especifique la disposición y la ubicación del proyecto. Tenga en cuenta que esto es absolutamente subjetivo. No existe una forma correcta y una incorrecta de organizar sus módulos en control de fuentes. Además, es probable que usted se termine dando cuenta de que un patrón organizacional diferente, ya sea más simple o más complejo, es lo que más útil le resulta. Le recomendamos usar la siguiente configuración:
    • Seleccione Advanced Mode (Modo avanzado).
    • En el campo Name on Repository (Nombre del repositorio), asegúrese de que la opción sea Use project name (Usar el nombre del proyecto).
    • Cambie Project Repository Layout (Disposición del repositorio del proyecto) por Use single project layout (Usar disposición de proyecto único).
    • Deje la casilla de verificación denominada Use Subversion recommended layout ('trunk', 'branches' and tags) (Usar la disposición recomendada de Subversion: "tronco", "ramas" y etiquetas) sin marcar. Su configuración debería ser similar a la que se puede observar en la Figura 16.
    • Haga clic sobre Next.
Figura 16. Especificación de la ubicación
Especificación de la ubicación
  1. Ingrese una descripción opcional en el campo para comentarios. Se creará un comentario predeterminado general para usted, pero usted lo podrá cambiar por algo más específico. Deje activada la opción Launch the Commit Dialog for the shared resources (Lanzar el Diálogo de confirmación para los recursos compartidos).
Figura 17. Lanzamiento del Diálogo de confirmación para los recursos compartidos
Lanzamiento del Diálogo de confirmación para los recursos compartidos
  1. Haga clic sobre Finish (Finalizar) para confirmar el módulo al repositorio.
  2. Aparecerá un nuevo recuadro para comentarios. Éste difiere del comentario anterior debido a que se aplica a los artefactos y no al módulo. Ingrese un valor y haga clic sobre OK.
  3. Ahora, el módulo se gestiona en control de fuentes. Tenga en cuenta que ahora hay un número de revisión y una URI junto al nombre del módulo en la vista Business Integration.
Figura 18. URI nueva
URI nueva

Gestión de soluciones de integración en control de fuentes

WID introdujo las soluciones de integración en v6.2. Se trata de proyectos no implementables que le permiten relacionar lógicamente módulos que trabajan de manera conjunta en un espacio de trabajo. Esto incluye a los módulos SCA, los módulos de mediación, las bibliotecas y los proyectos Java. El diagrama de solución de integración le muestra las invocaciones y las relaciones existentes entre los módulos.

Aunque las soluciones de integración no cuentan con una lógica implementable, se las puede gestionar en control de fuentes como a cualquier otro proyecto WID. Además, existen algunas opciones en las soluciones de integración que le permiten modernizar algunas tareas de desarrollo del equipo.

Para agregar proyectos a la solución de integración, haga lo siguiente:

  1. Presione el botón derecho del mouse sobre Project References (Referencias de proyecto) y seleccione Add or Remove Project References (Agregar o eliminar referencias de proyecto).
Figura 19. Agregado o eliminación de referencias de proyecto
Agregado o eliminación de referencias de proyecto
  1. Aparecerá una ventana que incluye una lista de proyectos de espacio de trabajo. Marque o desmarque los módulos que desee gestionar en el repositorio. Haga clic sobre OK para guardar los cambios realizados.
Figura 20. Selección de proyectos
Selección de proyectos

Los módulos a los que se hace referencia en la solución de integración se pueden desproteger desde el control de fuentes de la siguiente manera:

  1. Presione el botón derecho del mouse sobre Project References y seleccione Check Out Referenced Shared Projects (Desproteger proyectos compartidos referenciados).
Figura 21. Comprobación de proyectos compartidos referenciados
Comprobación de proyectos compartidos referenciados
  1. Se desprotegen los proyectos del repositorio remoto y se sobrescriben todos los módulos que se encuentran en el espacio de trabajo.

En la mayoría de los casos, conviene desproteger los módulos referenciados directamente desde el repositorio, en vez de usar la funcionalidad de la solución de integración. Cuando use la solución de integración para desproteger el módulo, sólo se desprotegerá el tronco de la revisión de HEAD. Además, las soluciones de integración se pueden gestionar en SCM como cualquier otro módulo WID. En su parte central, las soluciones de integración son muy simples y consisten sólo de projectSet.psf y solution.graphml, que identifican las dependencias del módulo de solución.

Comprobación de proyectos desde Subversion

Usted puede desproteger módulos desde Subversion haciendo lo siguiente:

  1. Abra la perspectiva SVN Repository Exploring. De ser necesario, agregue una New Repository Location (Nueva ubicación del repositorio) al espacio de trabajo.
Figura 22. Nueva ubicación del repositorio
Nueva ubicación del repositorio
  1. Actualice la ubicación del repositorio para poder visualizar la foto más reciente en el repositorio.
Figura 23. Actualización de la ubicación del repositorio
Actualización de la ubicación del repositorio
  1. Expanda el módulo o el proyecto que desea desproteger. Si utiliza el patrón de disposición trunk/branches/tags que se discute con anterioridad, expanda la carpeta apropiada. En este caso, desprotegeremos la copia deltronco.
Figura 24. Copia del tronco
Copia del tronco
  1. Presione el botón derecho del mouse sobre la carpeta del tronco y seleccione Check Out (Desproteger) para importar el módulo en su espacio de trabajo local.
Figura 25. Comprobación
Comprobación

Borrado de proyectos y artefactos

En algunas ocasiones, es posible que un artefacto específico o todo un módulo ya no sean necesarios para un proyecto. Si se elimina un artefacto de la copia local que está en funcionamiento, éste ya no aparecerá en la revisión de HEAD del repositorio una vez que se haya confirmado el módulo al repositorio remoto. Sin embargo, el artefacto seguirá existiendo en la revisión de HEAD para que se lo pueda recuperar de ser necesario. También es posible eliminar los módulos y los artefactos directamente desde el repositorio de Subversion.

Sincronización de cambios entre la copia en funcionamiento y el repositorio

A medida que usted trabaja con módulos gestionados en control de fuentes, existe la posibilidad de que haya cambios entre la copia local y la copia remota de los módulos. Para que los artefactos en la copia de trabajo local y en el repositorio remoto siguiesen estando de acuerdo entre sí, el espacio de trabajo local debería sincronizarse con el repositorio remoto. La perspectiva Team Synchronizing (Sincronización del equipo) sincronizará la copia local y la copia remota e identificará aquellos artefactos que es necesario confirmar o actualizar. Si se modificó un artefacto y lo confirmaron varios usuarios, aparecerá una advertencia de conflicto de fusión en el asistente de sincronización.

Para sincronizar el módulo del espacio de trabajo con el repositorio remoto, haga lo siguiente:

  1. En la vista Business Integration, presione el botón derecho del mouse sobre el nombre del módulo y seleccione Team > Synchronize with Repository (Sincronizar con el repositorio).
Figura 26. Sincronización con el repositorio
Sincronización con el repositorio
  1. Una ventana de diálogo emergente aparecerá para informarle que se abrirá la perspectiva Team Synchronizing. Haga clic sobre Yes (Sí).
Figura 27. Perspectiva Team Synchronizing
Perspectiva Team Synchronizing
  1. Una lista de artefactos modificados aparecerá en la vista Synchronize (Sincronizar). Tenga en cuenta que, en este caso, existen artefactos con cambios salientes, cambios entrantes y conflictos.
Figura 28. SourceControlTest
SourceControlTest
  1. De manera predeterminada, se selecciona Incoming/Outgoing Mode (Modo entrante / saliente), lo que significa que todos los cambios y los conflictos aparecerán en la lista de sincronización. Como se puede observar a continuación, usted puede modificar el filtro para que sólo se muestren los cambios salientes, los cambios entrantes o los conflictos.
Figura 29. Cambios al filtro
Cambios al filtro

En la parte inferior de la ventana de WID, aparece la cantidad de cambios salientes, entrantes y en conflicto.

Figura 30. Cambios salientes, entrantes y en conflicto
Cambios salientes, entrantes y en conflicto
  1. En este momento, usted puede confirmar, actualizar o fusionar conflictos a través de la vista Synchronize. Presione el botón derecho del mouse sobre el módulo o el artefacto para realizar estos cambios. Vea las próximas secciones para obtener mayor información sobre la confirmación, la actualización y la fusión.

Aunque usted puede actualizar o confirmar antes de la sincronización, no se recomienda hacer esto en lo más mínimo. El asistente de sincronización le mostrará una lista completa de los cambios realizados en las versiones locales y remotas del módulo. Si usted confirma o actualiza estos cambios sin sincronización, es posible que sobrescriba el trabajo importante de otros usuarios. Evite estos problemas siempre recurriendo a la sincronización en primer lugar. Además, cuando usted trabaja con módulos que pueden llegar a sufrir revisiones frecuentes, realice sincronizaciones frecuentes para verificar que su copia de trabajo local esté actualizada.

Confirmación de los cambios al repositorio

Todos los cambios realizados a la copia de trabajo local se deben guardar en el repositorio remoto antes de que los cambios entren en efecto. Aquí es cuando la confirmación pasa a ser importante. Cuando se agrega el proyecto al repositorio, una confirmación inicial guarda todos los artefactos de la copia de trabajo local en el repositorio.

Los artefactos se deberían confirmar en el repositorio en las siguientes circunstancias:

  • Cambios a los artefactos que existen en el repositorio en la actualidad (es decir cuando un BO existente se modifica para que incluya campos de datos nuevos).
  • Adición de artefactos nuevos a un módulo que se encuentra en el repositorio en la actualidad (es decir cuando un proceso BPEL nuevo se agrega a la copia de trabajo local).
  • Eliminación de artefactos del módulo (es decir cuando se borra un archivo WSDL de la copia en funcionamiento).

Si observa un indicador "sucio" (>) en su espacio de trabajo, éste le sugiere que su copia local difiere de la copia del repositorio remoto. Es posible que usted desee sincronizar o confirmar los cambios al repositorio para garantizar que la copia remota esté de acuerdo con su copia de trabajo local.

Figura 31. El indicador denota que algo se ha modificado en el espacio de trabajo
El indicador denota que algo se ha modificado en el espacio de trabajo

Confirme los cambios al espacio de trabajo haciendo lo siguiente:

  1. Sincronice el espacio de trabajo con el repositorio remoto. Si no se encuentran cambios entre la copia de trabajo local y el repositorio remoto, no habrá nada que confirmar o actualizar.
  2. Abra la perspectiva Team Synchronizing para visualizar el resumen de sincronización.
  3. Confirme los cambios al repositorio. Usted puede confirmar todos los cambios al módulo o confirmar los artefactos individuales. Presione el botón derecho del mouse sobre el nombre del módulo o el artefacto y seleccione Commit... (Confirmar...). Aparecerá un recuadro de diálogo de confirmación.
Figura 32. Recuadro de diálogo de confirmación
Recuadro de diálogo de confirmación

De manera alternativa, usted puede hacer clic sobre el botón Commit All Outgoing Changes (Confirmar todos los cambios salientes) en la parte superior de la ventana de la vista Synchronize.

Figura 33. Botón Commit All Outgoing Changes
Botón Commit All Outgoing Changes
  1. Ingrese in comentario opcional en el recuadro de diálogo de confirmación. Haga clic sobre OK para confirmar los cambios.
Figura 34. Ingreso de un comentario de confirmación
Ingreso de un comentario de confirmación
  1. Luego de confirmar el módulo y sincronizar el espacio de trabajo, usted podrá observar que no hay más cambios abiertos para el módulo especificado.
Figura 35. No hay cambios en el módulo
No hay cambios en el módulo

Notas:

  • Realice sincronizaciones frecuentes para verificar si existen actualizaciones realizadas por otros usuarios. Esto resulta muy importante en el caso de los artefactos centrales que se pueden llegar a usar en varios módulos (como, por ejemplo, las bibliotecas con WSDLs y XSDs).
  • Si usted intenta confirmar elementos que otros usuarios han modificado, se presentará un conflicto de fusión. Aunque existen herramientas de fusión dentro de la perspectiva Team Synchronizing, estas herramientas se diseñaron para códigos tradicionales (como, por ejemplo, Java) y no funcionan bien para los artefactos WID basados en XML. Por lo tanto, los conflictos de fusión se deberían gestionar manualmente.
  • La operación de confirmación sólo se puede usar para aquellos módulos que ya se están gestionando en control de fuentes. Si usted está creando un módulo nuevo, use el recuadro de diálogo denominado Share Project... (Compartir proyecto...).
  • Si realiza algún cambio a la copia de trabajo local, tenga en cuenta que el indicador sucio (>) aparecerá junto al nombre del módulo.

Actualización de los cambios desde el repositorio en la copia de trabajo local

Ya discutimos la confirmación en la sección anterior, que es lo que usted usa al momento de guardar sus cambios locales al repositorio. Sin embargo, en algunas ocasiones, es posible que otros usuarios hayan realizado cambios a un módulo que usted haya comprobado. En este caso, su copia de trabajo local no estará sincronizada y se la deberá actualizar. Una actualización es efectivamente todo lo opuesto a una confirmación (en vez de implementar los cambios al espacio de trabajo local en el repositorio, una actualización se ocupará de todos los cambios realizados en el repositorio desde el momento en el que se comprobó el módulo). Como usted no sabe cuándo será necesario actualizar un módulo, usted debería sincronizar su copia local con el repositorio remoto con regularidad.

Actualice su copia de trabajo local de la siguiente forma:

  1. Sincronice su espacio de trabajo con el repositorio remoto. Si todo está sincronizado, no es necesario realizar actualizaciones.
  2. Vea la lista de sincronización desde la perspectiva Team Synchronizing.
  3. Actualice su espacio de trabajo local. De manera similar a lo que ocurre en la operación de confirmación, usted puede actualizar todo el módulo o los artefactos individuales. Presione el botón derecho del mouse sobre el nombre del módulo o del artefacto y haga clic sobre Update... (Actualizar...)
Figura 36. Actualización del módulo
Actualización del módulo

De igual forma, usted puede seleccionar Update All Incoming Changes (Actualizar todos los cambios entrantes) directamente desde las opciones del botón de la vista Synchronize.

Figura 37. Actualización de todos los cambios entrantes
Actualización de todos los cambios entrantes
  1. Se actualizó el espacio de trabajo.

Gestión de conflictos

Supongamos que existen dos usuarios, Joe y Tom, que están trabajando en el mismo proyecto WID. Cada uno de ellos desprotege un conjunto de módulos desde el repositorio y, sin decirle al otro cuáles son sus planes, realiza un conjunto de cambios a un proceso BPEL en un módulo ShipOrderModule. Joe realiza los cambios rápidamente y sincroniza su copia con el repositorio remoto. No se presenta ningún conflicto. Por lo tanto, confirma los cambios y cierra su espacio de trabajo. Algunas horas después, Tom decide confirmar sus cambios al proceso. Realiza la sincronización e, inmediatamente luego de esto, observa un conflicto: Joe también estuvo trabajando con el mismo conjunto de artefactos.

Tom dispone de tres opciones en este momento:

  1. Puede forzar sus cambios en el HEAD del repositorio y, por ende, sobrescribir los cambios de Joe. El artefacto de Joe seguirá existiendo en una versión anterior porque ya se lo había confirmado.
  2. Puede actualizar su copia de trabajo local para que refleje los cambios que Joe hizo en el repositorio, pero perderá todo su trabajo.
  3. Puede usar las herramientas de fusión para fusionar los cambios entre la copia de Joe y sus propios cambios

Al fusionar conflictos, usted dispone de varias opciones. En el caso del código fuente tradicional (como, por ejemplo, Java), la mejor y más fácil opción consiste en usar las herramientas de fusión para obtener ayuda al momento de realizar la integración de ambas versiones del código. Sin embargo, esto no resulta práctico en el caso de los artefactos WID, ya que están basados en XML y, generalmente, resulta muy difícil realizar la integración en formato de texto simple. Generalmente, los artefactos WID se desarrollan usando herramientas GUI. Por lo tanto, realizar una integración basada en texto es un proceso riesgoso y propenso a errores. En la actualidad, no existe ninguna forma de realizar una fusión y comparación gráfica para los artefactos WID.

Si un artefacto central se fusiona incorrectamente, el proceso necesario para corregir estos problemas puede llevar mucho tiempo y puede afectar de manera adversa a otros artefactos o módulos. Si usted obligatoriamente necesita fusionar artefactos WID debido a un conflicto, asegúrese de conservar las copias locales de ambos artefactos en caso que sea necesario volver a la versión anterior de cualquiera de ellos.

Los conflictos de fusión se ocupan de la importancia de las prácticas de sincronización frecuente. Si Tom hubiese realizado sincronizaciones frecuentes en vez de haber dejado pasar tantas horas sin hacer nada al respecto, se habría dado cuenta de que el proceso BPEL había sido modificado por Joe mucho antes de realizar modificaciones significativas al proceso. Luego de esto, podría haber discutido los cambios con Joe y quizá los podría haber integrado en su copia de trabajo local para así evitar las ambigüedades durante la confirmación.

Por lo tanto, ¿cuál es el mejor enfoque? De ser posible, trate de evitar todos los conflictos de fusión. Si sabe que varios usuarios trabajarán con un mismo módulo o una misma biblioteca, discuta esta situación con su equipo y asegúrese de que sólo una persona realice los cambios a un artefacto a la vez. Usted también puede usar las opciones Lock (Bloquear) y Unlock (Desbloquear) que figuran en el menú denominado Team (Equipo) para bloquear el acceso de lectura o escritura correspondiente a módulos o artefactos específicos.

Opción Mark as Merged (Marcar como fusionado)

La vista Synchronize incluye una opción denominada Mark as Merged que le permite anular los marcadores de conflictos marcando el artefacto como si ya se lo hubiese fusionado. Esto resulta muy útil cuando usted ha fusionado manualmente el artefacto en cuestión y no desea usar las herramientas de comparación y fusión basadas en texto para fusionar conflictos.

Para marcar el archivo como fusionado, presione el botón derecho del mouse sobre el módulo o el artefacto desde la vista Synchronize y seleccione Mark as Merged. El indicador merge-conflict (fusionar conflicto) desaparecerá y el artefacto se podrá confirmar o actualizar según lo que sea necesario.

Bloqueo y desbloqueo de recursos

Para evitar conflictos de fusión, posiblemente usted desee evitar que varios usuarios tengan acceso de escritura a un módulo o a un recurso. Usted puede hacer esto configurando bloqueos en un módulo en particular. Cuando un módulo o un artefacto están bloqueados, otros usuarios lo pueden ver pero no pueden confirmar cambios hasta que se lo desbloquee

Para bloquear un módulo, haga lo siguiente:

  1. Desproteja los módulos desde el repositorio.
  2. Desde la vista Business Integration, presione el botón derecho del mouse sobre el módulo y seleccione Team > Lock... (Bloquear...)
Figura 38. Bloqueo de módulos
Bloqueo de módulos
  1. Ingrese un comentario opcional y marque la opción Lock recursively (Bloquear recursivamente). Haga clic sobre OK.
Figura 39. Bloquear recursivamente
Bloquear recursivamente
  1. El módulo está bloqueado para que sólo usted lo pueda usar. Usted podrá observar los íconos de bloqueo de color rosa en su espacio de trabajo.
Figura 40. Módulos bloqueados
Módulos bloqueados
  1. Cuando no necesite tener acceso exclusivo, asegúrese de Unlock (Desbloquear) el módulo.
    • a. Presione el botón derecho del mouse sobre el nombre del módulo raíz y seleccione Team > Unlock (Desbloquear).
    • Marque la opción Recursively (Recursivamente) y haga clic sobre Yes (Sí). El módulo se debería desbloquear en su espacio de trabajo.
Figura 41. Desbloqueo de módulos
Desbloqueo de módulos
Figura 42. Marcado de la opción Recursively
Marcado de la opción Recursively

Notas:

  • El bloqueo sólo afecta el acceso de escritura a un artefacto. Si un usuario bloqueó un módulo, los demás usuarios todavía podrán desproteger los módulos bloqueados, pero no podrán confirmar ningún cambio hasta que se libere el bloqueo.
  • Varios usuarios pueden obtener acceso de escritura a un módulo bloqueado usando la opción Force lock (Forzar bloqueo). No se recomienda el uso de esta práctica, ya que abre la posibilidad de fusionar conflictos.
Figura 43. Opción Force lock
Opción Force lock

Trabajo con ramas

Las ramas le permiten crear una nueva línea de desarrollo desde un módulo existente. Las ramas son útiles cuando usted cuenta con un sólo flujo de código firmemente basado en el módulo del tronco. Esta sección describe cómo usted puede crear y desproteger ramas desde el repositorio.


Creación de una rama nueva desde la vista Business Integration

Usted puede crear una rama desde un módulo existente en la vista Business Integration. Para crear una rama, el módulo debe existir en Subversion en la actualidad, ya sea como un tronco o como una rama diferente, y se lo debe desproteger en su copia de trabajo local.

  1. Verifique que su espacio de trabajo local incluya el tronco o una rama para el módulo desde la que usted desea crear una rama.
  2. Presione el botón derecho del mouse sobre el nombre del módulo y seleccione Team > Branch... Aparecerá una ventana nueva.
  3. Ingrese un nombre para la rama y seleccione la opción Start working in the branch (Comenzar a trabajar en la rama). También le recomendamos ingresar un comentario, ya que éste le ofrecerá a su equipo una forma de identificar el propósito de la rama. Haga clic sobre OK.
Figura 44. Ingreso de la ubicación de la rama
Ingreso de la ubicación de la rama
  1. Se creará la rama en el repositorio remoto.
Figura 45. Rama creada en el repositorio remoto
Rama creada en el repositorio remoto

Si usted seleccionó la opción Start working in the branch, su copia de trabajo local reflejará el nombre de la rama recientemente creada.

Figura 46. Directorio de la rama nueva
Directorio de la rama nueva

Usted también puede crear ramas directamente en Subversion dentro de la vista SVN Repository Exploring.

  1. Abra la vista SVN Repository Exploring y navegue hacia el módulo deseado. En este caso, ramificaremos desde el tronco denominado HelloWorldProcess. Presione el botón derecho del mouse sobre el tronco y seleccione New > Branch...
Figura 47. Rama nueva
Rama nueva
  1. Aparecerá una ventana nueva. Ingrese un nombre de rama y un comentario opcional y haga clic sobreOK.
Figura 48. Ingreso de un nombre de rama y un comentario opcional
Ingreso de un nombre de rama y un comentario opcional
  1. La rama aparecerá en la vista SVN Repositories, pero se la debe desproteger antes de que aparezca en su copia de trabajo local.
Figura 49. Listado de ramas
Listado de ramas

Comprobación de una rama desde el repositorio

  1. Ubique el módulo y la rama dentro de la vista SVN Repositories que desea desproteger. Expanda branches para obtener una lista completa de las ramas disponibles para un módulo en particular. En el caso de este ejemplo, desprotegeremos branch03.
  2. Presione el botón derecho del mouse sobre el nombre de la rama y seleccione Check Out.
Figura 50. Comprobación de rama
Comprobación de rama
  1. Como el tronco y todas las ramas correspondientes a un módulo comparten el mismo nombre de módulo en el repositorio, es posible que observe una notificación que le informe que el módulo ya existe en la copia de trabajo local. Seleccione el nombre de módulo que sobrescribirá la copia de trabajo local y haga clic sobre OK.
Figura 51. Anulación del proyecto
Anulación del proyecto
  1. Ahora, la rama seleccionada aparece en la copia de trabajo local

Temas avanzados de Subversion

Esta sección resume algunas de las funciones avanzadas que se incluyen en Subversion. Para mayor información sobre estos temas, por favor visite los archivos de ayuda de Subversive o la documentación del servidor de Subversion.

Anulación de operaciones

Existen dos comandos de anulación disponibles en la vista Synchronize: Override and Commit (Anular y confirmar) y Override and Update (Anular y actualizar). Estos comandos anularán todos los cambios realizados en el repositorio (al momento de confirmar) o en la copia de trabajo local (al momento de actualizar) para un módulo o un artefacto determinado. Tenga cuidado cuando use los comandos de anulación porque puede sobrescribir los cambios realizados en su espacio de trabajo local o repositorio remoto de manera accidental.

Suele ser más recomendable usar los comandos estándar, Commit and Update (Confirmar y actualizar), en conjunto con Mark as Merged.

Presione el botón derecho del mouse sobre el módulo o el artefacto para acceder a los siguientes comandos de anulación.

Figura 52. Operaciones de anulación de confirmación y actualización
Operaciones de anulación de confirmación y actualización

Reversión de cambios en la copia de trabajo local

Si realiza cambios en su copia de trabajo local, pero luego decide que dichos cambios fueron accidentales o innecesarios, usted podrá descartarlos usando la opción denominada Revert (Revertir). Esta opción restaurará el artefacto al estado definido en la revisión del repositorio correspondiente.

Para revertir un módulo en su espacio de trabajo, presione el botón derecho del mouse sobre el nombre del módulo y seleccione Team > Revert... Aparecerá un menú desplegable con una lista de artefactos modificados. Elija los artefactos que desea revertir y haga clic sobre OK. Tenga en cuenta que el indicador "sucio" (>) se eliminará de dichos artefactos.

Figura 53. Reversión de los cambios realizados en la copia de trabajo local
Reversión de los cambios realizados en la copia de trabajo local

Uso de la vista History

Es posible que usted desee visualizar el historial de revisión del control de fuentes para un módulo o un artefacto en particular. La vista History ubicada en la perspectiva SVN Repository Exploring le mostrará la revisión de un artefacto. La vista History le mostrará el número de revisión, la hora de confirmación, el autor del artefacto y todos los comentarios disponibles que existan.

Visualice la historia del artefacto de la siguiente manera:

  1. Abra la perspectiva SVN Repository Exploring.
  2. Expanda el módulo y ubique el artefacto del que desea ver la historia de revisión.
  3. Presione el botón derecho del mouse sobre el artefacto y seleccioneShow History(Mostrar historial).
Figura 54. Mostrar historia
Mostrar historia
  1. Una lista de las revisiones disponibles aparecerá en la vista History. Haga clic sobre una de las revisiones para ver su historia de cambios.
Figura 55. Vista History
Vista History

Selección de una revisión específica en el repositorio

En la mayoría de los casos, usted desprotegerá sus módulos desde la revisión de HEAD del repositorio. Pero, ocasionalmente, es posible que desee desproteger una revisión en particular. La vista SVN Repositories le permite visualizar todas las revisiones en el repositorio y eliminar el tronco o las ramas en su espacio de trabajo local.

Usted puede navegar por una revisión en particular de un módulo y desprotegerla de la siguiente manera:

  1. Abra la perspectiva SVN Repository Exploring y refine la vista SVN Repositories. Busque el árbol denominado REVISIONS (REVISIONES) debajo de la ubicación del repositorio raíz.
Figura 56. Árbol de revisiones
Árbol de revisiones
  1. Presione el botón derecho del mouse sobreREVISIONSy haga clic sobre Select Revision... (Seleccionar Revisión...).
  2. Aparecerá una ventana emergente. Usted puede seleccionar una de las revisiones existentes por Date (Fecha) o Revision number (Número de revisión). Haga clic sobre Browse... (Navegar...) para seleccionar un número de revisión. Haga clic sobre OK luego de seleccionar una revisión.
Figura 57. Selección de una revisión
Selección de una revisión
  1. Para visualizar una lista de los módulos que existen en la revisión mencionada con anterioridad, expanda el árbol denominado REVISIONS hasta que pueda observar el tronco, las ramas y las etiquetas. Ahora, usted puede desproteger la revisión del módulo al igual que lo hizo con la revisión de HEAD.
Figura 58. Árbol de revisión
Árbol de revisión

Cambio de una revisión de un espacio de trabajo a otra

En la sección anterior, usted aprendió a navegar por las revisiones anteriores que existen en el repositorio y a desprotegerlas. Estas prácticas resultan muy útiles cuando usted importa un módulo en su espacio de trabajo. Pero en algunas ocasiones, es posible que usted desee desproteger una versión anterior de un módulo que ya existe en su espacio de trabajo. En estos casos, se usa la opción switching (cambio).

Cambie un módulo por una versión diferente de la siguiente manera:

  1. Abra la perspectiva Business Integration y resalte el módulo que desea cambiar.
  2. Presione el botón derecho del mouse sobre el nombre del módulo y seleccione Team > Switch... (Cambiar...).
  3. Aparecerá una ventana nueva.
    • Haga clic sobre la URL Browse... (Navegar...) y seleccione una URL para la ubicación del módulo. Seleccione el tronco o la rama apropiada.
Figura 59. Navegación
Navegación
  • Desde la sección denominada Revision (Revisión), elija una revisión por Fecha o Número de revisión. En este caso, optamos por la opción Revision number. Haga clic sobre el botón Browse... Revision y seleccione una revisión.
  • No modifique el valor predeterminado de Depth (Profundidad) y copie el valor de Working (En funcionamiento).
  • Su configuración debería ser similar a ésta. Haga clic sobre OK.
Figura 60. Navegación de la revisión
Navegación de la revisión
Figura 61. Selección de la URL y revisión de la fuente del repositorio
Selección de la URL y revisión de la fuente del repositorio
  1. La revisión seleccionada del módulo se importará en su espacio de trabajo. Tenga en cuenta que el número de revisión se modificó basándose en su selección.
Figura 62. Número de revisión
Número de revisión

Tenga en cuenta que Select Revision (Seleccionar revisión) y Switch (Cambiar) son similares porque ambos le permiten desproteger una revisión anterior en el repositorio. Sin embargo, la opción Select Revision sólo está disponible en la perspectiva SVN Repository Exploring, mientras que el comando Switch está disponible en la perspectiva Business Integration por medio del menú Team. Si el módulo no existe en su copia de trabajo local, usted debería usar Select Revision. Por otra parte, usted debería usar Switch para el caso de los módulos que ya existen en su copia de trabajo local.

Reemplazo de la copia de trabajo local con una versión desde SCM

De manera similar que con Switching, usted puede usar las funciones de Replace With (Remplazar con) para cambiar entre las ramas o las revisiones disponibles que existen en el repositorio. Usar este método en vez de Switching no ofrece ninguna ventaja. Simplemente, es otra forma de hacer lo mismo.

  1. Desde la vista Business Integration, presione el botón derecho del mouse sobre el nombre del módulo y seleccione Replace With.
  2. Seleccione la opción apropiada a continuación y pase por todos los menú de contexto correspondientes como si estuviese usandoSwitching. Si selecciona Latest from Repository (Última versión del repositorio), la última versión del módulo en el repositorio remplazará la copia de trabajo local.
Figura 63. Uso de Replace With para cambiar ramas
Uso de Replace With para cambiar ramas

Cuando remplace un módulo, sea cuidadoso porque todos los artefactos no guardados o no confirmados se eliminarán del espacio de trabajo local. Por lo tanto, usted debería realizar la sincronización antes de remplazar la copia de trabajo local.


Control de versión del módulo en WID

El control de versión del módulo es algo nuevo en WID v6.2 y le permite hacer varias cosas. En primer lugar, usted puede gestionar módulos de manera lógica basándose en un conjunto de características definido y puede implementar una versión específica con gran facilidad para cumplir con un propósito determinado si así lo desea. Y lo que quizá sea todavía más importante, usted puede instalar diversas versiones en el mismo objetivo de tiempo de ejecución de manera simultánea. El control de versión del módulo sólo se puede realizar por medio del editor de dependencia en WID.

Para crear un archivo EAR que conozca la versión, se debe implementar un módulo con control de versión usando serviceDeploy. Los módulos exportados como archivos EAR desde WID se generarán e instalarán adecuadamente, pero no conocerán la versión. De igual forma, las aplicaciones agregadas al UTE por medio de Add/Remove projects (Agregar / Eliminar proyectos) tampoco conocen la versión.

IBM Supplied Version Scheme usa un sistema numérico de tres dígitos para indicar la versión en el siguiente formato: <MAJOR>.<MINOR>.<SERVICE>. Por ejemplo, una versión anterior de un módulo puede tener un número de versión 1.0.2. Los valores correspondientes a MAJOR (MAYOR), MINOR (MENOR) y SERVICE (SERVICIO) son puramente subjetivos y el usuario los debe modificar. El desarrollador debe decidir cuándo incrementar cada categoría, ya que WID no lleva ningún registro de las versiones incrementales del módulo. Además, se recomienda llevar un ordenamiento numérico sucesivo, pero no se debe forzar el cumplimiento de esta recomendación. Esto quiere decir que no existe nada en WID que evite que usted cree una versión (por ejemplo, 1.0.1) que incluya contenidos más nuevos que los que figuran en la versión 2.1.0. Todos los proyectos y las bibliotecas dependientes de un módulo con control de versión no tienen que tener control de versión como algo obligatorio. Tampoco tienen que usar el mismo número de versión que el del módulo al que hacen referencia. Las propiedades de control de versión del módulo se pueden configurar desde la configuración de dependencia del módulo.

Figura 64. Número y configuración de la versión del módulo
Número y configuración de la versión del módulo

Tenga en cuenta que, cuando se controla la versión de los módulos, sólo se modifica el nombre del módulo. Esto le permitirá instalar dos o más copias de la misma aplicación en un tiempo de ejecución de WPS. Sin embargo, ninguna plantilla de procesos BPEL o de tareas humanas se modificará y, por lo tanto, esto puede evitar que usted instale diversas versiones de la aplicación en el mismo objetivo de tiempo de ejecución. Las plantillas de procesos o tareas deben ser únicas para un contenedor de tarea o proceso determinado. Si intenta instalar simultáneamente varias versiones de módulos en el mismo objetivo de tiempo de ejecución sin controlar las versiones de la tarea humana o el proceso BPEL, la aplicación no se instalará correctamente. Para solucionar este problema, usted debe controlar la versión de su proceso BPEL cuando se realice el diseño o refactorear el nombre de la plantilla del proceso BPEL.

El control de versión del módulo está desactivado de manera predeterminada, pero se puede activar para cada módulo por medio de las siguientes preferencias:Window > Preferences > Business Integration > Module And Library Versions (Versiones de biblioteca y módulo).

¿Cómo se genera un módulo con control de versión?

Existen dos artefactos WID que resultan relevantes para el control de versión del módulo:

  • sca.module: El nombre del módulo SCA se define en este archivo. Si se usa el control de versión del módulo, el nombre del módulo se modificará durante la implementación (de forma tal que el número de versión se adjuntará a la cadena del nombre del módulo durante la implementación. Tenga en cuenta que esto sólo funciona para las aplicaciones implementadas por medio de serviceDeploy y no para aquellas implementadas por medio de Add/Remove projects.
  • sca.module.attributes: Sólo se crea cuando el control de versión del módulo está activado. Aquí se configura el número de módulo especificado por el usuario. A modo de recordatorio, entienda que el número de versión sólo se aplica cuando el módulo se implementa por medio de serviceDeploy.

El módulo se debe implementar por medio de serviceDeploy para que las propiedades del control de versión del módulo entren en efecto. Durante la implementación, el número de versión definido en sca.module.attributes se usará para construir el nuevo nombre del módulo.

El módulo con control de versión se identifica usando el siguiente patrón:

ModuleName_vX_Y_ZApp.ear

, donde X, Y y Z son los números de revisión mayor, menor y de servicio.

Por ejemplo, asumamos que usted tiene un módulo, HelloWorldProcess, en su espacio de trabajo WID. Usted activa el control de versión e identifica el módulo como la versión 1.0.1. Si el módulo se implementa por medio de WID, el EAR resultante se llamará HelloWorldProcessApp.ear. Sin embargo, si el control de versión está activado, el nombre del módulo pasará a ser HelloWorldProcess_v1_0_1App.ear por medio de serviceDeploy.

¿Cómo el control de versión del módulo se relaciona con la gestión de control de fuentes?

El control de versión del módulo WID está muy relacionado con cómo los módulos se gestionan en control de fuentes. Lo ideal es que todas las versiones de un módulo se deberían gestionar en control de fuentes para que se las pueda recuperar, modificar o instalar con facilidad en el tiempo de ejecución de WPS.

Los módulos con control de versión deberían almacenarse en el mismo árbol de directorio que el módulo principal. Le recomendamos que la versión inicial del módulo (por ejemplo, 1.0.0) se almacene en el tronco, mientras que las versiones posteriores del módulo se deberían almacenar en las ramas de dicho tronco.

De manera alternativa, usted puede conservar la última o más estable versión en el tronco y todas las versiones anteriores del módulo en ramas. En este caso, no existe una respuesta correcta y otra incorrecta siempre que el patrón sea consistente. Para favorecer la continuidad, le recomendamos que la primera versión se almacene en el tronco y que todas las versiones posteriores se almacenen en las ramas. Si usted necesita realizar un cambio central a un artefacto que afectará a todas las versiones, se lo podrá implementar en el tronco y delegar en las ramas cuando sea necesario. Tenga en cuenta que los troncos y las ramas son nativos de Subversions. Es posible que otros productos SCM usen convenciones diferentes.


Anexo 1: Lista de artefactos WID gestionados en control de fuentes

Mapas de objeto de negocios:

  • .map, .xsl, .xsl.smap

Mapas de interfaz:

  • .ifm, <IFMapName>_ifm.mon

Artefactos WPS generales:

  • .component, .module, .modulex, .import, .export, .mon, ibm-deploy.scaj2ee

Metadatos de Eclipse:

  • carpeta .settings, MANIFEST.MF, .classpath, .project

Interfaces:

  • .wsdl

Tipos de datos (objetos de negocios):

  • .xsd

Mediaciones:

  • .medflow, .mfc, .mfcex

Procesos de negocios:

  • .bpel, .bpelex, <ProcName>Artifacts.wsdl, <ProcName>_bpel.mon

Máquinas de estado de negocios: (Tenga en cuenta que el archivo .bpel subyacente para la máquina de estado ahora se genera durante la instalación de la aplicación y, por lo tanto, no se lo gestiona en SCM.)

  • .sacl, .saclex, <BSMName>_sacl.mon

Tareas humanas:

  • .tel, .itel (sólo tarea en línea), <HTName>_tel.mon

Reglas de negocios:

  • .brg, .brgt, <BRGName>_brg.mon, .ruleset

Selectores:

  • .sel, .selt, <SelName>_sel.mon

Relaciones:

  • .rel, .rol

Solución de integración de módulos:

  • .project
  • projectSet.psf
  • solution.graphml

Anexo 2: Instalación del complemento cliente de Subversive

Para conectarse a un servidor de Subversion dentro de WID o Eclipse, usted debe instalar el complemento cliente adecuado. Como ya hemos visto en este documento, hay dos complementos disponibles que funcionan con Subversion: Subclipse y Subversive. Para el caso de los ejemplos que se discuten en este documento, usamos Subversive (aunque también se puede usar Subclipse).

Para instalar el complemento cliente de Subversive, por favor visite la guía de instalación de Subversive: http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php

Le recomendamos que evite instalar Subclipse y Subversive en la misma instancia WID, ya que ambos complementos tienen sistemas de menú similares y una similar perspectiva SVN Repository Exploring. Por lo tanto, suele ser difícil de distinguir un complemento del otro.

Instalación y configuración de un servidor de Subversion

Para usar Subversion, usted también necesitará un servidor de tiempo de ejecución de Subversion. En la mayoría de los casos, un sistema administrador se encargará de gestionarlo. Como este documento se concentra estrictamente en la programación del cliente WID, la configuración del tiempo de ejecución de Subversion escapa al alcance de este documento. Nosotros usamos la distribución Collabnet para este documento.

Para mayor información sobre la configuración de Subversion, por favor consulte éste excelente recurso gratuito: Control de versión con Subversion.

Sin importar el complemento cliente o el servidor de Subversion que usted use, asegúrese de que tanto el cliente como el servidor tengan el mismo nivel de versión.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web , WebSphere
ArticleID=475795
ArticleTitle=Desarrollo del equipo y gestión de artefactos en WebSphere Integration Developer v6.2
publish-date=08052011