1. Lineamientos Generales
-
Asegurarse de que los Pull Request sean concluidos es parte de las responsabilidades de cada Squad member. Por lo tanto son responsables de resolver cada observación.
-
Cada squad tiene definidos sus revisores requeridos.
- Sentry. Oscar Quisbert, Victor Chuquimia, Samuel Cari, Hector Copa, Hector Velez.
- Rocket. Ruben Alberto, Victor Chuquimia, Samuel Cari, Hector Copa, Hector Velez.
- NAD. Samuel Cari, Victor Chuquimia, Hector Copa, Hector Velez.
- Bravo. Hector Copa, Samuel Cari, Victor Chuquimia, Hector Velez.
-
Los squad leaders son los primeros en revisar los PRs. Se aguardará hasta tener su OK para seguir con las verificaciones adicionales.
-
En caso de necesitar la verificación de otros miembros del equipo se los agregará como revisores requeridos por lo que la aprovación del PR dependerá de la opinión del consultor externo.
2. Aspectos a ser considerados en la revisión de los Pull Requests.
- Que el Pull Request tenga linkado el Bug o US que está siendo resuelto. Esto va a facilitar el tracking de items que van siendo publicados en live.
- Los commits deben estar linkados con la task en la que se realiza el cambio.
- Que los cambios realizados estén de acuerdo a los cambios solicitados por el llamado.
- Evitar el uso excesivo de variables innecesarias.
var result = AwesomeClass.FantasticMethod();
return result;
- Emplear funciones nativas del lenguaje o proveeidas por los frameworks.
- Los archivos SQL que contengan traducción, deben estar siempre en UTF-8 (no es valido UTF-8-BOM). Tomar en cuenta que el resolvedor de conflictos en los Pull Request de Azure tiene por defecto configurado el Formato ANSI y no UTF-8. Para estos casos se suguiere resolverlo en local con un merge de la rama recurso.
FrontEnd
-
Se valida las reglas establecidas en la guia de estilo oficial de angular https://angular.io/guide/styleguide
-
Se valida las reglas establecidas por el proyecto para TypeScript
-
Que todos los recursos traducibles sean registrados y traducidos al Español (usando la herramienta translate) descargable desde aqui.
- Label nuevos.
- Excepciones.
- Reportes.
-
Todo codigo HTML nuevo debe ser estar acorde al estandar v5.
-
Todo codigo CSS nuevo debe ser estar acorde al estandar v3.
-
Todo codigo JS nuevo debe ser estar acorde al estandar ECMAScript 6
-
La identancion para nuevo codigo debe ser con dos espacios (el proyecto ya cuenta con una configuracion que deberia habilitarse en el editor o IDE de su preferencia).
BackEnd
- Que los CRUDS tengan todos sus tests en la carpeta correspondiente de la solución de Test.sln
- Las nuevas implementaciones de endpoints para controladores debe estar bajo Web Api 2 y el tipo de response deberá concordar con el FrontEnd.
Traducción
- Las scripts de traducción deben tener la codificación UTF-8 para mostrar correctamente caracteres especiales.
Corrections
- Las correciones deben postarse en un repo separado llamado ToolBox dentro de la carpeta correspondiente. NAD o SAD.
- Agregar el script log. especificando un título, IT o OTRS, WorkItemId, Descripción y Autor.
EXEC [aasi_scripts_log] 'journals docuplicados', '0', 117023, 'borrando journals duplicados IN 1 y 2 de la entidad 188111', 'Ngolo Kanté'
- Agregar el header de la script con las siguientes informaciones.
/*
--=======================================================================
.SYNOPSIS
Script para crear Bugs
.DESCRIPTION
crea bugs en base al título y descripción usando el método standard.
.AUTOR
Cesc Fabregas
.DATE 28/4/2020
--=======================================================================
*/
Breaking Changes (BC)
Al inicializar el archivo breaking changes, agregar un "scripts log" para marcar el final de la ejecución de todas las scripts. Esto nos ayuda a en el analisis de errores producidos por scripts q no se terminaron de ejecutar por algun error.
La siguiente script debe ir en la ultima linea de los archivos BC.
EXEC [aasi_scripts_log] 'Version XYZ', '0', 117023, 'End breaking changes', 'Kingsley Coman'