Guia de Jenkins

On 10 septiembre, 2012, in Herramientas, by twiindan

El otro dia hablamos de los sistemas de integración continua. Comentamos varias herramientas como Jenkins (antiguo Hudson) o Cruise Control.

En mi caso siempre he utilizado Jenkins, ya que a sido la que más plugins tiene desarrollados y mejor se integraba con las herramientas y arquitecturas que se estaban desarrollando. Aquí comparto una guía totalmente gratuita sobre Jenkins donde explica como empezar o como realizar la mayoria de las funciones de este particular “mayordomo”.

El libro se puede descargar gratuitamente de la pagina web de “Wakaleo” (rellenando unos datos)  o se puede comprar en la editorial O’Reilly por 35 dolares.

 

Tagged with:  

Seguro que más de uno de vosotros habéis tenido que realizar una integración entre diversos componentes de software que llevan mucho tiempo sin integrarse… normalmente esto provocaba una situación de incompatibilidades entre los componentes que comprometía una perdida de tiempo muy grande en el desarrollo del software.

Para solucionar este escenario, una de las prácticas que se está implantando en las empresas dentro del desarrollo de software es el sistema de integración continua. Pero que es realmente este sistema?

Según la definición de Martin Fowler: “La integración continua es una práctica de desarrollo de software en la cuál los miembros de un equipo integran su trabajo frecuentemente, como mínimo de forma diaria. Cada integración se verifica mediante una herramienta de construcción automática para detectar los errores de integración tan pronto como sea posible. Muchos equipos creen que este enfoque lleva a una reducción significativa de los problemas de integración y permite a un equipo desarrollar software cohesivo de forma más rápida.”

Para ello se pueden utilizar un software especializado en automatizar tareas y que estas se ejecuten de forma automática cuando se genere un evento como puede ser Cruise Control o Jenkins. Que tareas se pueden automatizar en estas plataformas?

  • Compilación de los componentes
  • Integración de todo el desarrollo
  • Ejecución de pruebas unitarias
  • Ejecución de pruebas de integración
  • Ejecución de pruebas de aceptación
  • Obtener métricas de calidad de código
  • Despliegues automáticos

Estos son solo algunos ejemplos de las tareas automaticas que se pueden realizar si aplicamos una metodología de integración continua con alguna de las herramientas que hemos comentado anteriormente y de sus plugins. Realmente se pueden automatizar muchas más tareas, ya que son herramientas muy versátiles a las que se le pueden añadir plugins para aumentar la funcionalidad.

Como funciona realmente? La herramienta se conecta automáticamente a un repositorio de versiones (SVN, CVS, GitHub, Mercurial…) y detecta cuando se ha subido una nueva versión de código en el repositorio. Una vez detectado el cambio se desencadenan las operaciones automáticas que se hayan configurado en la herramienta como la compilación o la ejecucción de tests unitarios.

Que conseguimos realmente con esto?

  • Un feedback temprano al equipo ya que en el caso de que el software no compile o no pase los tests unitarios el sistema avisara como que ha habido una compilación fallida.
  • Tenemos una build de forma automática cada vez que se suba el código al repositorio. Esto implica una reducción del riesgo a la hora de integrar el producto.
  • Permite la detección temprana de bugs, ya que estos se detectaran también en la subida de código al ejecutarse las pruebas de integración y aceptación de forma automática
  • Monitorización constante de las métricas del software (duplicidad de código, coberturas, complejidad…).

Como véis ventajas muy importantes y que nos permiten bajar los riesgos de la construcción del producto y poder reaccionar con mayor rapidez cuando se introducen bugs en el código o se sube una compilación fallida.

Con la integración continua ya no oiremos más “it works in my machine!!!!”

Más información: http://martinfowler.com/articles/continuousIntegration.html

Tagged with:  

Como comentamos en uno de los últimos posts, en las siguientes entregas hablaremos de los testing quadrants que ya introducimos y que descubri en el libro de “Agile Testing”. En esta entrega empezamos con el primero de los testing quadrants.

El Testing Quadrant Q1 es el primero de los quadrantes de testing a tener en cuenta, pero también es posiblemente el testing en el que menos involucrado se encuentra el tester.

Este tipo de testing suele estar muy ligado con la parte tecnológica del proyecto, ya es donde se realizan los unit tests o los tests de integración.

El proposito principal de este testing es ayudar al equipo a entender como debe funcionar el código a realizar, y proporcionar una guia para un correcto diseño de este software.

Generalmente este tipo de testing suele estar muy automatizado, mediante herramientas como xUnit (dependiendo del lenguaje de programación). En este tipo de testing se englobarian las metodologías de diseño como TDD (Testing Drive development).

También es recomendable ejecutar estos tests cuando se realiza una subida de nuevo código para comprobar que no tenga efectos colaterales y detectar posibles errores. Por ese motivo se aconseja introducirlo dentro del sistema de integración continua.

Como ventajas principales  de este tipo de testing podemos destacar tres:

  1. La velocidad de ejecución de los tres es extremadamente rápida por lo que se pueden ejecutar cada vez que se realiza alguna nueva funcionalidad.
  2. Se realizan tests a nivel unitario por lo que se puede llegar a condiciones complicadas de obtener por otro tipo de testing.
  3. Pueden servir como base para otro tipos de testing de más alto nivel como tests automatizados de aceptación o de negocio.

Y en que lugar queda el tester dentro de este tipo de testing? Generalmente los testers no se involucran en los tests unitarios ya que los suelen realizar los programadores.

Sin embargo, en metodologías ágiles, si que es aconsejable que los testers se involucren en este tipo de testing ayudando y guiando a los desarrolladores a diseñar esos tests unitarios. De esta manera el desarrollador puede aprender técnicas para realizar los tests unitarios de forma más eficiente, y el tester puede aprender de desarrollo como funcionan los tests unitarios y entender la forma en la que trabaja el desarrollador.

Recordar que al final el objetivo del equipo es el mismo, entregar un software de calidad, y esta calidad es responsabilidad de todo el equipo. Por eso es importante el soporte continuo entre todo equipo.

Tagged with:  

Nuevo número de Testing Expirience

On 8 diciembre, 2010, in Revistas, Sin categoría, by twiindan

Ya se ha publicado una nueva entrega de la revista profesional sobre el testing Testing Expirience.

Con este número, ya son 12 los publicados y de los que se han descargado más de 300.000 copias en formato digital.

Este número se dedica a las herramientas Open Source, donde podemos encontrar varios ejemplos y casos prácticos de herramientas tan conocidas como TestLink o Hudson entre otras.

Esta vez se ha publicado también un pequeño articulo que he realizado sobre sistemas de integración continua utilizando herramientas Open Source.

Espero que la disfrutéis y perdáis el miedo a utilizar este tipo de herramientas que en algunos casos pueden ser muy completas y útiles para nuestro día a día.

Recordad que la revista es gratuita en formato digital (realizando el registro previamente) y cuesta 8 euros si la queréis un formato impreso.

Podéis descargar la revista del siguiente enlace.