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. |
| Analista 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. |
| Encargado de Soporte Técnico (EST) | Reporta a Gerencia General los casos de corrección por actualización de código y solicita las auditorías correspondientes. |
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
- EDL Expediente Digital de Liberación.
5. Descripcion del Proceso
I. Clasificación del Cambio
Responsable: Analista Programador (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: Analista Programador (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 incluirse obligatoriamente el número de OS en el título o cuerpo al momento de solicitar un PULL REQUEST, lo que permitirá la trazabilidad de las OS en el proyecto asignado. El AED podrá ubicar la OS para registrar su tiempo al realizar el MERGE.
III. Pase de DEV a QA
Responsable: Analista Programador (AP) / Analista encargado de Desarrollo (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: Analista Programador (AP) / Analista encargado de Desarrollo (AED)
Si los cambios realizados al ERP son complejos o involucran procesos sensibles que puedan afectar la operatividad de los clientes (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 cumplirse 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: Analista Programador Tester (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. Entrega del Expediente Digital de Liberación (EDL)
Responsable: Analista Programador (AP)
El AP debe entregar el EDL al AED, incluyendo obligatoriamente la siguiente información:
- Número de OS.
- Informe de Testeo.
- Entorno QA utilizado (por ejemplo: arudas, jomar, etc.).
- Correo de conformidad firmado por el cliente.
al AP.
Además, debe incluir los siguientes adjuntos:
- Script SQL con el parche a ejecutar, sin realizar ningún cambio adicional.
- Link del Pull Request (PR) con los cambios registrados en GitHub.
VII. Revisión y Ejecución de Script
Responsable: Analista encargado de Desarrollo (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.
VIII. Revisión de Informe de Testeo
Responsable: Analista encargado de Desarrollo (AED)
El AED revisa el informe elaborado por el Analista Programador Tester (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.
IX. Revisión del Expediente Digital de Liberación (EDL)
Responsable: Analista encargado de Desarrollo (AED)
El AED revisa el EDL entregado por el AP.
- Si está conforme, lo aprueba.
- Si el EDL presenta algún error en el informe o en los archivos adjuntos, el AED lo devolverá indicando los puntos a corregir
X. 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.
XI. Pase a Producción
Responsable: Analista encargado de Desarrollo (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.
XII. Resolución de Conflictos
Responsable: Analista Programador (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.
XIII. Comunicación a Clientes
Responsable: Encargado de Soporte (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.
XIV. Auditoría y Sanciones
Responsable: Encargado de Soporte Técnico, Gerencia General (EST/GG)
Todos los casos de correcciones por actualización de código deberán ser reportados por el EST a laGG, solicitando que un Analista Programador no involucrado en el incidente realice una auditoría del evento.
Si de las conclusiones de la auditoría se desprende responsabilidad de algún colaborador de Integrator SAC por incumplimiento de este procedimiento, este será susceptible a una sanción equivalente a una llamada de atención o suspensión, dependiendo del nivel de la falta y del daño causado al cliente y a Integrator.