GitHub + Git (SourceTree)

GitHub

Vamos a hacer una pequeña demostración de algunas de las capacidades que tiene GitHub para el control de versiones de código. GitHub es un sistema de almacenamiento de código para control de versiones y colaboración (definición comercial).

Esto es algo de lo que muchos de nosotros hacemos todos los días: colaborar con distintos equipos o compañeros, en uno o varios proyectos, pero al final hay código que pudiéramos compartir.

Es como cuando alguien se va de vacaciones y tienes que ocuparte de sus pendientes, necesitas su código. ¿Y si no te dejó el USB o el disco duro con la última versión? Eso es un poco obsoleto, lo más simple es usar Git para poder hacer esas tareas de colaboración.

Nuevo repositorio

Al grano. Previo a todo esto he creado una cuenta en https://github.com, igual que cuando crearon su cuenta en Twitter o Facebook. Una vez que tienen su usuario y contraseña, pueden entrar al portal y seguir estos pasos.

El primero de todos es crear un nuevo repositorio. Ese lugar en la nube donde van a almacenar todos sus artefactos.

Para esto basta con dar un click en el + que se muestra en la figura y seleccionar la opción para crear un nuevo repositorio.

Posteriormente, el sistema nos va a solicitar algunos datos del repositorio como nombre, descripción, si es público o privado y si queremos inicializarlo (poblarlo) con un archivo README. Al confirmar todo esto ya tendremos nuestro repositorio creado.

El repositorio se va a crear con una rama por default: master. Ésta va a ser la rama en la que se encuentra la última versión de nuestro código, la más actualizada.

Nuevo branch

Para incluir nueva funcionalidad, lo que deberíamos hacer es crear nuevos branches (sin actualizar directamente en master). En esos nuevos branches vamos a trabajar por separado, una vez que finalicemos, vamos a realizar un merge con master para incluir nuestros cambios. Cuando creamos un nuevo branch, tomaremos una foto (snapshot) de master en ese momento del tiempo. Todo el código que se encuentre en master, se copiará a nuestro nuevo branch.

En mi caso he incluido un branch llamado: branch-20170517. Aquí es donde voy a incluir mis cambios, sin alterar el master.

Basta con dar un click en el combo (justo a lado de master) y elegir la opción para crear una nueva rama o branch.

Una vez que he creado mi branch, puedo iniciar a trabajar los cambios que necesite. Para esto es muy importante asegurarnos que estamos realizando estos cambios en el branch que acabamos de crear, no en master.

Una vez que estamos seguros que estamos en el branch adecuado, vamos a trabajar los cambios. Para este ejemplo únicamente voy a modificar el archivo README que se creó inicialmente. La modificación consiste en agregar una nota en el README, pero ahora en español.

Commit (guardar)

Una vez que he realizado los cambios en mi branch de trabajo, voy a hacer un commit del mismo (guardar). El commit siempre tiene asociado un mensaje, con esto podemos tener la historia de quién hizo los cambios y porqué. Es una buena práctica colocar un mensaje claro de los cambios asociados a ese commit.

Después de haber realizado los cambios en el README, es necesario hacer un merge hacia el branch master. Recordemos que estamos trabajando en branch-20170517.

Pull request

Un pull request es la parte fundamental del concepto de colaboración en GitHub. Básicamente con un pull request le solicitamos a alguien, que haga la revisión de los cambios que hemos realizado, la descargue y haga el merge hacia su branch. En este caso estaríamos haciendo algo como lo siguiente:

branch-20140517  >> pull request >> master

Dentro del pull request va a suceder lo siguiente:

comparación >> merge (aprobación de los cambios)  >> confirmación

Para crear el pull request sólo tenemos que ir al tab de la parte superior del sistema: pull request. Luego elegir el botón nuevo pull request.

Posteriormente vamos a llenar algunos datos para crear el pull request. Desde qué branch se originan los cambios (branch-20170517) y hacia qué branch se tienen que trasladar (master). También se muestran las diferencias entre ambas ramas. Una vez realizado esto, hay que presionar el botón crear pull request.

Podemos incluir algunos comentarios, indicando la razón del pull request.

Merge

Esto será enviado a un flujo de aprobación, donde alguien tendrá que hacer el merge de los cambios. En este caso como estoy usando el mismo usuario, yo completaré ambas tareas. Hasta este momento nuestro pull request estará abierto.

Algo que me pareció muy cotorro, es que puedes agregar algunas reacciones (mano arriba, mano abajo, cara feliz, gorro de fiesta). Esto le da un toque de red social a esta parte del flujo. Y puede reflejar en un ícono, nuestro pensamiento acerca de los cambios realizados en el repositorio.

El pull request va a permanecer abierto hasta que alguien apruebe (o rechace) los cambios, y posteriormente lo cierre. En nuestro caso son cambios que se pueden combinar directamente entre nuestro branch de trabajo y master, así que esto es automático. Simplemente presionamos el botón merge pull request, incluimos algunos comentarios si lo consideramos necesario y entonces el pull request quedará cerrado y nuestro branch master ya contendrá los cambios realizados al README.

En la siguiente pantalla tenemos una última confirmación del merge. Si nos queremos arrepentir, éste es el momento. Una vez presionado el botón, ya no se podrá dar marcha atrás.

Lo que nos mostrará el sistema son dos cosas: la confirmación del merge y una opción para borrar el branch. Una vez que tenemos los cambios en master, ya no necesitamos más ese branch.

Finalmente podríamos agregar algunos comentarios y/o reacciones, vemos la confirmación tanto del merge, como del borrado del branch.

Confirmación en el repositorio

Si volvemos a nuestro repositorio, vamos a poder que los cambios ya están incluídos en master.

SourceTree

Hacer esto directamente en GitHub, pudiera ser muy simple. Sin embargo, para una gran cantidad de artefactos, esas tareas de comparación y merge pueden volverse un poco complejas. O bien, si a nosotros no nos acomodan los sitios web y preferimos la línea de comandos, entonces podemos utilizar Git. O algo intermedio, un cliente de Git.

SourceTree es uno de los que me parecen muy intuitivos y completos, por detrás usa Git. Trae un Git propio, o si ustedes tienen una versión en particular previamente instalada, se puede configurar para que use la que más les convenga.

Una vez que el administrador ha creado el repositorio inicial (todos los pasos anteriores), alguna de nuestras tareas pudiera ser hacer algunos cambios (agregar, modificar o eliminar artefactos). Para eso necesitamos tener el código en nuestras máquinas o en un ambiente local. Posteriormente desarrollar, probar y subir los cambios de nuevo al repositorio. Para esto usamos SourceTree (o Git).

Clonar repositorio

Lo primero que haremos es descargar el repositorio que ya está en la nube de GitHub. Elegimos clone, colocamos la URL de nuestro repositorio de GitHub, la carpeta de destino en nuestra máquina y el nombre del branch que deseamos descargar. Presionamos el botón de clonar y esperamos la confirmación de la descarga.

Copia local

Lo anterior nos va a crear una copia local del repositorio en la ruta que indicamos. Ahí comenzaremos con los cambios.

Los cambios que hice son muy básicos: agregué un README, pero en vez de tener extensión MD (como el original del repositorio), le puse extensión TXT.

Commit

Mis cambios están listos y es hora de hacer commit. Si vamos a la sección de commit (arriba a la izquierda) de SourceTree, podemos ver varias cosas: los archivos que están pendientes por subirse al repositorio (README.txt) y el contenido (o diferencia) de lo que está en nuestra copia local y lo que está en el repositorio. Una vez que seleccionamos lo que queremos subir, presionamos el botón de commit (que está abajo a la derecha). Aquí podemos agregar nuestros comentarios del commit (al igual que lo hicimos en GitHub).

SourceTree nos mostrará un mensaje de confirmación y podremos observar de nuevo en la parte central, que ya no hay cambios en nuestra copia local con respecto al repositorio.

Push

Ya que hicimos el commit, los cambios no se verán reflejados en el repositorio, sino hasta hacer un push. Source Tree nos habilitará la sección de push (arriba a la izquierda). Esto nos dará oportunidad de elegir desde dónde y hacia dónde necesitamos hacer el push de los cambios. En este caso van de mi master local hacia el master del repositorio de GitHub. Esperamos la confirmación de finalización del push.

Confirmación de cambios en el repositorio

Ahora podremos confirmar que los cambios fueron colocados correctamente en el repositorio. El archivo README.txt debería estar ahí:

Cambio directamente en el repositorio

Para mostrar cómo debemos tratar cuando alguien más realiza un cambio en el repositorio, vamos a crear una clase java simple directamente en GitHub. De alguna forma SourceTree nos debe avisar que ha habido un cambio en el repositorio y que lo debemos descargar. Esto es para que siempre podamos tener la última copia del repositorio, Podríamos estar trabajando en un componente que alguien más actualizó y subió al repositorio, si no tenemos la última versión podríamos estar planchando sus cambios.

Para mostrar esto creamos la clase java en el repositorio y hacemos commit, directamente en GutHub.

Pull

Ahora veremos en SourceTree que en el botón de Pull, tenemos una marca (número) que indica que algunos cambios están en el repositorio, pero no en nuestra copia local y debemos descargarlos. Presionamos el botón de pull, confirmamos desde dónde y hacia dónde vamos a traer los cambios y finalmente esperamos la confirmación de que los cambios han sido descargados.

Confirmación en nuestra copia local

Finalmente podemos ir a nuestra copia local y confirmar que los cambios han sido descargados correctamente.

Resumen

Esta es una manera muy simple de mostrar algunas de las características GitHub, y también de cómo podemos interactuar con esos repositorios a través de Git o SourceTree, que es un cliente de Git. A partir de aquí pueden crear su propio repositorio y jugar con las estructuras, branches, merge, flujo de GitHub.

Es una inicial y muy simple aproximación a este tipo de sistemas de control de versiones y colaboración en la nube. Puede convertirse en algo muy poderoso e importante en su entorno de integración continua.

Pueden dar una mirada más a profundidad en las referencias que menciono a continuación.

Referencias

GitHub: https://github.com/
SourceTree: https://www.sourcetreeapp.com/
Git: https://git-scm.com/

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