1. Objetivo y Alcance
🔹Objetivo: Definir las actividades, responsabilidades y controles necesarios para garantizar que las actualizaciones de código en el ambiente de PROD del ERP Integrator se realicen de manera controlada, segura y trazable, minimizando riesgos operativos para los clientes.
🔹 Alcance: Este procedimiento debe ser seguido por todos los Analistas Programadores de Integrator SAC.
2. Roles y Responsabilidades
| Rol | Responsabilidad |
|---|---|
| Gerencia General (GG) | Supervisa y aprueba lineamientos generales del proceso. |
| Analista Programador (AP) | Desarrolla, documenta y corrige los cambios solicitados. |
| Analista Programador Tester (APT) | Ejecuta validaciones funcionales y documenta resultados. |
| Administrador de Base de Datos (ADMBD) | Ejecuta scripts SQL en producción y valida integridad de datos. |
| Encargado de Desarrollo (AED) | Revisa código, valida cumplimiento del proceso y autoriza el pase a producción. |
| Encargado de Soporte (ESOP) | Comunica a clientes cuando los cambios impacten la operatividad. |
3. Definicion
La modificación y actualización del código del ERP Integrator o de su base de datos es una actividad crítica para garantizar la estabilidad y correcto funcionamiento del sistema.
La actualización en PRODUCCIÓN consiste en trasladar un desarrollo previamente validado en los ambientes DEV y QA al ambiente PROD, asegurando:
- Trazabilidad mediante número de OS.
- Validación funcional previa.
- Revisión técnica del código y scripts SQL.
- Ejecución controlada en bases de datos productivas.
- Comunicación a clientes cuando corresponda.
4. Glosario
- ERP: Sistema Integrator.
- VCS: Validación de Código a desde el Sistema (ERP)
- DEV: Ambiente de Desarrollo
- QA: Ambiente de Validación
- PROD: Ambiente de Producción
- OS: Orden de Soporte
5. Descripcion del Proceso
I. Clasificación del Cambio
Responsable: AP
Todo cambio o modificación en el código del ERP debe ser clasificado por el AP como simple o complejo, antes de iniciar el proceso de actualización.
- Cambio Simple (No requiere OS de testeo formal)
Se considera simple cuando no impacta el funcionamiento del ERP ni afecta otros procesos del sistema. Ejemplos:
– Cambios visuales (Ajustes de interfaz que no afectan la lógica)
– Correcciones tipográficas.
– Cambios menores en formatos de reportes (Cambios que no impliquen desarrollos).
– Actualización de enlaces o redirreciones internas.
- Cambio Complejo (Requiere validación formal, testeo y documentación obligatoria.)
Se considera complejo cuando su levantamiento al sistema produce cambios importantes en el funcionamiento del ERP o puede poner en riesgo la funcionalidad de otros procesos, afectando la operatividad de los usuarios. Ejemplos:
– Impacto en procesos críticos (Ventas, Facturación, NC, Guías, CxC).
– Modificaciones en la estructura de base de datos.
– Cambios que alteren el comportamiento del sistema.
II. Registro y Trazabilidad
Responsable: AP
El AP inicia la creación del ISSUE en GITHUB para describir la tarea a realizar, se asigna el proyecto ERP y el número de OS.
- Debe incluir obligatoriamente el número de OS en el título o cuerpo, al momento de solicitar un PULL REQUEST ,esto permitirá la trazabilidad de las OS en el proyecto asignado.
- El AED podra ubicar la OS para registrar su tiempo al realizar el MERGE.
III. Pase de DEV a QA
Responsable: AP/AED
- El AP sube los cambios vía SFTP al ambiente QA, para iniciar con las validaciones.
- El AP no tiene acceso directo al repositorio GitHub.
IV. Proceso de Testeo (Solo Cambios Complejos)
Responsable: AP/AED
Si los cambios realizados al ERP son complejos o involucran procesos sensibles que puedan afectar la operatividad de los clientes (como Notas de Venta, Facturación, Notas de Crédito, Emisión de Guías de Remisión o Cuentas por Cobrar), el AP deberá emitir una solicitud de testeo mediante la OS correspondiente.
Dicha solicitud será asignada a un AP con experiencia en el módulo afectado, en coordinación con el Encargado de Soporte.
En la OS, el AP deberá adjuntar obligatoriamente:
- Manual de validación para realizar el VCS.
- Script SQL con extensión “.sql”, el cual no debe presentar errores al ser ejecutado por el DBA.
- Se recomienda incluir en el script sentencias preventivas como:“DROP TABLE/PROCEDURE/FUNCTION IF EXISTS obj_tabla_function_sp”;
Si los cambios son simples y no afectan procesos sensibles, no será necesario emitir OS de testeo.
En todos los casos (cambios simples o complejos), el AED será responsable de subir los cambios de QA al repositorio de GitHub, verificando que contengan el número de OS correspondiente.
De no cumplir con este requisito, notificará al AP para su corrección. Posteriormente, los cambios serán sincronizados automáticamente de QA a PROD.
V. Validación Funcional
Responsable: APT
El APT deberá realizar las validaciones desde el ERP utilizando el manual entregado por el AP “Instrucciones de Testeo de código”.
Durante el testeo:
- Elaborará un informe detallado describiendo cada operación realizada y el estado de cada una.
- Si no se presenta ningún inconveniente, dará por finalizada la OS.
- Si se detectan errores, deberá informarlos al AP responsable y, de ser posible, adjuntar capturas de pantalla y logs (los archivos pueden enviarse aparte, indicando su nombre en el informe).
- Una vez levantadas las observaciones y finalizado el procedimiento, el APT entregará el informe al AED para su revisión y conformidad.
VI. Revisión y Ejecución de Script
Responsable: AED
El AED revisa el script SQL y ejecuta el parche en ambiente controlado.
Si no presenta ningún error, deberá:
- Informar al AP.
- Hacer entrega del script.
VII. Revisión de Informe de Testeo
Responsable: AED
El AED revisa el informe elaborado por el APT.
- Si está conforme, aprueba la OS para continuar con el proceso.
- Si encuentra observaciones, envía el archivo de casos de prueba al AP para la corrección correspondiente.
VIII. Validación con Clientes
Si los cambios son complejos y pueden afectar a clientes específicos:
- El AP debe informar al equipo e identificar qué clientes podrían verse impactados.
- Si corresponde, deberá instalar un ambiente de prueba para cada cliente con su respectiva data.
- Informará a los clientes sobre los cambios realizados y solicitará su validación.
- En caso de observaciones, deberá corregirlas hasta obtener el visto bueno del cliente.
IX. Pase a Producción
Responsable: AED
Una vez aprobado el trabajo por el AED:
- El AED sube los cambios de QA al repositorio de GitHub, verificando que contengan el número de OS.
- Si no lo contiene, notificará al AP para su corrección.
- Posteriormente, los cambios se sincronizarán automáticamente de QA a PROD.
- El AED ejecutará el script en todas las bases de datos de la nube de Integrator.
X. Resolución de Conflictos
Responsable: AP
Si se genera algún conflicto al momento de crear el PULL REQUEST antes del pase a producción:
- El AP deberá resolverlo de manera inmediata.
- Podrá solicitar apoyo del AED si no logra resolverlo por sí mismo.
No se permitirá el pase a producción mientras exista un conflicto pendiente.
XI. Comunicación a Clientes
Responsable: ESOP
Si el desarrollo afecta el funcionamiento general del ERP:
- Se emitirá un comunicado oficial a todos los clientes informando sobre la actualización realizada.