Prueba de concepto herramienta de automatización de código

[milo19980525]

Se requiere desarrollar una prueba de concepto para automatización de código empleando alguna de las herrmientas encontradas en #75.

Especificaciones técnicas

• La prueba de concepto se debe realizar con un proyecto con forma base de proyecto web (parte front). Además de una estructura para el black (mid y crud)
• Las herramientas identificadas en la issue #75 se deben utilizar para la prueba de concepto (por lo menos una).

Sub Tareas

• [x] Desarrollar una plantilla para un proyecto tipo front básico (escoga la estructura que más le convenga o que considere pertinente), definiendo los parámetros configurables la estructura de archivos pertinente y demás configuración posible.
• [x] Desarrollar una plantilla para un proyecto tipo back básico CRUD (escoga la estructura que más le convenga o que considere pertinente), definiendo los parámetros configurables la estructura de archivos pertinente y demás configuración posible.
• [x] Desarrollar una plantilla para un proyecto tipo back básico MID (escoga la estructura que más le convenga o que considere pertinente), definiendo los parámetros configurables la estructura de archivos pertinente y demás configuración posible.

Criterios de aceptación

• [x] Se crea una plantilla con parametros que dan como resultado la estructura base de un proyecto tipo front.
• [x] Se crea una plantilla con parametros que dan como resultado la estructura base de un proyecto tipo back (Mid).
• [x] Se crea una plantilla con parametros que dan como resultado la estructura base de un proyecto tipo front (Crud).

Requerimientos

• [x] Revisión y análisis de herramientas de automatización

Dependencias

• No presenta.

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias entán identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [x] Desarrollo en local.
• [x] Push en Feature.
• [x] Pruebas locales (funcionales).
• [x] PR a Develop.
• [x] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [x] Aprobada por SM/Líder técnico.

[milo19980525]

@a52290451 Por favor comentar lo adelantado en el issue.

[a52290451]

Herramienta utilizada

Para la automatización de código en la creación y refactorización de proyectos, se empleo Hygen, cuya investigación se encuentra en: #75

Creación de plantilla para API_MID en GO

Para la creación de la plantilla API_MID se utilizo como punto de referencia la API CUMPLIDOS_DVE_MID. La implementación inicial deja como resultado la siguiente estructura de archivos fuente:

Los datos que se configuraron para que sean ingresados por parte del usuario y lograr un mayor nivel de personalización de la API generada son:

• goversion: versión de GO
• pgversion: versión de Postgres para el archivo docker-compose.yml
• dcversion: versión de docker-compose

Para la creación de la API se ejecuta el siguiente comando:

hygen api_mid_template with-prompt --appname api_mid_prueba

En donde:

• "api_mid_template" representa el generador.
• "with-prompt" representa una subdivisión al interior del generador.
• "--appname" representa una acción (en este caso define una variable de entrada)
• "api_mid_prueba" representa el nombre de la variable, que equivale al nombre de la API

Luego se solicita que se ingresen los datos anteriormente mencionados:

Y, finalmente, de forma automática, se crea el directorio con el nombre de la API señalado, y en su interior todos los archivos correspondientes:

La vista final de la estructura de archivos de la nueva API queda de la siguiente manera.

Nota: cabe aclarar que, al finalizar la generación de los archivos, de igual forma se instrumentan una serie de comandos que generan archivos complementarios como "go.mod", "go.sum", "swagger.json", "swagger.yml" entre otros. Todo esto con el fin de lograr que la API quede lista para su ejecución.

Creación de plantilla para API_CRUD en GO, con base en una BD

Para la creación de la plantilla API_CRUD, no se empleó una API base, en su lugar, a través del comando:

'bee api appname -driver=postgres -conn="postgres:// pguser:pgpass@pghost/dbname?sslmode=disable

Se realiza la creación de una API_CRUD inicial, con base en una Base de datos Postgres existente.

La implementación inicial deja como resultado la siguiente estructura de archivos fuente:

Tras la generación inicial de la API_CRUD, hygen sobrescribe y actualiza los archivos app.conf y main.go. El resto de los archivos, se mantienen iguales.

Los datos que se configuraron para que sean ingresados por parte del usuario y lograr un mayor nivel de personalización de la API generada son:

• goversion: versión de GO
• pgversion: versión de Postgres para el archivo docker-compose.yml
• dcversion: versión de docker-compose
• pguser: Usuario de la Base de Datos
• pgpass: Contraseña del usuario para la BD
• pghost: Host para la conexión a la BD
• dbname: Nombre de la Base de Datos

Para la creación de la API se ejecuta el siguiente comando:

hygen api_crud_template with-prompt --appname api_crud_prueba

En donde:

• "api_crud_template" representa el generador.
• "with-prompt" representa una subdivisión al interior del generador.
• "--appname" representa una acción (en este caso define una variable de entrada)
• "api_crud_prueba" representa el nombre de la variable, que equivale al nombre de la API

Luego se solicita que se ingresen los datos anteriormente mencionados:

Y, finalmente, de forma automática, se crea el directorio con el nombre de la API señalado, y en su interior todos los archivos correspondientes:

La vista final de la estructura de archivos de la nueva API queda de la siguiente manera.

Nota:

1. cabe aclarar que, al finalizar la generación de los archivos, de igual forma se instrumentan una serie de comandos que generan archivos complementarios como "go.mod", "go.sum", "swagger.json", "swagger.yml" entre otros. Todo esto con el fin de lograr que la API quede lista para su ejecución.
2. Para la creación de la API_CRUD se requiere tener creada una Base de Datos, la cual se utilizara como base para la generación de la estructura base.

DEUDA TÉCNICA

1. Inyección de código: se requiere implementar inyección de código para ajustar partes específicas de la estructura base generada en la creación de la API.
2. Refactor del API: se requiere automatizar el refactor del API.
3. Migración del API: Ajustar la plantilla con los cambios sugeridos en Beego Migrations.

Creación de plantilla para Nuevos Clientes en Angular JS y TypeScript

Para la creación del generador de Nuevos Clientes se utilizó como base la plantilla señalada en los lineamientos de la OATIC.

La implementación inicial deja como resultado la siguiente estructura de archivos fuente:

Son aproximadamente 56 archivos base, lo cual supone una gran cuota inicial de archivos para un nuevo cliente.

Tras la generación inicial del cliente, hygen ejecuta una serie de comandos que copian los archivos estáticos, como assets y demás, a sus ubicaciones correspondientes.

Los datos que se configuraron para que sean ingresados por parte del usuario y lograr un mayor nivel de personalización de la API generada son:

• angversion: Versión de AngularJS
• nodeversion: Versión de NodeJS

Para la creación de la API se ejecuta el siguiente comando:

hygen cliente_oas_template with-prompt --appname cliente_prueba

En donde:

• "cliente_oas_template" representa el generador.
• "with-prompt" representa una subdivisión al interior del generador.
• "--appname" representa una acción (en este caso define una variable de entrada).
• "cliente_prueba" representa el nombre de la variable, que equivale al nombre del cliente.

Luego se solicita que se ingresen los datos anteriormente mencionados:

Y, finalmente, de forma automática, se crea el directorio con el nombre del cliente señalado, y en su interior todos los archivos correspondientes:

La ejecución de este comando tarde un poco ya que internamente ejecuta el comando:

npm i --legacy-peer-deps

El cual se encarga de instalar todos los paquetes y dependencias del proyecto.

La vista final de la estructura de archivos del nuevo cliente queda de la siguiente manera.

Nota: cabe aclarar que, al finalizar la generación de los archivos, de igual forma se instrumentan una serie de comandos que generan y copian archivos complementarios y realizan la instalación de dependencias del proyecto. Todo esto con el fin de lograr que el cliente quede lista para su ejecución.

DEUDA TÉCNICA

1. Automatización de estilos: de forma interactiva, se puede automatizar la selección de estilo que tendrá el nuevo cliente.
2. Inclusión de archivos estáticos: queda pendiente la inclusión de archivos estáticos al interior de la plantilla. Actualmente se encuentran por fuera y son clonados desde una dirección externa.

---

---

DEUDA TÉCNICA GENERAL

Automatización y sincronización con GITHUB

• Se requiere buscar una forma de que las plantillas se almacenen en github y que solo sea necesario clonar los repositorios y ejecutarlas para la generación de código automático.
• Se requiere automatizar al interior de las plantillas la sincronización con los repositorios creados previamente para las nuevas APIs y Clientes

[a52290451]

@milo19980525 Se requiere especificar Repositorio para cargar las plantillas creadas

[milo19980525]

@a52290451 porfa crear un nuevo repo para cada plantilla y subirlo allí, muy buen trabajo.

[a52290451]

Creación de repositorios

1. Repositorio para Plantilla API_MID: https://github.com/udistrital/plantilla_api_mid

2. Repositorio para Plantilla API_CRUD: https://github.com/udistrital/plantilla_api_mid

3. Repositorio para Plantilla de Nuevos Clientes: https://github.com/udistrital/plantilla_cliente_oas