MARMITA. Ingeniería

De EduWiki
Revisión de 13:05 26 sep 2019 por Cap04c (Discusión | contribuciones) (Instalación del entorno de desarrollo)

(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar

Introducción

Volver a MARMITA

Concepto

El subsistema de Ingeniería contempla el conjunto de pautas y procedimientos de trabajo bajo los que se debe regir el desarrollo de cualquier proyecto de desarrollo, adaptando en cada caso a lo que cada tecnología necesite, pero con el objetivo de tener una forma de trabajo homogénea y común para todos los desarrollos de aplicaciones.
De esta forma, se estandarizará y garantizará la calidad de las distintas fases del ciclo de vida del software.
Se definirán las actividades necesarias en la gestión y desarrollo del producto.

Objetivos

Los objetivos que persigue este subsistema son los siguientes:

  • Disponer de un conjunto de normas homogéneas de funcionamiento.
  • Conseguir que el software tenga una calidad homogénea.
  • Ser capaces de planificar los plazos de entrega
  • Conseguir una mayor satisfacción del usuario al ver cubiertas sus necesidades


Según MADEJA las áreas a definir son las siguientes:

Áreas
1.Contenidos generales
2.Comunicación y Difusión
3.Creación y Evolución de Sistemas
4.Ingeniería de requisitos
4.1.Desarrollo de requisitos de un sistema que satisfaga las necesidades de negocio
4.2.Gestión de requisitos del sistema software a desarrollar
4.3.Identificación de las necesidades de negocio
5.Gestión de Proyectos
5.1.Finalización del Proyecto
5.2.Gestión de la Planificación del Proyecto
5.3.Inicio del Proyecto
5.4.Seguimiento y Control de Proyectos
6.Formación

Políticas

Securización de servicios REST

Por defecto, todas las apliaciones web estarán securizadas con Apache Shiro contra el CAS. Los servicios REST que sirvan a tales aplciaciones web también estarán securizadas de igual manera. En cambio, los servicios REST que sirvan a aplicaciones nativas (Android e IOs) deberán estas securizados con OAUTH contra el OAUTH del CAS.

Flujo de desarrollo

Flujo en general

Antes de subir algo a producción.

  1. Reflexionar sobre la necesidad de parar la aplicación
  2. Subir los cambios en la capa de base de datos.
  3. Subir los cambios en la capa de presentación.

Flujo en JAVATO

  1. Bajo el proyecto de SVN en eclipse
  2. Realizo las modificaciones
  3. Ejecuto el programa para probarlo hasta que funcione
  4. Hago commit
  5. En Jenkins, ejecuto tarea de subida del proyecto a pruebas.
  6. En Jenkins, solicito tarea de subida del proyecto a producción.

Flujo en java

  1. Bajo el proyecto de SVN en eclipse
  2. Realizo las modificaciones
  3. Ejecuto el programa para probarlo hasta que funcione
  4. Hago commit
  5. En Jenkins, ejecuto tarea de subida del proyecto a pruebas.
  6. En Jenkins, solicito tarea de subida del proyecto a producción.

Flujo en Angular

  1. Bajo el proyecto de SVN en eclipse
  2. Realizo las modificaciones
  3. Ejecuto el programa para probarlo hasta que funcione
  4. Hago commit
  5. En Jenkins, ejecuto tarea de subida del proyecto a pruebas.
  6. En Jenkins, solicito tarea de subida del proyecto a producción.

Flujo en PHP

  1. Bajo la rama del proyecto de SVN en eclipse
  2. Realizo las modificaciones
  3. Ejecuto el programa para probarlo hasta que funcione
  4. Hago commit
  5. Subo por FTP donde corresponda.

Flujo en .Net

Para el proyecto PLUMIER

  1. Bajo el proyecto de SVN, rama de pruebas.
  2. Realizo las modificaciones
  3. Ejecuto el programa para probarlo hasta que funcione
  4. Hago commit
  5. Despliegue en CITRIX de prueba ( el compilado se proporciona y notifica a Sistemas mediante CLIP para que lo instalen)
  6. Para subir a producción, los pasos siguientes
  7. Descargo la rama de producción
  8. Merge con la rama de producción
  9. Compilación
  10. Ejecución del programa para comprobación
  11. Commit
  12. Publicación desde Visual Studio
  13. Se sube al equipo CEACEJO
  14. Se notifica a la persona encargada de distribuirlo en los CPD.
  15. Despliegue en CITRIX de producción y AVATAR ( el compilado se proporciona y notifica a Sistemas mediante CLIP para que lo instalen)

Para Servicios Web

  1. Se trabaja en una de las máquinas virtuales con Visual Studio 2003 instalado
  2. Bajo el proyecto de SVN con cliente SVN (Tortoise), rama de pruebas
  3. Realizo las modificaciones
  4. Ejecuto el programa para probarlo hasta que funcione
  5. Hago commit
  6. Publicación desde Visual Studio
  7. Se instala en el IIS de pruebas ( 147.84.65.3) copiando la carpeta bin
  8. Para subir a producción, los pasos siguientes
  9. Descargo la rama de producción
  10. Merge con la rama de producción
  11. Compilación
  12. Commit
  13. Publicación desde Visual Studio
  14. Inclusión en el repositorio SVN de las versiones de servidor.
  15. Despliegue de la aplicación en Natalia.
  16. Si la instalación requiere parada de los servicios para incluir actualizaciones de la BBDD (scripts pesados, modificaciones tablas, o gran número de modificaciones de paquetes, tablas y scripts de datos) se crean dos carpetas en el SVN, una para parar los servidores y poder dedicarnos durante la parada a la actualización de la BBDD y otra para instalar la nueva versión y arrancar, junto con las dos peticiones en Natalia.

Flujo en Forms

  1. Descargar de SVN
  2. Edición con el entorno de Forms
  3. Pruebas contra desarrollo hasta que funcione.
  4. Commit para subir al SVN
  5. Subida por Natalia a pruebas
  6. Subida por Natalia a producción

Hay casos en los que no funciona el entorno de FORMS en el PC, Para probar el formulario OAS, como el entorno de desarrollo que tengo instalado no permite ejecutar el formulario, se pasa FTP al servidor de pruebas el formulario. Cuando es una versión correcta, lo subo a SVN, y traspaso a producción por Natalia.

Flujo en paquetes PL/SQL

  1. Bajo el proyecto de SVN con cliente SVN (Tortoise). En el caso de plumier, se descarga la rama de pruebas
  2. Modifico el código de base de datos contra desarrollo.
  3. Se prueba hasta que funciona
  4. Se sube al SVN haciendo commit
  5. En Plumier para subir a producción se descarga la rama de producción, se hace Merge de pruebas con producción, y luego COMMIT.
  6. Con Natalia se sube a producción los scripts.
  7. Recompilación de la BBDD tras actualizar desde Natalia.

Flujo en scripts

  1. Se descarga de SVN el paquete
  2. Modifico el código de base de datos contra desarrollo. Se prueba
  3. Se sube al SVN
  4. Con Natalia se sube a pruebas.
  5. Con Natalia se sube a producción.



Control de versiones

El control de versiones es fundamental

Se ha creado una página que habla tanto de esto como del procedimiento de despliegue.

http://eduwiki.murciaeduca.es/wiki/index.php/Uso_de_herramientas_de_control_de_versiones

Política de asignación de versiones

Según el estandar de facto de versionado la versión de un artefacto tiene la siguiente estructura (MM.mm.pp[-RELEASE|-SNAPSHOT]

  • MM: se refiere a “Major Vesion”
  • mm: se refiere a “Minor Version”
  • pp: se refiere al “Patch Version”
  • -RELEASE: etiqueta opcional. Si no se pone equivale a hacerlo. Identifica a un versión “Release”. Esto permite cachearla, hacerle mirror, etc...
  • -SNAPSHOT: etiqueta opcional. Sirve para indicar que el proyecto está sobre una versión inacabada, y sobre la cual su código va cambiando con el tiempo. No es estable. No se puede cachear, ni hacer mirror.


La política de asignación de versiones sigue el convenio de que un artefacto que corrige un bug y que no añade funcionalidad nueva se le asigne un nuevo “pp” superior al anterior.
Un artefacto que añade funcionalidad pero compatible hacia atrás debe aumentar su “Minor Version”.
Un artefacto que añade funcionalidad incompatible o de gran envergadura debe aumentar su “Major Version”.


Proyectos maven: que son, cómo se estructuran

Maven permite dividir el código fuente proyectos y subproyectos.
Hay, principalmente tres tipos de proyectos maven: pom, jar y war.

  • Pom: es un proyecto que define subproyectos. Con este tipo de proyecto se puede descomponer un sistema en piezas más pequeñas, favoreciendo la reutilización.
  • Jar: es un proyecto de código java. La compilación de dicho proyecto produce una librería jar que puede ser incorporada en otros proyectos java.
  • War: es un proyecto de aplicación web. La compilación produce un fichero war que sigue el estandar J2EE de aplicación web. Es en sí una pieza destinada a ejecutarse en un servidor de aplicaciones tomcat, jboss, etc...


Un proyecto maven se identifica por 3 atributos: grupo, artefacto y versión: Grupo: es una etiqueta utilizada para agrupar proyectos que guardan alguna relación. Artefacto: es una etiqueta que define el nombre de la pieza de código. Versión: una etiqueta que define la versión de una pieza de código identificada por Grupo+Artefacto.

Gestión de proyectos

  • Se utiliza Redmine para la gestión de proyectos
  • Tiene instalado un plugin para gestión de proyectos ágiles con Scrum
  • Se usa Glpi para la gestión de incidencias

Un resumen de la funcionalidad Redmine + Scrum en el siguiente enlace:


Tipos de proyectos

De las muy diversas estructuras y composiciones en las que se pueden descomponer los proyectos, en este documento se define la nomenclatura y estructura de dichos proyectos. Primero se verá a qué tipos de proyectos da cabida esta arquitectura.
Se define que los proyectos tipo “jar” van a conforma la unidad más pequeña de composición de aplicaciones. Y que los proyectos tipo “war” van a ser los que se desplieguen en servidores de aplicaciones y que serán a partir de éstos los que darán lugar a los diferentes tipos de proyectos que se contemplan.
Desde el punto de vista de la interfaz que expone están:

  • Aplicación web: tiene interfaz de usuario, y se accede a ella desde un navegador, ya sea pc, tablet o movil.
  • Servicios REST: expone esta interfaz a las aplicaciones web.
  • Servicios web (WS): expone esta interfaz internamente a la parte back de los servidores.

Atendiendo a esta clasificación dentro de un “war” se puede dar diferentes configuraciones, es por tanto que esta arquitectura sólo permite estos:

  • Aplicación web
  • Aplicacion web + Servicios REST
  • Servicios REST
  • Servicios web

NOTA: Actualmente no se contempla que nosotros desarrollemos proyectos nativos Android e Ios, pero sí su integración en nuestros sistemas. Ver apartado Securización de servicios REST.

Estructura de una aplicación web

Una aplicación web se divide en dos grandes módulos: front y back.
Si resultase que dicha aplicación se divide en dos war (uno para el front y otro para el back), el nombre del proyecto front se le añade el sufijo “lite”, en caso contrario se entiende que el fron es un único war que expone la aplicación web y los servicios REST.
El back se puede dividir a su vez en varios submódulos, a saber:

  • DAO. Que define e implementa los servicios de acceso a datos y a la lógica de negocio.
  • Restful. Que define el servicio REST y lo implementa usando la capa DAO. También se encarga de la autorización y del manejo de errores.
  • Web[-RS]. Es un proyecto “war” que contiene la configuración Spring y es el que levanta los servicios REST, que por defecto se entiende que son para ser consumidos por una aplicación web (ver securización de servicios). El sufijo “-RS” es opcional. Este tipo de módulo estára presente en un proyecto cuyo front no exponga servicios (“lite”)
  • Web-WS. Es un proyecto “war” que contiene la configuración Spring para levantar un servicio web (WS).
  • Web-OAUTH. Es un proyecto “war” que contiene la configuracion Spring para levantar los servicios REST que van a ser consumidos desde apliaciones móviles. (ver securización de servicios REST)


En ocasiones puede ser necesario subdividir estos módulos en otros, en ese caso, el módulo podrá contener submódulos en donde se deberá añadir un sufijo al nombre del artefacto para diferenciarlo del resto de submódulo.


A continuación se muestra un gráfico algunas de las diferentes alternativas de proyectos.
AlternativasProyectos.png

Estructura de un proyecto

En esta sección se muestra toda la información referida a la arquitectura y a las normas de estructuración de proyectos, en cuántas capas se descomponen los proyectos y qué contenido debe tener cada capa.


(Para documentación técnica de configuración xml consultar Media:Interfaz_de_acceso_a_capas.odt)

Principio general

Por lo general un proyecto web se divide en tres capas: presentación, dao, y datos. En esta sección se describe qué código se espera que se encuentre en cada uno de los módulos de una apliación.

Front-lite

proyecto tipo war, aplicación web, sin código java dentro del proyecto, sólo HTML, CSS y JS, librerías JS como AngularJS, Jquery, o Bootstrap. Configuración Spring básica, sin despliegue de beans, tan sólo lo necesario para la seguridad de las páginas HTML (ver securización de aplicaciones web).

Front

Proyecto tipo war, del mismo tipo de contenido que un proyecto “front-lite”, además con exposición de servicios REST, no contendrá código java, además la seguirdad para servicios REST (ver sección de seguridad servicios REST).

Back-Dao

Proyecto tipo jar, contiene para cada servicio: una interfaz, la implementación de la interfaz, un pojo y un mapper. No contendrá ficheros de configuracion en ningún caso. Para más información ver sección “capa DAO”

Back-restful

Proyecto de tipo jar, contiene la definición de los servicios REST, las rutas, los parámetros y los métodos http. Se implementa utilizando la capa DAO. Aqui se debe comprobar la autorización a cada llamada, se decide si usar un sistema de logs contra BBDD para registrar el uso del servicio, y se realiza la verificación de errores (tratamiento de excepciones). Para más información ver sección “capa REST”. Back-web, back-web-rs, back-web-oauth, back-web-ws: proyecto tipo war, sin código java dentro del proyecto, contiene únicamente la configuración Spring para el despliegue.





Hay diferentes configuraciones de estructura de proyecto, siempre desde el punto de vista de aplicación web, ésta se puede descomponer en 1 o 2 wars.

Este es un ejemplo de configuración de un proyecto en un único war:

app/app-back
app/app-back/app-back-dao
app/app-back/app-back-restful
app/app-front

Este es un ejemplo de configuración de un proyecto en dos war:

app/app-back
app/app-back/app-back-dao
app/app-back/app-back-restful

app/app-back/app-back-web
app/app-front-lite

Para el diseño de las pantallas consultar Media:Pantallas1.1.doc.

Back-dao

En el proyecto dao se define la capa de servicios y su implementacion
paquete: es.carm.app.dao
clases: para cada servicio hay que definir alguna de estas clases

  • appServiceDao: interfaz con la definición del servicio
  • appServiceDaoImpl: clase que implementa el servicio. Se puede apoyar en ibatis, y/o servicios web
  • appServiceDaoMock: clase que implementa un stub del servicio.
  • appServiceDaoMapper: interfaz ibatis con las anotaciones necesarias definiendo el mapeo con la base de datos
  • pojos: clases que implementan la información de negocio.

Back-restful

En este proyecto se define la interfaz REST
paquete: es.carm.app.service
clases: para cada servicio se define una clase appService con las anotaciones necesarias para definir el servicio REST

Nota: para más información consultar el siguiente tutorial (http://www.mkyong.com/tutorials/jax-rs-tutorials/)


Front

En este proyecto se define la aplicación web. Puede utilizarse diferentes tecnologías de front: JSF, JSP, AngularJS, etc...
Por defecto, los proyectos nuevos serán en AngularJS

Para más información visita la página que define la estructutra de un proyecto angular js (Front-AngularJS)



El front-end framework que pensamos utilizar para el aspecto visual de las aplicaciones web desarrolladas con tecnología AngularJS:

http://getbootstrap.com/

Actualmente NO se permite el uso de otros estilos que los de bootstrap.

En el caso de que alguien necesite un estilo diferente o adicional debería informar a su responsable para ver la posibilidad de incorporarlo al resto.

Únicamente se utiliza los css de bootstrap. No se debe incluir las librerias javascript.

En su caso se debe utilizar los componentes Angular-UI http://angular-ui.github.io/bootstrap/


Creacion de un proyecto nuevo

Estos son loas pasos que hay que realizar para empezar un proyecto nuevo:

1.- Desde eclipse/cliente svn descargar la utltima semilla del repositorio

2.- Desconectar el proyecto de svn

3.- Configurar proyecto: (resumen: cambiar toda aparicion de appname por el nuevo nombre de la aplicacion)

  • Cambiar el nombre del proyecto: appname->nuevo nombre
  • Cambiar estructura de directorios: appname-back, appname-back-dao, appname-back-restful, appname-front
  • Determinar el groupid, artifactid
  • Cambiar propiedades, dependencias en todos los ficheros pom.xml
  • Cambiar los ficheros de propiedades (deploy.properties y applicacion.properties) appname->nuevo nombre
  • Cambiar el fichero xxx-front/deploy/build.xml para la plataforma y groupid/version adecuado

4.- Crear proyecto en svn

  • Desde el gestor de repositorios dar de alta el nuevo proyecto.
  • Publicar el proyecto en "trunk" en el nuevo repositorio desde eclipse/cliente svn
  • OJO: hay ciertas carpetas que no se DEBEN subir a svn:

- node_modules - bower_components - target

5.- Probar el proyecto en el equipo

  • Desde una linea de comandos ejecutar:

- mvn clean install

- cd nuevoProy-front

- npm install

- grunt dev

- mvn clean install tomcat7:run

probar que funciona en localhost/p

6.- Dar de alta el proyecto en jenkins

  • Entrar a Jenkins, desde la pestaña de aplicaciones, ejecutar acción nueva tarea
  • Seleccionar el nombre de la nueva aplicación
  • Marcar la opción "copiar de" introducir el nombre de algún proyecto similar
  • Crear
  • Cambiar la descripción
  • Cambiar la ubicación de la ruta svn
  • Cambiar la configuración de sonar
  • Ejecutar la tarea. Comprobar que todo ha ido bien

7.- Comprobar que en artifactory se ha publicado la aplicación

8.- Comprobar que el despliegue con natalia funciona correctamente

  • Solicitar a Sistemas la fusión del fichero deploy.properties de la aplicación con el de servidor
  • Desde NATALIA, dar de alta una nueva solicitud de trasapaso
  • Introducir el nombre de la aplicacion
  • Introducir la ruta svn del direcotrio donde está el build.xml
  • Grabar la solicitud
  • Desde el menu realizar traspaso ejecutar y comprobar que:

- Se descarga el war desde artifactory al servidor destino

- Se mueve el fichero a la carpeta webapps del servidor destino

- La salida del log es correcta al menos en el despliegue

Dar de alta un proyecto en Jenkins

URL del Servidor Jenkins: https://jenkins.murciaeduca.es/jenkins/


Tras iniciar sesión con las credenciales, se tendrá acceso al panel principal, ubicado arriba a la izquierda, con las principales acciones disponibles para realizar.


Accedemos a la opción primera ("Nueva Tarea"), de este modo nos aparecerá la primera página de configuración de la nueva tarea en la que tendremos que indicar el nombre de la misma. Respecto al tipo de proyecto, seleccionamos "Copiar una Tarea existente" y apuntamos como tarea de referencia "eduwsV2"; depués pulsamos OK.


La siguiente página nos muestra la configuración de la nueva tarea, ya copiada de nuestra tarea de referencia indicada en el paso anterior. Tan solo hará falta cambiar la ruta del repositorio Subversion, para lo cual deberemos acceder al RPS (https://rps.murciaeduca.es/scm/) y copiar la URL del proyecto el cual estamos agregando como nueva tarea en Jenkins (en caso de ser un proyecto dentro de otro mayor se deberá copiar la ruta completa hasta el proyecto en cuestión).


Si la Nueva Tarea se corresponde con un proyecto Maven con un front, habrá que añadir como paso previo a la compilación unas líneas de comando que deberá ejecutar de forma automática Jenkins, para lo cual en la misma pantalla de configuración habrá que buscar el apartado "Pasos previos". Ya localizado el apartado correspondiente (justo antes de Proyecto, Pasos posteriores, Propiedades del proyecto y Acciones para ejecutar después), pulsamos el botón "Añadir un paso previo" y seleccionamos entre las opciones que se despliegan "Ejecutar línea de comandos (shell)". En la nueva sección que aparecerá, se deberá copiar el texto siguiente:


cd NOMBREPROYECTO-front
npm install
grunt

IMPORTANTE: NOMBREPROYECTO se deberá sustituir por el nombre del proyecto Maven en el que está incluido el front.


Una vez realizado este cambio, podremos darle a Guardar, ubicado siempre en la parte inferior de la pantalla, y nos redirigirá al a la página del proyecto. En ella tendremos el panel de opciones arriba a la izquierda con las opciones siguientes:


Volver al Panel de Control - Regresa al panel principal de Jenkins.

Estado Actual - Pantalla principal de la Tarea en Jenkins.

Cambios

Zona de Trabajo

Construir Ahora - Compila el proyecto. De estar ocupado el sistema compilando otros proyectos se añadirá a la cola.

Borrar Maven project

Configurar - Pantalla de configuración de la Tarea, en donde podemos modificar la configuración dada inicialmente durante el proceso de creación de la Nueva Tarea.

Módulos

Subversion Log de consultas



Configurar Artifactory en una Tarea de Jenkins

En configuración de la Tarea de Jenkins (ya sea una tarea creada con anterioridad o una nueva que hayamos creado siguiendo los pasos del anterior apartado), al final nos da la opción de añadir una acción para ejecutar después de compilar el proyecto. Pulsamos sobre el botón "Añadir una acción" y, dentro de las opciones que se despliegan desde el mismo, escogemos "Deploy artifacs to Artifactory".


Una vez introducida la acción posterior al compilado, aparecerá la configuración del artifactory para la tarea en cuestión. La primera opción es la URL del servidor (la cual no hay que modificar) y seguidamente los repositorios de RELEASES y SNAPSHOTS contra los que deberá ir la Tarea de Jenkins en cada compilación. Para obtener las listas de repositorios disponibles, pulsamos el botón "Refresh" justo debajo de dichas opciones (cuando termine saldrá con letras verdes "Items refreshed successfully" justo debajo de las opciones y a la misma altura que el botón Refresh), una vez obtenidos los repositorios del servidor Artifactory seleccionamos de la siguiente manera:


Target releases repository - libs-release-local
Target snapshots repository -  libs-snapshots-local


Una vez realizados los cambios, podemos darle a Guardar y compilar el proyecto en Jenkins.


Configurar Sonar en una Tarea de Jenkins

En el panel de configuración de la Tarea de Jenkins, pulsamos la opción "Añadir un paso posterior" y seleccionamos de las opciones de sedespliegan "Invoke Standalone Sonar Analysis".


Una vez desplegado el panel de configuración de Sonar dentro de nuestro proyecto en Jenkins debemos configurarlo con, al menos, los siguientes parámetros:


  • sonar.projectKeysonar.projectName, los cuales serán el nombre de nuestra Tarea de Jenkins
  • sonar.projectVersion, la versión del proyecto (0.0.1, 1.0.0, etc)
  • sonar.sources, la ruta hacia la carpeta con el código fuente del proyecto


Si el proyecto se divide en varios subproyectos (back-dao, back-restful, front u otros) se deberá tomar una de las siguientes configuraciones para la correcta toma de código por parte de Sonarqube:


Opción A) Eliminar de la configuración la opción sonar.sources y, en su lugar, cada uno de los subproyectos se introducirán en la configuración de Sonar como módulos con la siguiente configuración:


sonar.modules=NOMBREPROYECTO-back-dao, NOMBREPROYECTO-back-restful, NOMBREPROYECTO-front


NOMBREPROYECTO-back-dao.sonar.projectName=NOMBREPROYECTO-back-dao
NOMBREPROYECTO-back-dao.sonar.sources=NOMBREPROYECTO-back/NOMBREPROYECTO-back-dao/src
NOMBREPROYECTO-back-dao.sonar.projectBaseDir=.


NOMBREPROYECTO-back-restful.sonar.projectName=NOMBREPROYECTO-back-restful
NOMBREPROYECTO-back-restful.sonar.sources=NOMBREPROYECTO-back/NOMBREPROYECTO-back-restful/src
NOMBREPROYECTO-back-restful.sonar.projectBaseDir=.


NOMBREPROYECTO-front.sonar.projectName=NOMBREPROYECTO-front
NOMBREPROYECTO-front.sonar.sources=NOMBREPROYECTO-front/src
NOMBREPROYECTO-front.sonar.projectBaseDir=.


Opción B) En la opción sonar.sources, incluir las rutas hacia todos los directorios src de los diferentes subproyectos separados entre si por comas. El resultado debería ser algo parecido a esto:


sonar.sources=NOMBREPROYECTO-back/NOMBREPROYECTO-back-dao/src, NOMBREPROYECTO-back/NOMBREPROYECTO-back-restful/src, NOMBREPROYECTO-front/src


IMPORTANTE

  • NOMBREPROYECTO se deberá sustituir por el nombre del proyecto introducido en jenkins (en caso de no coincidir el nombre de la carpeta con el de la Tarea de Jenkins, utilizar el nombre de la carpeta).
  • En la opción sonar.modules se deberán introducir todos y cada uno de los módulos a introducir en la configuración de Sonar, cualquier módulo que no se incluya en dicha línea se omitirá durante la ejecución de Sonar.


Una vez realizados los cambios, podemos darle a Guardar y compilar el proyecto en Jenkins.

Servicios desplegados por defecto en la semilla

ControlService: url app/services/controlservice/Autorizacion/ID_APP_CONTROLAPLIC