Integración Continua - Parte 2 - Subversion

Subversion

Subversion, como habíamos revisado en la entrada anterior (Integración Continua - Parte 1), es un sistema de control de versiones desarrollado por Apache. Pero vamos al grano antes de que nos ataque el "WannaCry".

Toda la información referente la pueden encontrar en su sitio web:

https://subversion.apache.org/

Descarga

Al ser código abierto, pueden descargar el proyecto directamente del sitio y compilarlo para armar su propia versión. Yo decidí descargar el producto de VisualSVN para mayor agilidad. Eso lo pueden hacer aquí:

https://www.visualsvn.com/downloads/

Instalación

La instalación en Windows es muy simple. Únicamente descarguen el archivo MSI y se ejecuta. Verán la siguiente secuencia de pantallas:

Bienvenida

Lo que se va a instalar es el servidor de subversion de Apache y por supuesto un Apache HTTP server que es donde se desplegará la aplicación:

Licencia

Términos de licencia del producto que deberán ser aceptados:

Componentes

Selección de componentes a instalar. Elegimos que se instale tanto el servidor como las herramientas de administración del sistema de control de versiones:

Configuración del servidor

Aquí indicamos las rutas locales del servidor donde se almacenarán tanto los repositorios como los respaldos. Algo muy importante es elegir un puerto que tengamos disponible. Por default es el puerto seguro 443, se puede elegir libremente el que nosotros queramos:

Confirmación de la instalación

Finalmente vamos a confirmar la instalación.

Finalización de la instalación

El instalador nos va a mostrar cuando finalice. Aquí podemos terminar; o bien, ir al administrador del servidor.

Administración del servidor

En esta herramienta administrativa es donde vamos a poder gestionar todas las actividades relacionadas con el servidor: iniciarlo, detenerlo, crear usuarios, crear repositorios, crear grupos, entre otras.

Creación de los usuarios

Para poder utilizar nuestro repositorio, debemos crear al menos un usuario. Posteriormente vamos a poder crear grupos. Para el ejemplo de ahora es suficiente con un usuario:

Una vez creado el usuario, vamos a poder observarlo en la sección correspondiente de nuestro servidor.

Creación del repositorio

Finalmente, vamos a crear nuestro repositorio.

Elegimos el tipo de repositorio. Esto depende del tipo de sistema de archivos que estemos usando. Para el caso del ejemplo he creado un repositorio normal (regular).

Colocamos el nombre del repositorio:

Elegimos la estructura inicial del repositorio. Esto creará una serie de carpetas como trunk, branches y tags. Esto nos será de ayuda para cuando estemos revisando el ciclo de vida de los despliegues del código.

Finalmente colocamos los permisos de acceso a nuestro repositorio. Podemos otorgar o negar todos los permisos de acceso; o bien, personalizarlos de acuerdo a nuestras necesidades. En mi caso particular, le di todos los permisos a todos los usuarios.

En la última pantalla veremos la confirmación de que nuestro repositorio se ha creado correctamente, así como un resumen del mismo.

Si volvemos al administrador del servidor, debemos poder confirmar que nuestro repositorio está listo para ser usado.

Confirmación de acceso

Una vez que hemos completado todos los pasos anteriores, abrimos un navegador y entramos a la URL solicitada. En el caso de nuestro ejemplo debemos entrar por HTTPS, pues habilitamos el acceso seguro. El propio navegador nos va a hacer una advertencia de seguridad de confianza en el sitio (debemos aceptar el riesgo) y nos va a solicitar un usuario y contraseña válidos del repositorio. Lo que veremos a continuación es el contenido del repositorio en el navegador:

Igualmente podemos confirmar que en nuestro sistema de archivos (servidor) ya se encuentra el repositorio creado:

Cliente de SVN

Una vez que tengan el servidor de SVN listo, se pueden crear usuarios (por ejemplo para el equipo de desarrollo). Estos usuarios van a interactuar con el servidor para descargar el código (check out); o bien, para incluir sus cambios (check in).

Al trabajar en equipos de más de una persona, existen algunas acciones que deben realizarse de manera colaborativa. Por ejemplo si dos personas se encuentran trabajando sobre el mismo componente, es posible que necesiten realizar un merge para poder depositar el código en el repositorio.

Para que estos usuarios puedan realizar las interacciones con el repositorio, es necesario que cuenten con un cliente de SVN.

Tortoise SVN

Es quizá uno de los más conocidos, lo ocuparemos para dar agilidad al concepto. Una vez instalado podremos tener disponibles los comandos directo en nuestro explorador de archivos como un menú contextual (click derecho).

Check out

Para realizar el check out del repositorio (descargarlo), vamos a ocupar la URL del repositorio y nuestras credenciales para acceder al mismo, así como un directorio en donde vamos a almacenar la copia local (working copy). Antes de realizar el checkout, el directorio de la copia local se encuentra vacío:

Realizamos el checkout:

Y entonces el directorio de nuestra copia local, se va a poblar con los artefactos del repositorio:

Cambios en la copia local (working copy)

Ahora sí, podemos comenzar a hacer los cambios que necesitemos en nuestro código: generar artefactos, eliminar artefactos, modificar artefactos. Para nuestro ejemplo únicamente generamos un archivo de texto en nuestra copia local:

Check in

Finalmente, una vez que terminamos el desarrollo o los cambios que necesitemos, vamos a subir (check in) los artefactos al repositorio.

Seleccionan los elementos que quieren subir y después el comando commit:

Seleccionan la rama a la que van a subir los artefactos. Aquí es posible (recomendable) colocar algún comentario para poder tener trazabilidad de los cambios (de cualquier manera se va a tener esa trazabilidad, si la cagamos no habrá poder humano que nos pueda salvar y vamos a tener que pagar las tortas de tamal al día siguiente):

Finalmente, podremos ver un resumen de los cambios realizados en el repositorio (en este punto ya no nos podemos arrepentir de lo que subimos).

Confirmación de los cambios en el repositorio

Para poder asegurarnos que nuestros cambios están ahí, podemos ir al repositorio a través de nuestro navegador y ahí deberán estar los artefactos que acabamos de subir:

Conclusiones y Siguientes pasos

Es posible (porque ya los veo criticando) usar cualquier repositorio de código. Lo que pretendo mostrar es el concepto del mismo (trabajo colaborativo, administración del código, control de versiones, respaldos, ramas, etcétera), no si un repositorio es mejor que otro, no vamos a entrar en esa discusión.

Pueden bien usar Git + Bitbucket si las condiciones de sus proyectos lo permiten, ameritan y gustan de estar más a la moda. Particularmente a mi me gusta mucho esa combinación. Si tienen algún comentario respecto a esto y su intención es iniciar una discusión (con todos los beneficios que pudiera tener eso), pueden entrarle al ruedo en Los Engreídos del Software.

Como lo revisamos en la entrada anterior (Integración Continua - Parte 1), los siguientes pasos son:

• Administración de proyectos y builds con Apache Maven
• Administración de repositorios de Maven con Apache Archiva
• Servidor de Integración Continua con Apache Hudson

Estos componentes los veremos en las siguientes entradas del blog.

Integración Continua - Parte 1

Integración Continua

Vamos sin rodeos. Hace un buen rato que no escribía una entrada en el blog. Así que vamos al grano. En la siguiente serie de entradas, me ocuparé de un tema muy interesante (al menos para mi): Integración Continua.

Les parecerá un tópico normal, seguramente en los últimos años/meses han escuchado mucho de esto. Pero, ¿en realidad han tenido alguna relación directa con un algún ambiente de integración continua? Hasta hace algunos meses, yo no. Quizá en alguno que otro experimento, tras bambalinas, pero no de manera directa.

Oracle. "Es el producto que yo manejo", se diría por ahí (1). Así que exploraremos algunos conceptos básicos y una serie de herramientas que podrían ayudar a desplegar un entorno de integración continua, para Oracle Fusion Middleware.

Servicios y Microservicios: SOA

Como ésta entrada no está dedicada a discutir si los microservicios reemplazan a SOA, ni tampoco a determinar si SOA es el padre de los microservicios, vamos a centrarnos en la forma en que se construye (típicamente) una aplicación.

En la mayoría de los proyectos en que hemos participado existen pequeños grupos de personas, que en conjunto hacen un equipo de trabajo completo. Cada uno de esos grupos realiza una tarea definida, trabaja en el ámbito en el que está especializado: administración del proyecto, desarrollo (cualquier tecnología), pruebas, infraestructura, soporte y demás. Así cada equipo colabora con una pequeña parte del proyecto, para al final construir una aplicación integral en la que conviven todas las piezas. ¿Les suena esto en donde cada quien hace un pedazo de todo el trabajo? ¿Servicios? ¿SOA? Acordamos no hablar de eso, sigamos.

Agilidad

Otro concepto que hemos escuchado mucho es el de la agilidad. Aquí es donde comienza a tener importancia la metodología que utilizamos para implementar un proyecto de software. Lo sentimos por aquellos que se identifican con la metodología en cascada, pero desde mi punto de vista eso ya quedó atrás. Muchos años atrás.

Las metodologías ágiles nos ayudan a implementar estrategias iterativas que permiten descubrir errores en etapas más tempranas del proyecto. Por lo tanto, podemos corregirlos de manera anticipada y durante cada iteración, también podemos incluir funcionalidad nueva que haga que el desarrollo sea incremental.

Una parte fundamental de ser ágil es: el negocio cambia constantemente. ¿Qué tan constantemente? Tal vez les suene que a la mitad de los proyectos o, incluso, ya prácticamente cuando se encuentran desplegando sus componentes, al usuario se le ocurre cambiar alguna regla o definición de negocio. O varias.

Entre más pequeñas sean las piezas que construimos y más rápido las pongamos en pruebas, validación y operación, la vida se vuelve mucho más simple. Podemos agregar, modificar o eliminar funcionalidad de acuerdo a las nuevas necesidades. Una vez por año, una vez por mes. Quizá una vez por día. Al usuario eso no le interesa, su interés se centra en qué tan rápido ve funcionando el producto que solicitó.

¿Se imaginan generar un JAR, WAR, EAR, EXE, o cualquier cosa que ustedes generen, una vez al día? ¿Desplegarlo, probarlo, validarlo, monitorearlo y dar soporte a la producción? Ahora imaginen eso, multiplicado por las decenas o cientos de componentes que generaron. Quizá justo en este momento quieran darle una oportunidad al concepto de integración continua.

Concepto

El concepto de libro es el siguiente: la integración continua es una práctica de la ingeniería de software enfocada en mejorar la calidad y reducir el tiempo de entrega de una pieza de software. Esto se logra aplicando pequeños pero frecuentes esfuerzos en el control de la calidad. Uno de los fines de la integración continua es ayudar a las organizaciones a automatizar despliegues y pruebas de los componentes desarrollados.

Prácticas clave

Para lograr establecer un entorno de integración continua, es necesario llevar a cabo una serie de prácticas clave:

1. Un control de versiones que es utilizado para dar seguimiento a los cambios.
2. Los desarrolladores realizan commit hacia el control de versiones todos los días.
3. El producto (build) es realizado después de cada commit.
4. El build debe ser automático.
5. El despliegue debería ser automático hacia los ambientes de desarrollo, pruebas y producción.
6. Las pruebas del producto deberían estar automatizadas.
7. Los resultados del build deben ser públicos, de esta manera cualquier persona podrá enterarse cuando sus cambios son incorrectos e impiden que el build se complete de manera satisfactoria.
8. Los entregables deben estar disponibles para desarrolladores, equipo de pruebas y cualquier otro stakeholder del proyecto.

Soporte de integración continua, Oracle

Como mencionamos en un principio, esta serie de entradas se centrará en tecnología Oracle. ¿Cómo Oracle soporta un entorno de integración continua?

1. Oracle JDeveloper se integra con los sistemas de control de versiones más comunes.
2. Capacidad de realizar el build desde la línea de comandos usando Maven, así el build puede ser automatizado.
3. Capacidad de crear nuevos proyectos usando los arquetipos de Maven.
4. Capacidad de descargar las dependencias de los repositorios de Maven.
5. Capacidad de parametrizar los scripts, así los builds pueden ser desplegados hacia varios entornos (desarrollo, pruebas, producción).
6. Capacidad de incluir pruebas de los proyectos en el ciclo de vida de Maven.
7. Capacidad de poblar el repositorio de Maven con dependencias de Oracle desde un directorio de instalación de productos de Oracle (Oracle Home).
8. Capacidad de gestión de los builds con servidores de integración continua (como Hudson).

Componentes de integración continua

En el mercado hay disponibles un buen número de opciones tecnológicas para la implementación de un entorno de integración continua. Algunos de estos componentes pueden ser de uso gratuito (open source) y algunos otros pueden ser productos comerciales. Para nuestro ejemplo vamos a usar lo siguiente:

1. Apache Subversion como sistema de control de versiones.
2. Apache Maven para creación y automatización de los builds.
3. Apache Archiva como administrador del repositorio de Maven.
4. Apache Hudson como servidor de integración continua.

Apache Subversion

Un control de versiones funciona como repositorio de artefactos de código. A este repositorio tienen acceso los desarrolladores usando un cliente de Subversion. Los equipos de desarrollo pueden copiar artefactos desde y hacia el repositorio. El control de versiones lleva un registro de quién y qué ha cambiado en los artefactos de código (aquel que rompa el build, deberá pagar el desayuno del día siguiente).

• Se integra de manera natural con JDeveloper.
• Soporta distintas opciones de autenticación, incluyendo la autenticación vía un certificado.
• Funciona bien en entornos de red.
• Para proyectos de Oracle SOA Suite, provee de commit atómico, que permite actualizar varios archivos como parte de un mismo commit.

Apache Maven

Maven es un sistema de administración de proyectos y builds. Tiene capacidades de administración de proyectos (no piensen en MS Project, por favor) en términos de:

• Nombrado y versionamiento.
• Dependencias.
• Ubicación del código.
• Ubicación de los builds.
• Plantillas de proyectos.
• Proceso de liberación.

También tiene capacidades de administración de builds en términos de:

• Cómo ejecutar el build.
• Pasos a realizar en cada fase.
• Parametrización del build.
• Extensión del framework.

Una instalación típica de Maven consiste de la instalación de Maven en la máquina de cada desarrollador, un repositorio de Maven compartido al interior de la organización y múltiples repositorios públicos de Maven donde están almacenadas las dependencias. Estos repositorios públicos almacenan librerías que pudieran ser usadas como dependencias en el desarrollo de nuestros proyectos.

Apache Archiva

En ocasiones nos viene a la mente ¿por qué usar un administración de repositorios de Maven? La respuesta a esto es que algunas organizaciones encuentran útil tener un repositorio interno de Maven. Las razones pudieran ser las siguientes:

• Actuar como intermediario o caché de repositorios externos. Así el repositorio central (interno) descargaría las dependencias una única vez y las almacenaría en caché para que los desarrolladores las puedan utilizar.
• Para almacenar los artefactos que se desarrollen al interior de la organización y que estos puedan ser compartidos con otros equipos de desarrollo o proyectos.

Apache Hudson

Hudson es un servidor de integración continua muy utilizado y nos ayudará a automatizar el proceso de creación de builds. Los pasos que se contemplan en la automatización pueden ser los siguientes:

• Iniciar el proceso de build siempre que un desarrollador realice un commit hacia el sistema de control de versiones.
• Descargar el código del sistema de control de versiones.
• Compilar el código.
• Ejecutar pruebas unitarias.
• Empaquetar el código en un archivo con formato de despliegue (JAR, por ejemplo).
• Desplegar el archivo hacia un ambiente de ejecución.
• Ejecutar pruebas de integración.
• Enviar notificaciones ante fallas en el proceso.

Resumen

En la primer entrada de esta serie, hemos explorado algunos conceptos, beneficios y necesidades que se cubren al implementar un entorno de integración continua al interior de una organización.

Se ha dado un breve resumen de lo que cubriremos en las siguientes entradas del blog, para mostrar cómo un entorno de integración continua nos proporciona capacidades de automatización de builds, administración del código, documentación, automatización de pruebas, despliegue hacia distintos entornos (desarrollo, pruebas, producción), entre otras.

Vamos a usar tecnología de Apache para: control de versiones (Subversion), administración de proyectos y builds (Maven), administración de repositorios de Maven (Archiva) y servidor de integración continua (Hudson).

Citas

(1) Gerardo "Ellera" Nieves

Oracle Developer Cloud Service Demo

Oracle Developer Cloud Service

Para empezar, vamos a explicar de qué se trata esta nube. Oracle Developer Cloud Service es un ambiente de hosting en la nube. ¿Qué es lo que se sube a esa nube? Proyectos de desarrollo de software.

En esta ocasión, vamos a tomar el rol de ingeniero de software. Una de nuestras tareas va a ser crear un ambiente en la nube de Oracle, para el desarrollo de proyectos Java. Debemos probar la creación de proyectos y administración de incidentes en la nube, así como probar las características de administración del ambiente.

En esta nube podemos tener el rol de administrador o desarrollador. Casi todas las tareas que vamos a cubrir pueden ser realizadas por ambos roles. Sin embargo, algunas de ellas sólo pueden ser ejecutadas por administradores.

Entre otras cosas, básicamente lo que ofrece esta nube es lo siguiente (de acuerdo al fabricante):

1.      Administración de issues

2.      Desarrollo ágil

3.      Repositorio de código fuente

4.      Build del software

5.      Revisión de código

6.      Colaboración vía Wiki

7.      Despliegue de servicios

Sin más, vamos a pasar al uso de la nube y de sus características. Para esto, tendremos que ingresar a través de la consola de Oracle Developer Cloud Service, con las credenciales que nos han proporcionado para el acceso.

Crear un proyecto nuevo

Para crear un nuevo proyecto basta con presionar el siguiente botón:

En la sección de detalles del proyecto, debemos dar un nombre y descripción del proyecto. A continuación, vamos a seleccionar el tipo de seguridad. Los proyectos privados son accesibles únicamente para miembros. En los proyectos compartidos, tanto el código, la wiki, los issues y builds del proyecto están disponibles para cualquier miembro del dominio de identidades de la organización.

Se pueden crear proyectos vacíos, o bien, elegir una plantilla. Si creamos un proyecto a partir de una plantilla, estaremos copiando todos los artefactos: repositorios GIT, configuración de builds y despliegue, páginas de la wiki, etcétera.

En nuestro ejemplo, lo haremos a través de una plantilla:

Por default, en las propiedades del proyecto podemos elegir un estilo de la wiki (Textile, Confluence o Markdown). Todas las wikis del proyecto usarán este estilo. Nosotros elegimos Textile.

Al seleccionar el repositorio inicial, debemos especificar su configuración. Aquí elegimos la opción de inicializar el repositorio con un archivo README.

Si se crea el proyecto a partir de una plantilla, tendremos que especificar algunas otras propiedades.

Al finalizar todo esto, presionaremos el botón Finish:

A continuación, veremos una página que muestra el progreso de la creación de nuestro proyecto. Esto tomará algunos instantes en finalizar:

Una vez que el proyecto es completamente aprovisionado, el sistema nos llevará a la página inicial. Esto nos mostrará los tabs que se muestran en la siguiente imagen. El tab de administración se mostrará únicamente si somos dueños del proyecto:

En esta pantalla podemos explorar algunas de las opciones, podemos esconder el panel de la izquierda para dar una mejor visibilidad del proyecto. También podemos ver el feed en el panel central, volver al menú inicial de Oracle Developer Cloud Service, explorar las características de los repositorios de Maven y Git, gráficas y estadísticas del proyecto, entre otras cosas.

Agregar usuarios al proyecto

Cuando iniciamos un proyecto, uno de los primeros pasos es agrega usuarios al proyecto. Para esto es necesario hacer click en el tab Team del lado derecho. Después debemos elegir New Member:

Aquí podemos agregar un usuario como miembro o como dueño del proyecto. De igual forma, si queremos agregar más de uno, debemos seleccionar la opción de usuarios múltiples. Lo anterior nos permitirá agregar más de un usuario al mismo tiempo:

Nota importante: los usuarios del proyecto deben pertenecer a la organización para poder ser asignados. De lo contrario recibiremos un error como este:

Administración del código con un repositorio Git

Oracle Developer Cloud Service ya provee un repositorio Git para la administración del código. Es posible utilizar un cliente de Git para interactuar con el repositorio. La integración de Git se puede hacer directamente con el IDE (OEPE, Oracle JDeveloper, NetBeans).

Del lado derecho de la página principal del proyecto, podemos encontrar los repositorios del proyecto:

Creación de issues

Ésta nube de Oracle tiene incluído un sistema de administración de issues basado en nube, para el equipo de desarrollo. Es posible definir issues y asignarlos a algún miembro del equipo. Por ejemplo, podemos crear issues para:

1.      Sugerir mejoras

2.      Especificar tareas

3.      Reportar defectos

4.      Definir nueva funcionalidad

5.      Asociar transacciones de código con issues

Para acceder al sistema de administración de issues, debemos elegir ésta opción en el panel del lado izquierdo:

Para crear un issue, es necesario presionar el siguiente botón del lado derecho de la pantalla:

Debemos llenar algunos datos relacionados con el issue, como se muestra a continuación. Aquí podemos catalogar el issue como defecto, tarea o característica. Para este ejemplo elegimos tarea:

Una vez que presionamos el botón de crear issue, nos aparecerá una breve confirmación en la parte superior de la pantalla. Esto nos indica que el issue ha sido creado.

El siguiente paso es asignar un propietario del issue. En este caso me lo asigné a mí mismo. También agregué un comentario que describe qué es lo que hay que hacer para esa tarea.

Una vez que presionamos el botón de agregar, el comentario estará guardado:

Finalmente presionamos guardar y el issue estará creado.

En la página principal de administración de issues, tendremos lo siguiente:

Desarrollo ágil

El tab agile nos permite organizar y calendarizar issues en sprints y supervisar el progreso.

Para esto, tenemos que dar un click en el tab de agile y después crear un nuevo tablero:

Colocamos los siguientes datos y presionamos el botón para crear el tablero:

Esto nos devolverá a un backlog del proyecto. En este backlog tenemos una única tarea creada, la del issue que generamos con anterioridad. Para poder trabajar con el backlog, debemos crear un sprint. Esto lo hacemos dando click en el botón para crear el sprint. Aquí simplemente colocamos el nombre del sprint:

Una vez que creamos el sprint, es necesario mover los issues del backlog hacia este nuevo sprint. Para esto, damos un click derecho sobre la tarea y esto nos dará algunas opciones. En el caso de nuestro ejemplo, elegimos mover la tarea hacia el sprint que acabamos de crear:

Después de realizar esto, tendremos la tarea asociada a nuestro sprint:

Para iniciar nuestro sprint, debemos presionar el botón que está del lado derecho de la pantalla. Esto nos dará opción de definir las fechas de inicio y fin del sprint. Hay que considerar que cuando usamos una metodología ágil, los sprints típicamente son de un par de semanas de duración, por eso el sistema nos indica las fechas de inicio y finalización del sprint, por default.

Al verificar en el tab de sprints activos, podemos ver que el que acabamos de crear ya se encuentra en este estado y el sistema automáticamente los organiza en columnas, como se muestra a continuación:

Revisión del código

Una de las bondades de esta nube, es que nos permite tener absoluto control de los issues a través de la integración del repositorio de Git.

Utilizando las pestañas de Merge Requests y Code, es posible gestionar el ciclo de vida de los issues, así como de realizar un monitoreo del estado de cada uno. Entre otras opciones, podemos realizar lo siguiente:

1.      Copia de un branch hacia uno nuevo, que es donde atenderemos las solicitudes de cambios.

2.      Asociación de los issues abiertos a ese nuevo branch de código.

3.      Modificación del código para resolver el issue o la solicitud de cambio.

4.      Merge de los cambios del branch de trabajo hacia el branch principal del código.

5.      Commit de los cambios.

6.      Adicional se pueden aceptar o rechazar los cambios de acuerdo a la revisión del código.

Al realizar el commit de los cambios, tenemos la opción de cambiar de estatus el issue asociado al repositorio de código. En nuestro caso, al confirmar los cambios en el repositorio principal, podemos observar que el issue que teníamos abierto, ha sido marcado como resuelto.

El último paso es cerrar o terminar el sprint. Como era un único issue el que teníamos asociado al sprint, ahora procederemos a cerrarlo. Esto lo haremos presionando el botón de completar sprint. Nos saldrá una ventana de confirmación, donde aceptaremos la acción:

Lo que veremos a continuación es una pantalla donde nos da algunas estadísticas del estatus del sprint. Verán algo como lo siguiente:

Si observamos la página principal del proyecto, veremos que en el feed se ven reflejadas todas las actividades que hemos realizado hasta el momento:

Uso de la Wiki

Uno de los aspectos interesantes de esta nube es la integración de una Wiki lista para usarse. Podemos usar esta Wiki para crear documentación y colaborar con algunos otros miembros del equipo.

Para acceder a la Wiki, elegimos la opción en los tabs del lado izquierdo de la pantalla. Inicialmente no tenemos Wiki para este proyecto, por lo que veremos una pantalla como la siguiente:

Algo que me pareció muy interesante de esta funcionalidad, es que es un tanto inteligente. Cuando generé la primera página de la Wiki, puse dentro de la descripción del texto la palabra issue 1.

Al guardar la entrada de la Wiki, esto se convirtió automáticamente en un hipervínculo hacia el detalle del issue que generamos con anterioridad.

              

Si damos un click encima del hipervínculo, nos llevará al detalle del issue. Me parece que esta forma de generar documentación es muy simple y práctica de usar.

Ahora en la sección de Wiki, tendremos la que hemos creado recientemente:

Integración continua

Cuando creamos un proyecto en Oracle Developer Cloud Service, tenemos aprovisionadas todo lo necesario para realizar el build. Si queremos subirnos al tren de la integración continua, podemos automatizar e integrar ambientes de pruebas, recibir retroalimentación inmediata o desplegar hacia alguna nube: Oracle Java Cloud Service, Oracle Application Container; o bien, a algún ambiente local.

Para hacer uso de esta característica, debemos elegir la opción de build del lado izquierdo del panel:

Para nuestro ejemplo, elegiremos JDK 1.8:

Es posible ejecutar los pasos que nosotros ocupemos para realizar el build de nuestro proyecto. Esto es una característica muy interesante ya que podemos elegir entre lo siguiente:

1.      Ejecutar un Shell

2.      Invocar Ant

3.      Invocar Maven 2

4.      Invocar Maven 3

5.      Invocar Gradle

6.      Invocar NodeJS

7.      Copiar artefactos

En nuestro caso elegimos la opción de ejecutar un Shell:

Después de realizar el build, también hay varios pasos que podemos ejecutar. Algunos que me parecen muy interesantes son: la integración nativa para realizar el despliegue del proyecto en Oracle Cloud Service, publicar un reporte de pruebas de JUnit o la misma documentación de Java.

Salvamos nuestro job y lo ejecutamos:

Una vez que el build termina de ejecutarse, veremos un resumen parecido al siguiente:

Podemos observar que aquí se encuentra el archivo hello.out que definimos en las tareas del build del proyecto. Si damos click en este archivo, se descargará a nuestro equipo local. Podemos explorar el contenido:

Igualmente, si damos un click en la consola, podremos observar todas las tareas que fueron ejecutadas en el build. Si somos un poco observadores, nos daremos cuenta que detrás de las cámaras, se está ejecutando Hudson como nuestro servidor de integración continua. Esta integración entre la nube de Oracle y Hudson es nativa, nosotros no tuvimos que realizar ninguna configuración adicional, sino que fue aprovisionado de manera automática:

Si vamos a la página principal de jobs, se deberá ver como sigue:

Conclusiones

En conclusión, la nube de Oracle Developer Cloud Service (que a menudo viene incluida con el uso o contratación de algunas otras nubes: Oracle Application Container, por ejemplo), es una nube que nos facilita el desarrollo colaborativo, nos proporciona características de integración con Git, DevOps (Maven, Gradle), integración continua (Hudson), Wiki, y algunas otras características.

Es una muy buena opción, considerando que es gratis con el uso de alguna otra nube de Oracle. Sin duda proporciona características que podríamos y deberíamos emplear en los proyectos de desarrollo de software. Está bien pensada para el uso de metodologías ágiles y nos da una buena cantidad de características de caja para estos propósitos.

Considerando que en los proyectos de desarrollo tradicionales no tenemos orden alguno (o al menos a la mayoría de nosotros nos pasa esto en nuestro día a día), sin duda nos proporciona características valiosas que como desarrolladores nos ayuda a organizar mucho mejor el control del código, el seguimiento a los requerimientos y defectos encontrados en el código, el uso de una metodología (dejen ustedes ágil, con que usemos algún tipo de metodología tenemos suficientes beneficios), entre otras muchas que podrían ser de utilidad.