Artículos etiquetados con:qa
Cómo crear desplegar un artefacto con Maven

Uno de los propósitos de QA es generar modelos que aporten consistencia y organización a la hora de trabajar en proyectos de automatización.

Si además queremos que este modelo se sustente en la unificación de las bases de proyectos, la opción es Maven. Dicho esto, la primera pregunta que puede surgir es, ¿y por qué no con Gradle?

Lo cierto es que, a pesar de que su uso parece estar generalizándose, la gran mayoría de los proyectos basados en automatización siguen usando Maven. Además cuenta con una documentación mucho más extensa. Siendo sinceros, aunque empieces a utilizar Gradle para la automatización, finalmente acabarás recurriendo a Maven.

En este post veremos cómo crear, configurar y distribuir artefactos de nuestros proyectos para mejorar los procesos de desarrollos futuros.

 

QUÉ ES MAVEN

En primer lugar debemos entender qué es Maven y el beneficio que nos aporta. Nuestra idea es usarlo para desplegar un artefacto.

Maven es una herramienta que nos simplificará los procesos de desarrollo de un proyecto. Una de las principales ventajas es tenerlo todo centralizado en un fichero llamado POM (Project Object Model), el cual nos aportará toda la información y configuración del proyecto.

Este fichero está dividido en diversas secciones, pero para nuestro propósito nos centraremos principalmente en dos:

  • Configuración de la construcción
  • Configuración del entorno

 

CONFIGURACIÓN DE LA CONSTRUCCIÓN

Contiene la configuración de los plugins e informes que usaremos durante el ciclo de vida de la construcción. Éste se divide en varias etapas con las que podemos alterar el comportamiento del proyecto:

  • Validación
  • Compilación
  • Test
  • Empaquetado
  • Test de integración
  • Verificación
  • Instalación
  • Despliegue

Estas fases tienen una ejecución lineal. Esto quiere decir que, siguiendo la lista anterior, si quisiéramos usar la fase de verificación, previamente Maven pasaría por todas las fases anteriores.

 

CONFIGURACIÓN DEL ENTORNO

Será la encargada de definir los entornos externos a nuestro proyecto que necesitaremos, y los perfiles o requisitos para diferentes configuraciones dentro del mismo entorno. Algunas de las posibles configuraciones son las siguientes:

  • Distribuciones
  • Incidencias
  • Integración continua
  • Cadena de suministros
  • Prerrequisitos
  • Repositorios
  • Perfiles

 

 

QUÉ ES UN ARTEFACTO

A grandes rasgos, un artefacto es un conjunto de funciones, acciones y servicios que almacenamos conjuntamente en un único lugar para que cualquier persona pueda disponer de ellos y poder usarlos.

Así conseguimos tener un proyecto modularizado que nos permita beneficiarnos de todo lo creado. Además, si requerimos de una actualización o necesitamos añadir nuevos artefactos, el impacto de los cambios sobre nuestro proyecto será muy bajo.

 

 

CONFIGURAR UN ARTEFACTO

Para poder llevar a cabo el despliegue de un artefacto, debemos configurar nuestro POM del proyecto siguiendo el siguiente modelo.

A continuación, planteamos un ejemplo de los pasos a seguir para configurar un artefacto que posteriormente pueda ser usado.

 

CONFIGURACIÓN DE LA CONSTRUCCIÓN

Usaremos plugins que se centrarán en cuatro fases del ciclo de vida del proyecto: compilación, empaquetado, verificación y despliegue. Aunque pasaremos por todas, éstas son las fases que nos afectarán principalmente a la hora de generar el artefacto.

maven-compiler-plugins

El compilador será el primero. Simplemente estableceremos para qué versión de Java queremos compilar el código fuente del proyecto. Esto no un requisito necesario pero sí importante para poder evitar incompatibilidades dentro del proyecto.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<version>3.7.0</version>
	<configuration>
		<source>1.8</source>
		<target>1.8</target>
	</configuration>
</plugin>

 

maven-jar-plugin

El empaquetador tendrá el papel de establecer el formato del código compilado. En nuestro caso emplearemos el tipo JAR, pero estos pueden ser diversos según la necesidad.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jar-plugin</artifactId>
	<version>3.0.2</version>
	<executions>
		<execution>
			<id>jar</id>
			<goals>
				<goal>test-jar</goal>
			</goals>
		</execution>
	</executions>
</plugin>

 

maven-source-plugin

Dentro del grupo de empaquetadores, tenemos algunos plugins adicionales que usaremos sobre todo para añadir más información al artefacto final. En nuestro ejemplo hemos introducido el máximo de información al artefacto. Por ello, añadimos el código sin compilar para que sea accesible bajo el proyecto que lo usara y el javadoc que serán todas las descripciones de los componentes del artefacto.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-source-plugin</artifactId>
	<version>2.0.4</version>
	<executions>
		<execution>
			<id>attach-sources</id>
			<goals>
				<goal>jar</goal>
			</goals>
		</execution>
	</executions>
</plugin>

 

maven-javadoc-plugin

Será el encargado de establecer la configuración de empaquetado de toda la documentación en una distribución de tipo JAR.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-javadoc-plugin</artifactId>
	<version>3.0.0</version>
	<executions>
		<execution>
			<id>attach-javadocs</id>
			<goals>
				<goal>jar</goal>
			</goals>
		</execution>
	</executions>
</plugin>

 

maven-jarsigner-plugin

Para la parte de seguridad añadimos, como buenas prácticas, un firmado. Así nos aseguramos de que no está modificado por un tercero.

Usando este plugin verificamos que el firmado sea correcto. Simplemente se necesita configurar un contenedor de firmas y la firma que deseemos usar sobre el artefacto.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jarsigner-plugin</artifactId>
	<version>1.4</version>
	<executions>
		<execution>
			<id>sign</id>
			<goals>
				<goal>sign</goal>
			</goals>
		</execution>
		<execution>
			<id>verify</id>
			<goals>
				<goal>verify</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<keystore>src/main/resources/keystore.jks</keystore>
		<alias>myalias</alias>
		<storepass>password</storepass>
		<keypass>password</keypass>
	</configuration>
</plugin>

 

CONFIGURACIÓN DEL ENTORNO

Para finalizar sólo nos queda configurar el entorno. Para ello, emplearemos únicamente el gestor de distribuciones que será el que subirá a un repositorio privado nuestro artefacto.

Eso sí, debemos tener en cuenta que tendremos dos tipos de versiones de artefacto:

  • En desarrollo
  • De distribución

Como Maven autogestiona qué versión subir, la única forma de indicárselo es mediante el tag Version de nuestro proyecto mediante los siguientes formatos:

  • Versión en desarrollo: X.X.X-SNAPSHOT
  • Versión de distribución: X.X.X
<distributionManagement>
	<repository>
		<id>releases</id>
		<name>my-project-releases</name>
		<url>http://url_repo/artifactory/my-project-releases</url>
	</repository>
	<snapshotRepository>
		<id>snapshots</id>
		<name>my-project-snapshots</name>
		<url>http://url_repo/artifactory/my-project-snapshots</url>
	</snapshotRepository>
</distributionManagement>

 

 

CONFIGURAR LAS CREDENCIALES

Como sabemos, todo servicio suele estar vinculado a una cuenta. Por tanto, debemos establecer nuestro usuario y contraseña de acceso al repositorio para poder realizar el despliegue.

Siguiendo un modelo de buenas prácticas, Maven recomienda establecer estas credenciales en un fichero llamado settings.xml, Éste será el encargado de definir valores de configuración para ser usada en las ejecuciones (sin ser específicas) para un proyecto en concreto.

Los dos ámbitos que podemos encontrar son:

  • Maven. Será usado como configuración global su ubicación se encuentra en ${maven.home}/conf/settings.xml
  • Usuario. Será usado con la configuración establecida por el usuario su ubicación se encuentra en ${user.home}/.m2/settings.xml

Si es la primera vez que configuramos nuestro fichero como usuario, debemos crearlo e introducir las credenciales de la siguiente manera:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
	                    https://maven.apache.org/xsd/settings-1.0.0.xsd">
	<servers>
		<server>
			<id>releases</id>
			<username>admin</username>
			<password>password</password>
		</server>
		<server>
			<id>snapshots</id>
			<username>admin</username>
			<password>password</password>
		</server>
	</servers>
</settings>

Debemos tener muy en cuenta el ID que usemos ya que será el que asocie Maven automáticamente con los repositorios definidos anteriormente.

 

 

DESPLEGAR EL ARTEFACTO

Finalmente, teniendo todas las configuraciones establecidas, sólo nos resta desplegar el proyecto. Por tanto, procederemos a abrir un terminal y navegar hasta el directorio del proyecto de nuestro artefacto.

Una vez situados en él, simplemente convocamos el paso de despliegue de nuestro ciclo de vida para efectuar la construcción completa y finalmente la subida al repositorio de nuestro artefacto.

Usaremos la siguiente línea de comando:

$ mvn deploy

 

 

USAR EL ARTEFACTO

Una vez hayamos configurado correctamente el artefacto, podemos usarlo en proyectos. Para ello, debemos configurar el POM de nuestro nuevo proyecto añadiendo la dependencia de nuestro artefacto de la siguiente forma:

<dependency>
	<groupId>testing</groupId>
	<artifactId>my-project-deploy</artifactId>
	<version>1.0.0</version>
</dependency>

 

Esto nos permitirá un uso total de nuestro artefacto siempre y cuando nuestro repositorio sea público. En el caso contrario, debemos definir la ubicación de nuestros repositorios en nuestro proyecto para que entienda de dónde procede.

<repositories>
      <repository>
            <url>http://url_repo/artifactory/my-project-releases<</url>
            <releases>
                  <enabled>true</enabled>
            </releases>
            <snapshots>
                  <enabled>false</enabled>
            </snapshots>
      </repository>
	<repository>
	      <url>http://url_repo/artifactory/my-project-snapshots</url>
            <releases>
                  <enabled>false</enabled>
            </releases>
            <snapshots>
                  <enabled>true</enabled>
            </snapshots>
      </repository>
</repositories>

 

Hemos realizado un proyecto Maven con todas estas configuraciones de despliegue, para que puedas verlo en acción y utilizarlo como dependencia con tu proyecto si quieres. Podrás encontrarlo en nuestro repositorio de Github.

 

 


¿Qué papel tiene QA en las metodologías ágiles?

Pese a que cada vez son más las empresas que apuestan por el uso de metodologías ágiles en sus equipos de desarrollo de soluciones software, aún son muchos los que desconocen la flexibilidad, la agilidad y el ahorro de tiempo que supone implementar estos procedimientos.

La llegada de metodologías ágiles, tales como Scrum, permite abordar de forma ágil y rápida cada uno de los procesos que conforman la vida de un proyecto:

  • llevando a cabo desarrollos por etapas o sprints
  • realizando subidas a producción más cortas
  • incorporando herramientas de integración continua
  • fomentando la comunicación directa con el cliente para contrastar los resultados periódicamente

El objetivo principal no es otro que detectar errores en fases tempranas para rectificar en cualquier etapa previa a la subida a producción.

Pero sin lugar a duda, una de las mayores ventajas aportadas por las metodologías ágiles es la creación de productos de calidad que logren la completa satisfacción del usuario final. Esto ha dado visibilidad a la importante labor que realizan los responsables de calidad de soluciones software.

 

ENTONCES, ¿QUIÉN NECESITA QA?

A pesar de la visibilización de la que hablábamos, hoy en día, las personas que trabajamos en equipos de QA seguimos percibiendo un gran desconocimiento de nuestras responsabilidades por parte del resto de participantes de un proyecto. Nos encontramos a menudo con preguntas del tipo: ¿Qué es QA? ¿A qué te dedicas exactamente? ¿En qué fase del proyecto entra tu labor?

Es preciso saber, que la labor del QA no sólo tiene lugar tras la fase de desarrollo, como ocurría con las metodologías tradicionales. La figura de los responsables de calidad está presente durante todo el proceso, validando la aptitud del producto en cada una de las etapas.

 

¿QUÉ LABOR DESEMPEÑA UN EQUIPO DE QA?

Como decíamos, al contrario de lo que se piensa de forma generalizada, el equipo de QA no solo se limita a detectar fallos en el sistema. Su labor va mucho más allá: se analizan comportamientos, se anticipan defectos y se verifica que el funcionamiento y la usabilidad de una solución sean correctos.

El equipo de QA se sitúa entre el cliente y el equipo de desarrollo. Ayuda al primero a traducir sus requisitos y objetivos en pruebas, y al segundo a verificar cada una de sus acciones antes de que el producto llegue al usuario. De este modo, el equipo de QA aportará al cliente una visión real del trabajo realizado por el equipo y el estado en que se encuentra el proyecto en cada etapa.

El hecho de estar presente en todo el proceso, permitirá al QA optimizar y mejorar procedimientos ya existentes dentro del equipo, aportando soluciones que tengan como fin último aumentar la calidad de la solución.

Todo esto se traduce en la disminución considerable del tiempo de desarrollo, pudiendo reducir el número de revisiones y permitiendo validar el funcionamiento de la solución en cada una de las etapas.

Pero, ¿cuáles son los puntos fuertes del equipo de QA?

  • Su figura intermedia permite gestionar directamente el feedback del cliente en cada sprint. Permite corregir posibles errores y encontrar soluciones de forma ágil e inmediata.
  • Realiza todo el proceso de pruebas desde la perspectiva del usuario final. Aporta soluciones ante defectos de usabilidad o experiencia de usuario en fases tempranas.
  • Cuenta con un gran conocimiento funcional de la aplicación. Reduce las dudas que los desarrolladores suelen encontrar en la fase de desarrollo.
  • Su labor fomenta el análisis, la documentación y la recopilación de información que será de vital importancia en la fase de desarrollo.
  • Gracias a su manejo de herramientas de integración continua, podrá realizar la automatización de pruebas. Este proceso le llevará, en cualquier caso, a agilizar las pruebas de calidad y rendimiento de la solución desarrollada.

 

EL PROCESO DE PRUEBAS

El proceso de pruebas llevado a cabo por el equipo de QA a lo largo de un proyecto no solo darán lugar a un producto fiable y de calidad, sino que también permitirá establecer un control permanente sobre todos los procesos, evitando los problemas que suponen la detección de errores en fases más avanzadas.

Pero si por por algo se caracteriza el trabajo del equipo de QA es por la completa planificación de sus labores en cada una de las fases de un proyecto:

  1. Análisis
  2. Diseño y desarrollo
  3. Validación y entrega

 

FASE DE ANÁLISIS

En esta etapa verificaremos que tanto los objetivos como los requisitos planteados por el cliente sean correctos y precisos. Con ellos elaboramos un plan de pruebas.

Aquí nos serán de ayuda herramientas que nos permitan crear, ejecutar y dar reporte de los planes de prueba y su adecuación a los requisitos. Entre ellos destacan: TestRail, Zephyr para Jira, Teslink y Mantis.

Identificaremos también los casos de prueba que más tarde se convertirán en test automáticos. El objetivo es ejecutar pruebas de manera repetitiva y detectar posibles incidencias en etapas tempranas.

 

FASE DE DISEÑO Y DESARROLLO

En esta etapa el QA será el encargado de velar por el cumplimiento de cada uno de los requisitos, vigilando que la solución se adapta a la propuesta funcional y de diseño creada entre el equipo y el cliente.

Aquí entran en acción las herramientas de integración continua que permitirán a desarrolladores y QA trabajar en armonía:

  • Se automatizan de procesos de compilación
  • Se revisa del código generado
  • Y se realizan entregas continuas

Así se logra identificar fallos rápidamente. Una de las principales herramientas para hacerlo es Jenkins.

 

FASE DE VALIDACIÓN Y ENTREGA

En la fase final ejecutaremos el plan de pruebas, revisando que la solución ya desarrollada respeta los requisitos fijados y la entrega al cliente se hace en las condiciones adecuadas. Aquí podremos entregar al cliente reportes e informes de nuestro plan de pruebas.

Todos estos procedimientos se llevarán a cabo sprint tras sprint, formando parte importante del proceso iterativo que tanto defienden las metodologías ágiles.

 

 

EN RESUMEN

Decir que las metodologías ágiles han puesto en alza el valor de los equipos QA es innegable. No obstante, no hay que olvidar la responsabilidad que conlleva su participación en cada una de las fases de un proyecto.

Sus labores forman parte de un proceso continuo, que los convierte en los encargados finales de asegurar que el producto funcione correctamente y que logre superar las expectativas, de un cada vez más exigente, usuario final.

Después de todo esto, ya no hagas a un QA la pregunta de ¿a qué te dedicas? Sino ¿cuando empezamos a trabajar juntos?

 


La integración continua actual pasa por pipelines

En integración continua, como en la vida, hay que renovarse o morir y esto es lo que está pasando con los pipelines y herramientas como Jenkins.

Todos los que hemos utilizado Jenkins como herramienta de interacción continua, sabes lo difícil que resulta mantener los jobs si hay algún cambio a todos los que se tengan. Por ello, pedíamos a voces una herramienta que nos ayudase a gestionar estas actualizaciones de forma centralizada. De aquí es de donde surge la idea de pipelines.

Para empezar, tenemos que ponernos en contexto, ¿qué es eso de los pipelines?

 

PIPELINES: DEFINICIÓN

Un pipeline es una nueva forma de trabajar en el mundo devops en la integración continua. Utilizando pipeline y Jenkins, podemos definir el ciclo de vida completo de una aplicación (descargar código, compilar, test, desplegar, etc.) mediante código.

De esta forma, resulta mucho más sencillo replicar los diferentes pasos con distintas aplicaciones y gestionar mejor los cambios en cada paso.

Un ejemplo de pipeline integrado en herramientas como Jenkins podría ser:

Pipelines stageview - SDOS

 

 

 

¿POR QUÉ USAR PIPELINES?

Uno de los mayores beneficios de usar pipelines y Jenkins es poder hacer los jobs más configurables, fáciles de editar y más durables. También podemos utilizar entradas (input) humanos o esperar la aprobación de otro job para ejecutar el nuestro mediante pipelines.

Pero, además de estas ventajas, el principal valor diferencial de esta nueva estructura es que es versátil y extensible, y podemos crear pipelines para hacer un fork, un bucle, e incluso para ejecutar cosas en paralelo. Además podemos customizarlas todo lo que queramos mediante groovy.

 

MÁS VENTAJAS

Con pipeline podemos:

  • Definir de forma sencilla:
    • Parámetros de entrada
    • Variables de entorno y credenciales
    • Opciones como un timeout, retry o descartar builds
  • Enviar mensajes o hacer alguna acción post-build dependiendo del resultado de la ejecución del pipeline.
  • Saltar alguna fase dependiendo del entorno, la rama que ejecutemos, etc. mediante expresiones boleadas.

 

 

TIPOS DE PIPELINES

Hay dos tipos de pipeline: scripted y declarative.

Nosotros nos centraremos en el declarativo, por ser más novedoso y completo, pero te dejamos una tabla para que compares:

SCRIPTED PIPELINE DESCRIPTED PIPELINE
Modelo de programación imperativo Modelo de programación declarativo
Entorno de programación con todas las funciones Sintaxis más simple y pragmática para la creación de Jenkins pipeline
Gran flexibilidad y extensibilidad Limitado a lo que puede hacer un usuario
Se declara y ejecuta mediante nodos Se declara y ejecuta mediante el comando pipeline y los diferentes stages, stage, steps y step
No hay muchas limitaciones para usuarios expertos y requerimientos complejos La mejor opción para el desarrollo de estrategias de CI y CD con Pipelines
En común:
– Usan Groovy
– Pueden utilizar librerías compartidas
– Pueden utilizar script y shell
– Se guardan en un fichero .jenkinsfile

 

 

¿QUÉ ES UN PIPELINE DECLARATIVO?

Un pipeline declarativo es aquel que podemos crear, editar o configurar mediante una estructura definida que nos ayuda a entender y predecir los pasos del pipeline. Simplifica y da opciones a la sintaxis de los sub-sistemas de pipeline. Al igual que los descriptivos, los pipelines declarativos deben guardarse en un fichero Jenkinsfile para poder ser ejecutados luego por Jenkins.

Un ejemplo de un bloque con un pipeline declarativo podría ser:

pipeline {
    /* insert Declarative Pipeline here */
}

Las reglas básicas para construir un pipeline declarativo válido son las mismas que la sintaxis en groovy, con las siguientes excepciones a tener en cuenta:

  • El nivel más alto de un pipeline debe ser un bloque especificado como pipeline {}
  • No hay ; para separar bloques, cada bloque debe estar en su propia línea.
  • Los bloques sólo pueden contener secciones, directrices, pasos o asignación de bloques.

 

SINTAXIS BÁSICA DE UN PIPELINE DECLARATIVO

  • Pipeline {} Identificamos dónde empieza y termina el pipeline así como los pasos que tiene
  • Agent. Especificamos cuando se ejecuta el pipeline. Uno de los comandos más utilizados es any, para ejecutar el pipeline siempre y cuando haya un ejecutor libre en Jenkins.
  • Stages. Bloque donde se definen una serie de estados a realizar dentro del pipeline.
  • Stage. Bloque que define una serie de tareas realizadas dentro del pipeline, por ejemplo: Build. test, deploy, etc. Podemos utilizar varios plugins en Jenkins para visualizar el estado o el progreso de estos estados.
  • Steps. Son todos los pasos a realizar dentro de un stage. Podemos definir uno o varios pasos.
  • Step. Es una tarea simple dentro del pipeline. Fundamentalmente es un paso donde se le dice a Jenkins qué hacer en un momento específico o paso del proceso. Por ejemplo, para ejecutar un comando en shell podemos tener un paso en el que tengamos la línea sh “ls” para mostrar el listado de ficheros de una carpeta.

Un ejemplo de un pipeline declarativo podría ser:

pipeline {
	agent any
	stages {
    	stage('Build') {
        	steps {
            	sh 'make'
        	}
    	}
    	stage('Test'){
        	steps {
            	sh 'make check'
            	junit 'reports/**/*.xml'
        	}
    	}
    	stage('Deploy') {
        	steps {
            	sh 'make publish'
        	}
    	}
	}
}

 

 

¿QUÉ ACCIONES PODEMOS HACER EN UN PIPELINE?

Jenkins nos hace bastante fácil el desarrollo de pipelines. Si estamos acostumbrados a utilizar plugins para nuestra integración continua podremos ver en la mayoría de los changelogs de los plugins que utilizamos que ya soportan pipelines.

Si queremos asegurarnos, tenemos que tener un job con pipeline instalado y hacer clic en la sección de pipeline syntax. Ahí podremos ver todos los plugins que tenemos instalados y si tienen o no un script de pipeline asociado que podamos utilizar.

Pipelines syntax - SDOS

 

Pipelines syntax page - SDOS

 

 

CREACIÓN DE UN JOB CON PIPELINES

Para poder utilizar pipeline debemos instalar varios plugins en Jenkins:

Una vez que los tengamos instalados debemos crear un job tipo pipeline:

Pipelines creation - SDOS

 

A continuación tenemos que añadir la configuración siguiente:

  • Parámetros necesarios:
    • Url del repositorio de Git
    • Rama donde tengamos el código
  • En la sección de pipelines:
    • Url del repositorio de Git donde está el pipeline
    • Rama donde tengamos el pipeline
    • Nombre del fichero .jenkinsfile donde tenemos el pipeline definido

Pipelines configuration - SDOS

 

 

¿CÓMO UTILIZAMOS EL PIPELINE EN QA?

Actualmente en nuestro departamento de QA estamos utilizando los pipelines para realizar la integración continua de nuestros test automáticos con Appium.

Primero, y antes de empezar, necesitamos una serie de parámetros de entrada específicos para poder ejecutar los test, estos son:

Pipelines parameters - SDOS

 

Una vez que tenemos estos parámetros configurados por job, tenemos que ver los pasos que podemos hacer. Es decir, ¿qué pasos tenemos configurados en el pipeline con Appium para pruebas móviles en Android?

  • Configuración inicial. Definición y seteo de variables globales.
  • Descarga de código. Descargamos el código del repositorio mediante una URL y rama.
  • Ejecutar ADB Server. Ejecutaremos el ADB para lanzar el emulador.
  • Lanzar el emulador. Lanzaremos el emulador que hemos configurado desde los parámetros.
  • Appium Test. Ejecutaremos los test de appium.
  • Sonarqube. Realizamos el análisis de Sonarqube a nuestro código.
  • Post-build actions. Enviamos un e-mail con los datos de la ejecución así como una notificación al slack.

 

 

¿CÓMO EJECUTAR UN JOB EN JENKINS CON PIPELINES?

Una vez que tenemos nuestro job configurado con el pipeline, simplemente tenemos que ejecutarlo para ver el resultado de las diferentes fases:

Pipelines ejecution - SDOS

 

 

CONSULTA NUESTRO CÓDIGO DE PIPELINE

Te dejamos un enlace a nuestro repositorio de GitHub. Esperamos que te ayude agilizar los test de Appium y que el mantenimiento de tus scripts de automatización de pruebas sea coser y cantar.

 

 


Nuestro resumen del Sonarsource: Madrid City Tour 2017

El miércoles pasado cogimos un AVE bien temprano para llegar a Madrid, en mitad de la huelga de taxis, al evento de Sonarsource: Madrid City Tour 2017, Spain que se celebraba en el hotel NH Madrid Nacional.

Empezamos con el registro donde conseguimos nuestra acreditación y alguno de esos detallitos que tanto nos gustan…

Acreditación Sonarsource Madrid

 

Una vez que todos tomamos asiento, el CEO de Sonarsource, Olivier Gaudin (@gaudol) nos dio la bienvenida e hizo una pequeña introducción de lo que veríamos en el evento, además de señalar que una de las ambiciones más importantes de Sonarsource como compañía es construir una de las mejores soluciones para la revisión de código del mercado. Y eso nos entusiasma.

También señaló la importancia de analizar el código periódicamente con Sonar para mejorar la seguridad (reducir vulnerabilidades de nuestro código), la fiabilidad (reducir bugs) y la mantenibilidad (reducir deuda técnica).

 

Nuevos productos en la Suite de Sonar

Fabrice Bellingard (@bellingard), Product Manager de SonarCloud, fue el encargado de mostrar todos los productos de la suite de Sonar (SonarLint, Sonarqube, SonarJava, SonarC#, SonarWeb, SonarPHP, SonarTS, etc.) y de anunciar uno de sus nuevos productos: SonarCloud.

Suite productos Sonar - Sonarsource Madrid - SDOS

 

SonarCloud es una plataforma de análisis de código continuo y online con la que puedes analizar tus proyectos y ver los resultados online en la nube.

Todas estas herramientas que nos ofrece Sonar nos ayudan a crear lo que llamaron “Continuous Code Quality” que incluye: Continuous Integration, Continuous Deployment, Operate, Continuous Delivery.

 

Demo de Git + Jenkins + SonarCloud

Llegó entonces la espectacular demo con SonarCloud, también de manos de Fabrice Bellingard.

¿En qué consistió esta demo? Partiendo de un repositorio de Git con un código sin fallos previamente analizado por Sonarqube, un Job de Jenkins (con Pipelines) se lanzaba mediante un webhook configurado en Git cuando encontraba un nuevo Pull Request en el repositorio. Este Job de Jenkins estaba asociado a un JenkinsFile que contenía un Step para analizar el código del PR con Sonarqube. Los resultados del análisis del nuevo código se mostraban en SonarCloud.

Demo - Sonarsource Madrid - SDOS

 

La demostración tuvo como finalidad mejorar la calidad de cada PR y comprobarla antes de mergear el código con la rama Máster.

 

Nueva métrica: complejidad cognitiva

Tibor Blenessy (@saberduck), uno de los desarrolladores de Sonarqube, nos presentó una nueva métrica en Sonar: la complejidad cognitiva.

La complejidad cognitiva es una nueva forma de medir la entendibilidad del código. Como apuntó Tibor citando a Martin Fowler: “Cualquier tonto puede código que un ordenador entienda. Los buenos programadores son aquellos que escriben código que los humanos puedan entender”.

Surgió entonces una pregunta: ¿en qué se diferencian entonces la complejidad ciclomática y la complejidad cognitiva para Sonar? La complejidad ciclomática mide la testeabilidad del código, mientras que la complejidad cognitiva mide el entendimiento del código, además de promover hacer un código mejor.

 

Cómo escribir código limpio

Otra de las partes destacadas del evento fue la intervención de la empresa Excentia, partner de Sonar, que nos habló sobre cómo escribir código limpio, dándonos una receta para ello:

  1. Cuando codifiques, arregla los errores antes de que existan con SonarLint
  2. Cuando hagas un push, analiza cada Pull Request con Sonarqube
  3. Cuando hagas una subida, comprueba el Quality Gate del nuevo código con Sonarqube y Jenkins
  4. Cuando gestiones, echa un vistazo al estado de todos tus proyecto con Sonarsource Enterprise Edition

Limpiar código - Sonarsource Madrid - SDOS

 

Recurrieron además a una gráfica para todos conocida, la del coste de arreglar un defecto en las diferentes etapas del ciclo de vida software.

Coste de errores - Sonarsource Madrid - SDOS

 

Nueva Versión de Sonar en noviembre

Para finalizar el evento, Olivier Gaudin anunció la que fue una de las noticias más importantes del evento: la presentación de una nueva versión estable (LTS: Long Time Support) de Sonar en el mes de noviembre. Esta nueva versión contará con muchísimas nuevas features, incluyendo funciones comerciales como gran disponibilidad, gestión de ramas y notificaciones de SonarLint.

También se habló de las diferentes soluciones que nos ofrece Sonar, así como de las ventajas y desventajas de cada una.

 

Nuestras reflexiones

Después de todas estas exposiciones tan interesantes, tuvimos una comida en la misma sala en la que pudimos, en un ambiente más relajado, preguntar todas las dudas y hablar con los ponentes.

Nos volvimos a Sevilla con muy buena sensación: lo que vimos allí está en muy en línea con el trabajo diario en nuestro departamento de QA. Nos ha servido también para conocer algunas herramientas que ya hoy, sólo unos días después del evento, hemos incorporado a nuestro trabajo.

En resumidas cuentas, Sonarsource Madrid City Tour nos ha servido para constatar que hay algo que estamos haciendo bien en QA. Estamos en el camino a seguir. Queremos y sabemos que vamos a llegar muy lejos.


Save the date! 26/09: meetup QA

El próximo martes 26 de septiembre, nuestra oficina de Sevilla alojará una Meetup sobre calidad en el desarrollo de software. Estefanía Fernández, responsable del área QA en SDOS, será la encargada de compartir sus conocimientos sobre SonarQube y Docker.

Siguiendo la dinámica habitual de este tipo de encuentros, el enfoque será participación abierta y práctico, con ejemplos reales del uso de estas herramientas que serán muy útiles a la hora de utilizarlas.

En SDOS estamos entusiasmados con acoger a la comunidad QA de Sevilla para este encuentro. Un comunidad que, aunque de creación relativamente reciente, cuenta ya con unos 150 miembros y está apostando muy fuerte por ser punta de lanza del sector.

Si te interesa, ¡ya sabes! Te esperamos en nuestra oficina, el martes 26 de septiembre a las 19:00 horas. La inscripción se llevará a cabo desde la plataforma Meetup. ¡Date prisa que el aforo es limitado!


Uso de cookies

Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continúas navegando estas dando tu consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pincha el enlace para obtener más información.

ACEPTAR
Aviso de cookies