Documentación técnica

Ultima actualización: May 17th, 2018

Arquitectura

Quind está diseñado para adaptarse e integrarse facilmente con diferentes sistemas. Su arquitectura es modular basada en microservicios que reciben datos através de componentes recolectores construidos facilmente para extraer la información de sistemas externos y convertirla en métricas de valor a través del servidor central de Quind.

Quind está conformado por las siguientes capas:

  • Servicios: La vista accede a los microservicios a través de un reverse proxy implementado con ngnx, esto con el fin de facilitar el cambio de los endpoints de cada microservicio y optimizar el desempeño.
  • UI: Contiene los elementos visuales implementados en HTML y angular JS para presentar la información al usuario.
  • Recolección de información: Son los componentes que recolectan la información de los sistemas externos para enviarla a Quind. Estos pueden ser desplegados on-premise.
  • Datos: Quind usa MySQL como base de datos, cada microservicio tiene su propio esquema.
  • Procesamiento de información: El procesamiento de información está divido en microservicios con su propio esquema de datos, esto con el fin de incrementar el desempeño y escalabilidad del sistema.
  • Cada microservicio es un corte transversal de servicios, lógica de negocio y acceso a datos.

  • QaLog: Contiene las reglas de negocio para el cálculo de los indicadores de madurez del software.
  • CiLog: Contiene las reglas de negocio para el cálculo de indicadores de madurez del proceso
  • QaStats: Recibe toda la información de los microservicios de procesamiento dejándola disponible para visualización.
  • Users: Este microservicio implementa oauth2 para autenticar y autorizar el acceso a los servicios.
  • Arquitectura de despliegue
    screenshot

    Configuración de servidores

    Quind extrae información de otros servidores externos como Jenkins, TFS, VSTS y SonarQube para generar métricas de calidad. La configuración puede realizarse con estos servidores expuestos en internet (públicos) o sin exposición ejecutando un agente de recolección de información al interior de la red de la empresa.

    Configuración de SonarQube público

    Si el servidor es público solo debe ingresar a la sección de servidores, seleccionar "Público", ingresar los datos de URL, usuario, clave y presionar el botón agregar.

    screenshot

    Configuración de SonarQube privado

    1. Ingrese a la sección de servidores y haga click en agregar.
    screenshot
    2. Si el servidor es privado descargue el agente de recolección de datos
    screenshot
    3. Ejecute el siguiente comando para correr el agente en un servidor que tenga acceso a Sonar y Salida a internet en su propia red.
    java -DQUIND_SERVER=http://qalog.quind.io -DAPI_CLIENTS_TOKEN=$2y$10$FDUVXD6rwrYYPEWrQHLuxHJ3Vic7MQyybX04lQbAyfpeiTW2Fi -DFRECUENCIA_EJECUCION_SEGUNDOS=14400 -DENABLE_TRACING=true -DOAUTH_SERVER= http://user.quind.io/api/v1 -DCLIENT_ID=3 -DCLIENT_SECRET=iw6g3EWUSKMZi8K2L97WK0qJIuXezRHRr1AQma9o -DUSE_PROXY=false -DPROXY_SERVER=null -DPROXY_USERNAME=null -DPROXY_PASSWORD=null -jar /usr/lib/quind/qalog-client/qalog-client-1.0.jar

    Configuración de servidor de integración continua público

    Solo debe ingresar a la sección de servidores, seleccionar el tipo de servidor a configurar, ingresar los datos de URL, usuario, clave y presionar el botón agregar. Para el caso de Jenkins el servidor de build y de release son la misma URL. Para VSTS y TFS cambian según la versión

    screenshot

    Configuración del proceso

    A través de Quind usted podrá estandarizar el proceso de desarrollo y entrega de soluciones definiendo de manera única las tareas que deben realizarse en cada punto y verificando automaticamente cuales pasos se encuentran automatizados en su Delivery/Deployment Pipeline.

    Proceso general

    El primer paso para configurar el proceso en Quind es definir las etapas que hacen parte de él. Una etapa es un agrupador de tareas relacionadas entre sí que juntas permiten alcanzar un objetivo especifico. Quind sugiere definir las siguientes etapas como parte de su proceso según sea la necesidad:

  • Integración del software: Agrupa tareas relacionadas con integración continua tales como, compilar, generar desplegable, analizar el código, validar adherencia a la arquitectura de referencia, ejecutar pruebas unitarias y desplegar en un ambiente de integración. Su propoósito es dar feedback rápidamente a los desarrolladores.
  • Pruebas funcionales: Agrupa tareas que permiten reducir los riesgos de un mal funcionamiento en el software tales como, aprovisionar los ambientes de pruebas, configurarlos, desplegar el software, ejecutar pruebas de aceptación y hacer gestión de configuración de los artefactos que pasan los controles de calidad.
  • Pruebas de desempeño: Agrupa tareas que permiten verificar el desempeño de software tales como, aprovisionar los ambientes de pruebas de desempeño, configurarlos, desplegar el software, ejecutar pruebas de desempeño y hacer gestión de configuración de los artefactos que pasan los controles de calidad.
  • Pruebas de seguridad: Agrupa tareas que permiten identificar problemas de seguridad por la forma en la que se construyó el software tales como, realizar analisis estático de seguridad, realizar analisis denámico de seguridad y hacer gestión de configuración de los artefactos que pasan los controles de calidad.
  • Pruebas de aceptación: Contiene las tareas que soportan las pruebas de aceptación del usuarios tales como, aprovisionar, configurar y desplegar la aplicación a un ambiente de demostración, permitir al usuario aprobar o rechazar la versión y hacer gestión de configuración de los artefactos que pasan los controles de calidad.
  • Despliegue a producción: Agrupa las tareas relacionadas con la salidad a producción, entre ellas aprovisionar y configurar ambientes, desplegar en staging, en producción, hacer pruebas de humo, devolver a una versión estable en caso de error de despliegue y hacer gestión de configuración de los artefactos que pasan los controles de calidad.
  • Para configurar las etapas siga los siguientes pasos:

    1. Ingrese a la sección de servidores y haga click en etapas.
    screenshot
    2. Cree las etapas
    screenshot
    3. Edite las etapas para adicionar tareas
    screenshot
    4. Adicione tareas a la etapa colocando adecuadamente las expresiones regulares para detectar la acciones en el servidor de integración continua o release manager (identifique cómo según la tecnología: Jenkins, VSTS, TFS).
    screenshot

    Jenkins pipeline clásico

    En esta sección explicamos como configurar las tareas que hacen parte de las etapas del proceso de modo que puedan ser detectadas en un pipeline de despliegue de Jenkins.

    Antes que nada es importante entender que los pipeline de despliegue se pueden configurar de 2 maneras diferentes: Una de ellas es la clasica través de la creación de Jobs que agrupan una serie de acciones y están encadenados entre sí; o a través de Pipeline as Code, una manera de expresar el pipeline de manera declarativa.

    Identificar los nombres de las acciones en un esquema clasico de Pipeline en Jenkins:

    screenshot

    Para identificar los nombres de las acciones configuradas en el job de Jenkins en un esquema de pipeline clasico, es necesario mirar los servicios rest. Siga los siguientes pasos:

  • 1. Autentiquese en jenkins.
  • 2. Ingrese hasta la carpeta que contenga los jobs que desea analizar.
  • 3. Complete la URL que aparezca en el browser con el siguiente fragmento. /api/json?depth=1&tree=displayName,jobs[_class,displayName,lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]], lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]
  • 4. Ingrese a la URL. Ver ejemplo http://localhost:8080/job/CARPETA1/job/CARPETA2//api/json?depth=1&tree=displayName,jobs[_class,displayName, lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]], lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]
  • 5. Analice el JSon de respuesta, primero busque el nombre del Job cuyas acciones desea identificar e identifique los "actions". Cada "action" corresponde a una de las acciones que forman el job de jenkins. Ejemplo CauseAction, FitnesseResultsAction.
    screenshot

    "actions" : [ { "_class" : "hudson.model.CauseAction" }, { }, { }, { }, { "_class" : "hudson.plugins.fitnesse.FitnesseResultsAction" }, { }, { } ], "number" : 162 },

    Identificar las expresiones de regulares que deben estar presentes en las tareas de la etapa a partir de las acciones presentes en los jobs de jenkins:

    Las tareas en Quind se configuran con la siguiente estructura general de expresión regular.

    "nombre de la carpeta que contiene a los jobs"->"nombre del job que contiene las acciones"->"nombre de la acción"

    A continuación mostramos algunos ejemplos de cómo configurar las expresiones regulares para que el proceso de Quind reconozca las tareas configuradas en los Jobs que están en la carpeta redyTransaccional.

    screenshot

    Nombre Carpeta Nombre Job Nombre acción Expresión regular Descripción
    redyTransaccional redyTransaccional_Build hudson.plugins.sonar.action.SonarAnalysisAction .*->.*_Build->.*Sonar.* La expresión regular permite identificar las acciones que contengan la palabra Sonar de los Jobs que terminen en _Build sin importar la carpeta en la que se encuentre.
    redyTransaccional redyTransaccional_AceptTest hudson.plugins.fitnesse.FitnesseResultsAction .*->.*_AceptTest->Fitnesse.* La expresión regular permite identificar las acciones que empiecen por la palabra Fitnesse de los Jobs que terminen en _AceptTest sin importar la carpeta en la que se encuentren.
    redyTransaccional redyTransaccional_DepPro hudson.model.ParametersAction redyTransaccional->.*_DepPro->ParametersAction La expresión regular permite identificar las acciones tengan el nombre exacto ParametersAction de los Jobs que terminen en _DepPro y que estén ubicados en la carpeta redyTransaccional.
  • Jenkins pipeline as code

    En esta sección nos enfocaremos en la forma de configurar las tareas del proceso de delivery de Quind cuando se usa Jenkins Pipeline as Code.

    Identificar los nombres de las acciones en un esquema de pipeline as code de Jenkins:

    screenshot

    Para identificar los nombres de las acciones configuradas en el job de Jenkins en un esquema de pipeline as code, es necesario mirar los servicios rest. Siga los siguientes pasos:

  • 1. Autentiquese en jenkins.
  • 2. Ingrese hasta la carpeta que contenga los jobs que desea analizar.
  • 3. Complete la URL que aparezca en el browser con el siguiente fragmento. /api/json?depth=1&tree=displayName,jobs[_class,displayName,lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]], lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]
  • 4. Ingrese a la URL. Ver ejemplo http://localhost:8080/job/CARPETA1/job/CARPETA2//api/json?depth=1&tree=displayName,jobs [_class,displayName,lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]], lastBuild[actions[_class,nodes[displayName,id,parents,_class]]]
  • 5. Analice el JSon de respuesta, primero busque el nombre del Job cuyas acciones desea identificar e identifique los "actions". Cada "action" corresponde a una de las acciones que forman el job de jenkins. Ejemplo CauseAction, FitnesseResultsAction. Luego identifique los FlowGraphAction, en esta sección se encuentra el detalle de las fases y de los pasos del pipeline.
    screenshot

    "actions" : [ "_class" : "org.jenkinsci.plugins.workflow.job.views.FlowGraphAction", "nodes" : [ { "_class" : "org.jenkinsci.plugins.workflow.graph.FlowStartNode", "displayName" : "Start of Pipeline", "id" : "2", "parents" : [ ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepStartNode", "displayName" : "Allocate node : Start", "id" : "3", "parents" : [ "2" ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepStartNode", "displayName" : "Allocate node : Body : Start", "id" : "4", "parents" : [ "3" ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepStartNode", "displayName" : "Stage : Start", "id" : "5", "parents" : [ "4" ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepStartNode", "displayName" : "Declarative: Checkout SCM", "id" : "6", "parents" : [ "5" ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepAtomNode", "displayName" : "General SCM", "id" : "7", "parents" : [ "6" ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepEndNode", "displayName" : "Stage : Body : End", "id" : "8", "parents" : [ "7" ] }, { "_class" : "org.jenkinsci.plugins.workflow.cps.nodes.StepEndNode", "displayName" : "Stage : End", "id" : "9", "parents" : [ "8" ] },

    Identificar las expresiones de regulares que deben estar presentes en las tareas de la etapa a partir de las acciones presentes en los jobs de jenkins:

    Las tareas en Quind se configuran con la siguiente estructura general de expresión regular.

    "nombre de la carpeta que contiene a los jobs"->"nombre del job que contiene las acciones"->"org.jenkinsci.plugins.workflow.job.views.FlowGraphAction"->"Stage name"->"step name"

    A continuación mostramos algunos ejemplos de cómo configurar las expresiones regulares para que el proceso de Quind reconozca las tareas configuradas en los Jobs que están en la carpeta Carpeta1.

    screenshot

    Nombre Carpeta Nombre Job Nombre acción Nombre fase Nombre paso Expresión regular Descripción
    Carpeta1 KitBasicoPipeline org.jenkinsci.plugins. workflow.job.views.FlowGraphAction Probar unitariamente Windows Batch Script .*->.*Pipeline->org.jenkinsci.plugins.workflow.job.views.FlowGraphAction->Probar unitariamente->Windows Batch Script La expresión regular permite identificar los pasos "Windows Batch Script" que hagan parte de la fase "Probar unitariamente", que hagan parte de la acción FlowGraphAction (La cual aparece cuando se trata de pipeline as code), que sean parte de un Job cuyo nombre termine en "Pipeline" y que se encuentre en cualquier carpeta.
    Carpeta1 KitBasicoPipeline org.jenkinsci.plugins. workflow.job.views.FlowGraphAction Analisis de código Prepare SonarQube Scanner environment Carpeta1->.*Pipeline->org.jenkinsci.plugins.workflow.job.views.FlowGraphAction->Analisis de código->.*Prepare SonarQube Scanner environment.* La expresión regular permite identificar los pasos que contengan el texto "Prepare SonarQube Scanner environment" que hagan parte de la fase "Analisis de código", que hagan parte de la acción FlowGraphAction (La cual aparece cuando se trata de pipeline as code), que sean parte de un Job cuyo nombre termine en "Pipeline" y que se encuentre en la carpeta Carpeta1.
  • Team Foundation Server

    En proceso de constucción

    Visual Studio Team Service

    En proceso de constucción