DOCUMENTO DE ESTANDARES DE

AUTOATENCIÓN V1.0
Documentación para tener los lineamientos generales que se debe seguir en el desarrollo de aplicaciones y
es la base para la creación de componentes(servicios por dominio) y la comunicación de las mismas de forma
asíncrona y síncrona en la infraestructura azure cloud.

Diseño de Arquitectura de Software Selfcare

"La organización fundamental de un sistema compuesta por sus componentes, las relaciones entre ellos y
su entorno, así como los principios que gobiernan su diseño y evolución" (ISO/IEC 42010)

Como parte fundamental de las aplicaciones bancarias en la nube es importante tener un diseño simple,
seguro y entendible de la arquitectura y las interacciones entre los componentes que lo integran con el fin de
cumplir con los objetivos de negocio.
Componentes de la arquitectura cloud

AZURE CLOUD
En esta se sección definimos los componentes azure que usamos y las respectivas nomenclaturas que se
deben de seguir como buenas practicas.

Resource Group: La nomenclatura sigue la estructura <region_numero><nombre_crew><nombre_app>

<ambiente_app><numero_recurso> Ejemplo: (EU1_AADI_AAA_DEV_01)

Resource: La nomenclatura es siempre 3 letras iniciales <nombre_resource><nombre_crew><ambiente_app>

<nombre_recurso><numero_instancia> Ejemplo: (acreaddidevbus01)

Api Management Interno: Exposición de las api’s https de selfcare, cuyo objetivo de esta APIM es
comunicación entre claster o la red interna del banco.

Azure Key Vault: Almacén de certificados TLS 1.2, keys y secretos de la aplicación. Así mismos
gestionará el acceso a los recursos.

AKS: Contenedor de 3 nodos worker para despliegue de los servicios ligeros y configuración de secrets.

Azure Container Registry: Gestor de imágenes de los servicios.

Azure Redis Cache: Almacenamiento temporal y de gran velocidad como son tablas tipo o catálogo,
datos de seguridad.

Azure Service Bus: Tópicos de mensajería asíncrona para coumunicación de servicio ligero y tareas que
no requieran confirmación secuencial del proceso.

Azure Storage : almacenamiento cargas masivas e imágenes para el uso de la aplicación, volumes para
los servicios, es obligatorio si se guarda datos sensibles deben cifrarse en reposo (HSM).

Azure Scheduler: Scheduler funciona aunque se produzcan errores en la red, los equipos o el centro de
datos, por lo que los trabajos programados continúan ejecutándose puntualmente. Si es necesario,
cambia automáticamente a un centro de datos alternativo en la misma región.

OTHER CLOUDS
New Relic: Monitoreo y AMP de la infraestructura azure y de la aplicación backend y frontend.

Bitbucket: Remote Config, centralización, autorefresco, versionado de las configuraciones.

ONPREMISE
Api Connect: Es el punto donde se disponibiliza la api para que los canales se suscriban y puedan hacer
uso de ello.

Bus de Servicios: Servicios de interbank onPremise

Aplicaciones Interbank: Aplicaciones core del banco

HSM: Máquina para generación de llave mediante tres tarjetas y tres custodios

Patrones de Diseño
Los patrones de diseño deben de usarse en la capa de lógica de negocio de forma obligatoria según apliquen
y solo en casos excepcionales y justificados no se usaran.

Patrones creacionales
Abstract Factory

[modif.visibilidad] interface nombreInterfaz [extends listaInterfaces]

        {
            prototipo método1;  
        }
//Ejemplo
abstract class Creator{
   // Definimos método abstracto
   public abstract Product factoryMethod()
}

Factory Method: Una buena práctica es que la implementación del método no debe superar los 30
líneas de código, si sucede se debe dividir en otros métodos más pequeños..

[modif.visibilidad] interface nombreInterfaz [extends listaInterfaces]

        {
            prototipo ConcreteProduct;  
        }
//Ejemplo
public class ConcreteCreator extends Creator{
   public Product factoryMethod() {
       return new ConcreteProduct();
  }
}

Builder
Prototype

//Anotaciones @Autowired, @Service, @Repository, @Component

@Autowired
[modif.visibilidad]  nombreInterfaz;
//Trabajando con beans
@Bean
modif.visibilidad] ServicioTareas2 tareas(){    
}

Patrones estructurales
Adapter
Bridge
Decorator: @Qualifiers, @Service("nameService), @Repository("nameRepository).
Facade
Proxy
Patrones de comportamiento
Command: Una buena práctica es que los métodos no deben recibir más de tres parámetros si sucede
este escenario encapsular en un objeto.
Chain of responsibility
Mediator
Observer
State
Visitor

Definición y diseño de Servicios por Dominio

Los Servicios ligeros es un estándar de trabajo de la industria de software cuya definición y granularidad es a
nivel de dominio. (Más información aquí)

Cada servicio ligero que se crea debe tener un nombre que siga la siguiente estructura:

selfcare-<domain_name>

domain_name: Los dominios de sistema que se maneja en Selfcare son:

ConfigServer
DiscoveryServer
EdgeServer

domain_name: Los dominios de negocio que se manejan en selfcare son:

TemporaryLock
CardBlock

domain_name: Los servicios externos que maneja en selfcare son:

Bitbucket
Estructura arquitectónica de un Servicio pot
Dominio
Para la construcción de los servicios se usara como estándar el framework Spring Boot cuya clase principal es
el único punto de arranque o ejecución del servicio.

@SpringBootApplication
public class <dominio-miniservicio>Application {

   public static void main(String[] args) {

       SpringApplication.run(<dominio-miniservicio>Application.class, args);
  }
}

Versiones de SpringBoot
Para la construcción de las aplicaciones se usarán las siguientes librerías y las siguientes versiones de
springboot.
 spring-boot-2.1.0.RELEASE
spring-boot-starter-actuator-2.1.0.RELEASE
spring-cloud-starter-config-2.1.0.M1
spring-boot-starter-test-2.1.0.RELEASE
spring-boot-starter-web-2.1.0.RELEASE
spring-cloud-starter-netflix-eureka-client-2.1.0.M1
spring-cloud-starter-netflix-eureka-server-2.1.0.M1
spring-cloud-config-server-2.1.0.M1
spring-cloud-starter-netflix-zuul-2.1.0.M1
spring-boot-starter-data-redis-2.1.0.RELEASE
spring-boot-starter-webflux-2.1.0.RELEASE
spring-boot-devtools-2.1.0.RELEASE
spring-boot-starter-security-2.1.0.RELEASE
spring-security-oauth2-autoconfigure-2.0.0.RELEASE
spring-security-jwt-1.0.5.RELEASE
spring-restdocs-mockmvc-1.0.5.RELEASE

Librerías externas compatibles al framework SpringBoot

lombok-1.18.4
mongo-java-driver-3.8.2
gson-2.8.2
commons-cli-1.4
jackson-databind-2.9.7
azure-keyvault-1.1.2
httpcore-4.4.10
commons-lang3-3.8.1
rest-assured-2.1.0.RELEASE
adal4j-1.6.3
azure-keyvault-1.1.2

NOTA: Cualquier librería adicional al estándar que se requiera usar debe ser coordinado y actualizado
en este documento.

Estructura de los proyectos

La estructura de paquetes de cada proyecto será de la siguiente forma:

selfcare-<domain_name>

selfcare-<domain_name>-app
src/main/java

...
src/main/resources
application.yml
bootstrap.yml
src/main/test

...
pom.xml
 Dockerfile

selfcare-<domain_name>.yml
selfcare-<domain_name>-repo

pom.xml
selfcare-<domain_name>-core
pom.xml
selfcare-<domain_name>-esb

pom.xml
selfcare-<domain_name>-mocks
pom.xml
pom.xml

Los componentes cros que seran usados por los servicio ligero tendran la sigiente estructura:

selfcare-<domain_cross_name>
selfcare-<domain_cross_name>-commons

src/main/java
...
src/main/resources

application.yml
src/main/test
...
pom.xml

pom.xml

selfcare-<domain_name>: En este proyecto se define el parent, la arquitectura, las versiones de framework y

los módulos del el servicio ligero, para cuyo objetivo se usa Maven 3.5.3 o superior como estándar

...
   <modules>
       <module>selfcare-<domain_name>-app</module>
       <module>selfcare-<domain_name>-core</module>
       <module>selfcare-<domain_name>-esb</module>
       <module>selfcare-<domain_name>-repo</module>
       <module>selfcare-<domain_name>-moks</module>
   </modules>
...

selfcare-<domain_name>-app: Módulo principal y único del servicio, este será empaquetado e instalado en
los contenedores y para cuyo objetivo se usara los archivos de Dockerfile y selfcare-<domain_name>.yml

Y los paquetes tienen la siguiente estructura

src/main/java: En esta sección se tienen los paquetes del servicio dentro del grupoId definido en el
maven [pe.interbank.selfcare].

main.test: En esta carpeta se tiene las pruebas unitarias que se usaran en TDD.
 main.resources: En la carpeta resources tiene dos archivos de configuración: application.yml y
bootstrap.yml

Este componente también contiene la interfaz y la implementación de la lógica de negocio.

//Clase service interfaz

public interface <class_name>Service throws <custom_execption> {    
   public <return_object> <name_method>(<class_parameter> objClassParameter) ;
}
//Clase service implements
@Service
public class <class_name>ServiceImpl  implements <class_name>Service {    
   @Override
   public <return_object> <name_method>(<class_parameter> objClassParameter) {
      ...
  }
}

Los paquetes tendrán la siguiente nomenclatura: pe.interbank.selfcare.<domain_name> y dentro de ellos se

organiza de la siguiente manera.

...
   - controller
       - web //todo api se expone con el prefijo [api -> segurizados con oauth2, pub ->
públicas u otros formatos de segurización]
   - config //Configuraciones adicionales de miniservicio decorados con @Component
   - service //Interfaz de la lógica de negocio
       - impl //Implementación de la lógica de negocio.
   - dto
       - request //contrato de ingreso al miniservicio
       - response //contrato de respuesta del miniservicio  
  ...
...

selfcare-<domain_name>-repo: El componente que se integra con la base de datos o la fuente de datos.

//Conexión a base de datos

@Configuration
public class MongoDbConfiguration {
   @Bean
   public MongoClient mongoClient() throws <Custom_Exception> {
      ...
  }
}
//Clase repository
@Repository
public class <class_name>Repository extends CrudRepository<<class_Name>, <id_type>> {    
   public <return_object> <name_method>(<class_parameter> objClassParameter) ;
}

selfcare-<domain_name>-core: El componente que contiene los java beans, DTOs, Enums, clases utilitarias.
selfcare-<domain_name>-esb: El componente que se encarga de la integración entre servicio ligero o de un
servicio con algún otro componente para la gestión de tareas asíncronas mediante el patrón de publicación y
suscripción haciendo uso de los tópicos.

Es importante tener en consideración:

Publicación de mensajes
Suscripción a los mensajes
Reintento para procesar mensaje
Tópico de mensajes no procesados

selfcare-<domain_name>-mocks: El componente que carga y gestionar los mocks para la integracion de un

servicio.

selfcare-<domain_cross_name>-lib: El componente cros será usada por todos los servicio ligero que lo
requieran.

Clases, objetos, métodos, variables,

comentarios y excepciones
Clase: las clases en inglés con las primeras letras en mayúscula si es compuesto juntos sin espacio con los
iniciales en mayúscula. Este es un ejemplo de clase:

//Clase simple
public class Credit {..}

//Clase compuesta
public class CreditCustomer {..}

Objeto: Los objetos en ingles, siempre la primera letra en minuscula y si son compuesto los siguientes
nombres con los iniciales en mayúscula sin espacio. Este es un ejemplo de objeto:

//Objeto simple
Credit credit = new Credit(<parameters>);

//Objeto compuesto
Credit creditPerson = new Credit(<parameters>);

En lo sumo usar los principios de herencia, agregación y composición de acuerdo al escenario que aplique
el negocio.

Método: Los métodos son conjunto de instrucciones definidas para lograr un objetivo tanto de negocio o
sistema y estas deben seguir los siguientes lineamientos:

Los nombres de los métodos en inglés y deben representar la funcionalidad implementada.

Los métodos deben iniciar en minúscula y si son compuesto los iniciales en mayúscula.
Los parámetros de los métodos no deben exceder más de tres atributos o parámetros y se requiere más
parámetros se debe crear un objeto que contenga como atributos a esos parámetros.
La implementación de los métodos no debe superar los 30 líneas de instrucción si se presenta este
escenario refactorizar en métodos propios.
 Tener en consideración dentro de un método se recomienda usar no más de 4 ciclos iterativos (for,
while, do whle) y 8 condicionales anidadas (if-else, case), si se tiene este escenario refactorizar en
métodos propios.

Este es un ejemplo de método:

public void getCredit(String idCredit) {..}

Atributo: Las variables en inglés y deben iniciar en minúscula, si son compuesto los iniciales después de la
primera palabra en mayúscula. Este es un ejemplo de atributo:

Los atributos compuestos[Objeto] deben iniciar con obj<nombre_objeto>.

La capa service debe tener como retorno siempre objetos TO, Response ya en estos se definen el
contrato final de la api. Nunca se debe retornar modelos distintos a estos objetos.
Para los Get, Set, toString se hará uso de lombok y tener las clases con los atributos limpios y más fáciles
de implementar. Para dicho propósito se usara las anotaciones @Data si se requiere (Get, Set,
ToString), y casos específicos usaremos de forma explicita @Get, @Set y @ToString.

private String idCredit;

Comentario: los comentarios se deben realizar en idioma inglés, claro y siempre explicar el objetivo que
tiene la clase o método. Este es un ejemplo de clase:

- comentario simple de una línea:

//This method get the credit by id
public void getCredit(String idCredit) {..}
- comentario detallado de varias líneas:
/**
* <Coments>
*@author <developer_name> <<developer_email>>
*@fecha 04/14/04
*/
public class Credit {..}

Excepciones java: Las excepciones en java deben ser customizadas por cada capa, modulo y clase funcional,
no se debe usar excepciones por defecto generadas por JVM.

Errores genéricos:
Errores personalizados por miniservicio

Estándar para el registro trace,logs y

auditoria
Iniciar sesión en New Relic, luego desde el menú desplegable de la cuenta, seleccionar “configuración de
la cuenta” y dentro de la seccion “APM” seleccionar el agente que corresponde a Java.
Abrir el archivo .pom del servicio ligero e incluir lo indicado en las siguientes líneas, donde:

En la primera línea se indica el nombre del App el cual debe ser igual al indicado en el archivo
newrelic.yml; propiedad: app_name.
 El primer plugin indicado permite descomprir el contenido del agente de new relic: newrelic-agent-
4.8.0.jar, tener en consideración que se debe descargar la ultima versión del agente.
El segundo plugin indicado se indican configuraciones generales del agente de new Relic.
El tercer plugin, se debe indicar para indicar la clase principal Main que debe ejecutarse ya que el
agente New Relic también cuenta con una clase con método main. Para ello se debe colocar la
paqueteria en donde se encuentra la clase principal del miniservicio en el tag: < mainClass>
Como último paso se debe agregar la dependencia del agente indicando su ultima versión.
Luego de realizado los cambios en el archivo .pom del miniservicio, se debe realizar la compilación del
mismo.

Finalmente para poder ejecutar el minisercicio desde la máquina local se debe agregar en la sección VM
los siguientes parámetros:
-javaagent:Ruta completa donde se encuentra ubicado el archivo: newrelic.jar
-Dnewrelic.config.file=Ruta completa donde se encuentra ubicado el archivo:newrelic.yml; tener en
consideración que éste archivo debe encontrarse en la misma ruta en donde se ubica el agente de
new relic(newrelic.jar).
-Dnewrelic.environment=<profile> ejemplo:(-Dnewrelic.environment=DEV); ambiente de ejecución
de New Relic.

<!--
<name>Name Miniservicio</name>: Debe coincidir con lo indicado en el archivo newrelic.yml
-->
<build>
   <plugins>
       <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-dependency-plugin</artifactId>
           <executions>
               <execution>
                   <phase>prepare-package</phase>
                   <goals>
                       <goal>unpack-dependencies</goal>
                   </goals>
                   <configuration>
                       <includeArtifactIds>newrelic-agent</includeArtifactIds>
                       <outputDirectory>${project.build.outputDirectory}</outputDirectory>
                   </configuration>
               </execution>
           </executions>
       </plugin>
       <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-jar-plugin</artifactId>
           <configuration>
               <archive>
                   <manifestEntries>
                       <Premain-Class>com.newrelic.bootstrap.BootstrapAgent</Premain-
Class>
                       <Can-Redefine-Classes>true</Can-Redefine-Classes>
                       <Can-Retransform-Classes>true</Can-Retransform-Classes>
                   </manifestEntries>
               </archive>
            </configuration>
       </plugin>
       <plugin>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-maven-plugin</artifactId>
           <configuration>
               <mainClass>pe.interbank.selfcare.[domain].[Domain]Application</mainClass>
           </configuration>
       </plugin>
   </plugins>
</build>
<dependency>
   <groupiId>com.newrelic.agent.java</groupId>
   <artifactId>newrelic-agent</artifactId>
   <version>${newrelic-version}</version>
   <scope>provided</scope>
</dependency>

Archivo de configuración newrelic.yml

 #Propiedad Descripción

Modificar este dato con el valor obtenido de la página de new Relic después de haberse
license_key
logeado con su cuenta.

Indicar el nombre del(os) miniservicio(s) indicado en el pom tag separados por (;) en el
app_name
caso de requerirse realizar el monitoreo de más de un miniservicio.

Auditoria Customizada: para dicho objetivo usara la instancia de new relic

NewRelic.addCustomParameter(“Request”,VALOR_DEL_REQUEST). VALOR_DEL_REQUEST: este valor no
debe guardar datos sensibles y si fuese necesario ofuscados o su alias correspondiente.

En new relic no se deben guardar datos sensibles de Resquest y Response para este objetivo se usara una
colección en DynamoDB.

PROCESO DE CONFIGURACIÓN CENTRALIZADA

Para la configuración de los servicios ligeros se realiza mediante el server config y el repositorio bitbucket,
persionado para los distintos ambientes (SGT,DEV,UAT,PRD)

El nombre debe comenzar con el nombre de la aplicación tal como se declara en el servicio
correspondiente. Por ejemplo: - spring.application.name = blockcard
Si hay diferentes perfiles, el nombre del perfil debe aparecer después del nombre de la aplicación. Por
ejemplo: - blockcard-uat.yml, blockcard-dev.yml ( o .yml )

GET / {application}/{profile}[/{label}]

Evento @RefreshScope y "/actuator/refresh"

De forma predeterminada, los valores de configuración se leen en el inicio del cliente , y no nuevamente.
Puede forzar a un bean a actualizar su configuración (para extraer los valores actualizados del servidor de
configuración ) anotando el WelcomeController con el Spring Cloud Config @RefreshScope y luego activando
un evento /actuator/refresh .
Versionado en las URLs
Se recomienda la utilización del versionado en las URLs de los servicios utilizando solo la versión major:
Actualmente un servicio del Bus se encuentra así:

https://10.11.40.25:5020/ibk/sit/api/account/v1/accountid

https://ibbus:443/ibk/srv/MPO/Captaciones/cuenta.anular/v1.0

Estándar de contrato y estructura de

mensajes
La práctica estandarizada para manejar las versiones se basa en el versionamiento semántico.

Los paths deben estar en minúscula y sin guiones.

Recomendaciones
Análisis: Analizar la entrada y salida del proveedor, sea de mainframe, o de un distribuido, debido a que
por su antigüedad manejaban interfaces muy genéricas y se podían disgregar en varias actividades.
Futuro: Que no piensen en lo actual, que se mira a futuro sobre las otras cosas que puedan venir o que
puedan agregar.
Realizar las preguntas necesarias: para salir de toda duda antes de realizar una definición de negocio.

Prácticas de Versionado para Servicios Cloud y Librerías

La política de versionado que se DEBE utilizar para Servicios Cloud (o contenerizados) es adoptar el
versionamiento semántico, esto se aplica de la forma X.Y.Z.

Preparación de un Release
Para empezar a desarrollar y seguir las políticas de versionado semántico, se debe tener en cuenta si el
desarrollo es nuevo o pertence a la iniciativa de modificar un release existente.

Si es un desarrollo nuevo
1. Al iniciar un desarrollo nuevo, debe empezar con la versión 0.1.0-SNAPSHOT.
2. A medida que se agreguen nuevas funcionalidades se debe incrementar la versión minor de esta
versión.
3. Cuando el desarrollo sea promovido a ambientes previos, el desarrollo de la librería o servicio debe
colocarse el en 1.0.0-RC1, este sufijo significa Release Candidate 1. Luego de esto están prohibos agregar
nuevas funcionalidades o cambios en el contrato que agreguen una incompatibilidad.
4. Cada iteración de corrección de bugs o fixes de este release debe agregarse como un nuevo número de
este Release Candidate. Ejemplo: Pasar de 1.0.0-RC1 a 1.0.0-RC2.
5. Cuando se despliegue a producción este activo, el release definitivo debe pasar a 1.0.0.
Seguridad en URIs publicas:
Cuando se invoquen URIs que no necesitan token de acceso, se debe generar una autenticacion basica
conformado por los atributos clientId y accessKey. Por ejemplo:

Client ID: abcdef

Secret key: wxyz

El atributo en el header debe estar formado por ambos atributos concatenados en base 64. Por ejemplo:
Authorization: Basic TWF2ZXJpY2tDbGllbnRJZEFwcDpNYXZlcmlja0NsaWVudElkQXBwMTIz

Seguridad en URIs para la Configuracion Remota:

Cuando se invoquen URIs para obtener las configuraciones remotas, se debe generar una autenticación
basada en SHA-256 de la firma. Por ejemplo:
Autorización: SHA 53b25741f5037f0efa31038b364a36aba54dc9860b1afd6a7033e738af008ec1

Request:
El nombre de los request debe tener como sufijo la palabra "Request", por ejemplo: SimulationRequest,
CampaignRequest, etc.
Todos los request deben estar acompañados de su token de sesion en el Header.
Cuando se envié en la url un id, se debe realizar una verificación, validando que dicho id coincida con el id
enviado en el token de sesion
El nombre de los Keys de los request debe tener nombres en inglés y sin abreviaturas.
Los nombres de los Keys deben empezar con minúscula y cada nueva palabra debe empezar con mayúsculas
sin espacios ni guiones (_).

Para realizar el tracking de los mensajes, se creará un componente intercepto el cual agregará un atributo X-
OPERATION-TRACE-ID en el header del request, dicho valor será recuperado al momento de generar el
response y devuelto en el header del response.

Cuando se define un servicio rest en la capa Controller en java se debe tener en cuenta si se mandan como
parámetro una variable o un objeto.
En caso enviar variables como atributos se debe usar la anotación @PathVariable. Por ejemplo:

@PostMapping("/employees/{id}")
   Employee one(@PathVariable Long id) {
       return repository.findById(id).orElseThrow(() -> new
EmployeeNotFoundException(id));
  }

En caso enviar objetos como atributos se debe usar la anotacion @RequestBody. Por ejemplo:

@PostMapping("/employees")
   Employee newEmployee(@RequestBody Employee newEmployee) {
       return repository.save(newEmployee);
  }

En caso se necesite pasar como parametro una variable y un objeto, se puede usar ambas anotaciones.
Response:
El nombre de los response debe tener como sufijo la palabra "Response", por ejemplo: SimulationResponse,
CampaignResponse, etc.

La estructura del response debe contener algunos atributos relacionados con el status del mensaje
Estructura del mensaje:

{
   
   card : {
       data1: 'data1',
       data2:  data2,
       data3: {[]},
       data4: {}          
  }
}

{
"code" : 10240,
"message" : "Validation Failed",
"errors" : [
{
"code" : 5432,
"message" : "First name cannot have fancy characters"
},
{
"code" : 5622,
"sub_system" : "Service-A",
"message" : "Password cannot be blank"
}
],
"additional_info" : [
// Pares de claves/valor arbitrarios. Se aceptan: boolean, int, double,
...
]
}

Códigos de Estado HTTP

 Código Nombre Descripción

Respuesta a un GET, PUT, PATCH o DELETE exitoso. También se puede

200 OK
utilizar para un POST que no da lugar a una creación.

Indica que el recurso fue creado. Útil para respuestas POST

201 Created
que realizan una creación.

Respuesta a una solicitud exitosa que no devolverá un cuerpo

204 No Content
(como una solicitud DELETE).

El recurso solicitado se le ha asignado un nuevo URI

Moved
301 permanente y cualquier referencia futura a este recurso
Permanently
DEBERÍA usar uno de los URI devueltos.

Utilizada para errores de validación en los parámetros de la

304 Bad Request
petición.

Cuando no se proporcionan detalles de autenticación o

ninguno es válido. También es útil para activar una ventana
401 Unauthorized
emergente de autenticación si la API se utiliza desde un
navegador.

Cuando la autenticación se realizó correctamente, el usuario

403 Forbidden
autenticado no tiene acceso al recurso por permisología.

404 Not Found Cuando se solicita un recurso no existente.

Internal El servidor encontró una condición inesperada que le impidió

500 Server cumplir con la petición. Idea para errores generales del
Error servidor.

... ... ...

Estándar de commits
Lineamientos para los commits
La gestión de los commits es sumamente importante el cual deben seguir los siguientes lineamientos.

Formato de los commits debe seguir la siguiente estructura:

-<tipo>(<alcance>): <asunto>
[LINEA EN BLANCO]
<descripción>
[LINEA EN BLANCO]
<pie_detalle>

Asunto
 Una descripción breve del cambio.
Oraciones en presente imperativo: “agrega. . . ” y no “agregado” ni “agregar”.
No poner la primera letra en mayúscula.
No poner punto “.” final.

Tipos

feat: Añade una feature.

fix: Corrige un bug.
docs: Añade documentación.
style: Estilo de codificación como el linter.refactor
test: Para añadir unit-test que se olvidaron.
build: Mantenimiento de scripts de construcción o configuración.

Alcance

Debe ser el lugar donde se aplique directamente el cambio. Por ejemplo

“pe.interbank.maverick.identityserver.security.Custom”

Descripción

Es opcional.
Elabora la idea del cambio y hace un contraste con el comportamiento anterior.

Ejemplos

feat(pe.interbank.maverick.identityserver.security.CustomJDBC):
fix(pe.interbank.maverick.identityserver.security.CustomJWT): lint CustomJWT .
fix(pe.interbank.maverick.identityserver.security.CustomJWT): remove unnecessary method.
build(pe.interbank.maverick): exec clean after bundle
fix(pe.interbank.maverick.identityserver.security.CustomJWT): remove whitespaces.
feat(pe.interbank.maverick.identityserver.security.CustomJWT): create * favorite alias validator.

Gestión de las ramas de desarrollo

Lineamientos para la gestión de las ramas de desarrollo

Se creara el branch [dev], para todo el proyecto a partir del la rama principal [master].
Durante el ciclo de desarrollo del sprint deberá existir una rama de git por feature y resposnable de la
historia de usuario.
El responsable de las rama [dev] serán los líderes del developer team.
Los desarrolladores que trabajen en determinada feature crearán ramas de tareas a partir de la rama
[dev].
Las ramas de tareas se basarán en el tasking hecho por el equipo y contendrán el código que cumple
con dicha tarea.
El nombre de las ramas de tareas seguirán el formato <nombre_de_app>-<numero_sprit>-
<numero_hitoria_usuario><nombre_de_feature>-<nombre_de_tarea>.
Ninguna otra persona distinta al líder técnico del team hará commits a la rama [dev].
Las rama [dev] recibirán cambios mediante pull-requests desde las ramas de tareas.
Cada uno de los pull-requests anteriores deberán tener la aprobación de un miembro del team el líder o
arquitectura antes de aceptarse.
 El líder técnico deberá hacer los merges siempre de tipo de NO fast-forward.
Después aceptar un pull-request, el líder técnico borrará la rama de tarea.
Cuando la rama [dev] estén listas para integración, el líder técnico creará un tag con el
“<nombre_de_feature>-v” antes de enviar la rama de [master], donde “v<N.>” es la versión del feature,
por ejemplo, “v1”, “v2”, etc.
El valor de “N” de los [tags] irá incrementándose tantas veces como se envíe la rama [dev] a [master].

Pase a producción
Crear un [tag] para cada proyecto a subir con el formato: <nombre_app>-v<N.N.N>
Para el caso de front el tag debe tener el siguiente formato: <nombre_app>-v<N.N.N>-bk<N.N.N> para
poder asociar un front con una version especifica de backend.

Desarrollo basado en TDD

Todo componente que cuente con lógica de negocio debe ser desarrollado usando TDD para ello se debe
considerar lo detallado en los siguientes puntos:

1.- Requisitos para la implementación de TDD:

 Consideración Descripción

Contar con la(s) historias definidas (s) y sus respectivos criterios de aceptación
1
definidos por el PO en base a lo indicado en el item: "Definición de features".

Contar con los criterios de aceptación definidos por el PO en base a lo indicado en el

2
item: "Definición de Criterios de aceptación".

Contar con los casos de prueba funcionales, rendimiento (en caso aplique), seguridad
3
(en caso aplique) en base a lo indicado en el item: "Definición de casos de prueba".

El equipo de desarrollo debe realizar la implementación de los test unitarios en base

4
a lo indicado en el item: "Definición de los test unitarios"

2.- Lineamientos para la implementación de TDD

Definición de features(historias de usuario):

Las features deben probar partes o funcionalidades de una App(aplicación) y no la App completa.

Escribir una narrativa(en una frase) del feature indicando lo que ésta hace o de lo que trata, es
decir; la narrativa debe indicar que es lo que se va a implementar en esa feature.
Si un feature es muy grande; en el refinamiento se deberá dividirla en historias mas pequeñas.

Escribir las features utilizando el formato(en español) “COMO…QUIERO…PARA…” por ejemplo:

NOMBRE: Hacer check-in online.
COMO cliente con una reserva ya pagada.
QUIERO poder hacer el check-in online.
PARA poder acceder a mi vuelo sin problemas.

Definición de Criterios de aceptación(CAs):

El Cas debe describir siempre un contexto, un evento y la respuesta o consecuencia esperada del
sistema.
Se propone describir los criterios de aceptación usando Gherkin GWT (GIVEN-WHEN-THEN/DADO-
CUANDO-ENTONCES) ya que es la forma mas utilizada para realizar ésta tarea.
Given(DADO): Colocar las condiciones(pasado) previas a la ejecución de la prueba.
When(CUANDO): Colocar la descripción(presente) del evento o acción.
Then(THEN): Colocar la descripción (en futuro) del resultado esperado.
Ejemplo:
ESCENARIO 1: el nombre del cliente es obligatorio en el check-in
DADO un cliente en la ventana de check-in online
CUANDO deja el campo de nombre en blanco Y pulsa el botón de confirmación
ENTONCES se muestra un mensaje de error indicando que el campo nombre es obligatorio.
Definición de casos de prueba:

Depurar los casos de prueba definidos por el QA y determinar(en conjunto con el equipo de
desarrollo) los casos testeables.
En base a lo detallado en la definición de Criterios de aceptación, definir los casos de prueba en
base al formato indicado en la tabla, donde:

C(n): Cantida de casos por cada escenario.

Accion(n): Cantidad de acciones que se pueden realizar para el escenario a probar.
 Resultado(n): Resultados esperados.
Definición de los test unitarios:

La codificación de los test unitarios deben ser :

Atómicos: Es decir; el test debe probar la mínima cantidad de funcionalidad.
Independiente: Es decir; la ejecución del test no debe depender de otros test para producir
un resultado satisfactorio.
Rápido: Su ejecución debe ser rápida.
Inocuo: Significa que su ejecución no altera el estado del sistema, es decir; el resultado debe
ser el mismo al ejecutarlo una o muchas veces.
La implementación de los test debe seguir el éstandar definido en éste documento.

3.- Procedimiento para la implementación de TDD

Se selecciona un caso de prueba.

Se escribe un test en base al caso de prueba seleccionado.
Se verifica si la prueba unitaria falla.
Implementar el código para superar la prueba unitaria.
Ejecutar nuevamente la prueba para ver si es superada.
Se refactorizar y se limpia el código implementado.
Ejecutar finalmente el test y comprobar que funcionan correctamente.