Ciclo de Vida de Desarrollo Seguro (SDLC) – AHORA ERP 5

Ciclo de Vida de Desarrollo Seguro (SDLC) de AHORA ERP — descripción de los controles de seguridad, calidad y trazabilidad que aplica Ahora Soluciones en la construcción, verificación y publicación de Ahora ERP, con las evidencias que los sustentan en el sistema de integración continua.

• Producto: Ahora ERP, línea 5.x (ramas 5.0.0, 5.1 y develop)

• Alcance: Cadena de construcción ERP_Version5 y su árbol de dependencias

• Plataforma CI/CD: JetBrains TeamCity 2026.2, 12 agentes de compilación

• Control de versiones: GitLab corporativo, repositorio erp/estandar

• Versión del documento: 1.0 · 15 de septiembre de 2026

• Evidencia de referencia: Compilación 3710 de ERP_Version5, etiqueta v5.0.0.146

Índice

1. 1. Introducción

2. 2. Alcance y arquitectura del producto

3. 3. Flujo general del SDLC aplicado

4. 4. Cadena de construcción en integración continua

5. 5. Gobierno del código fuente y desarrollo seguro

6. 6. Controles de seguridad y procedimientos implementados

7. 7. Auditoría y trazabilidad

8. 8. Alineación con estándares

9. 9. Conclusiones

10. Anexo A. Inventario de configuraciones de la cadena

11. Anexo B. Glosario

1. Introducción

Ahora ERP se desarrolla bajo un Ciclo de Vida de Desarrollo Seguro (SDLC) formalmente estructurado, que integra prácticas de seguridad, control de calidad y trazabilidad en cada fase del proceso: desde la apertura de una incidencia o petición de desarrollo en el gestor de código hasta la publicación de la versión instalable y sus paquetes de actualización.

La construcción del producto está completamente automatizada en el sistema de integración continua de Ahora Soluciones. La cadena de la versión 5 está compuesta por 15 configuraciones de compilación encadenadas que ejecutan 97 pasos automatizados, cada uno de ellos registrado, condicionado al éxito del anterior y con sus resultados y artefactos conservados para auditoría.

El entorno de automatización garantiza que todas las compilaciones sigan un flujo reproducible sobre una revisión única del código, con compilación en entornos limpios, pruebas unitarias, de base de datos, de interfaz de usuario y de actualización, análisis estático de código y de composición de software, protección de los binarios mediante ofuscación y firma digital, y empaquetado versionado de los resultados.

2. Alcance y arquitectura del producto

Ahora ERP es una solución ERP-CRM-BPM para el mercado español. El producto se construye a partir de un repositorio único que contiene las capas que forman la aplicación:

Este documento describe la cadena de construcción ERP_Version5 (identificador Erp_ErpNetInstalador) y las configuraciones de las que depende. Quedan fuera del alcance, aunque forman parte de la misma cadena y se construyen con los mismos principios, los componentes Actualizador, AhoraCertificados, AhoraDispositivos, TechFun, Traductor y AhoraAPI, que cuentan con sus propios procesos.

3. Flujo general del SDLC aplicado

El proceso se estructura en fases secuenciales cuya ejecución está condicionada al éxito de las anteriores. Las dependencias entre configuraciones se declaran como snapshot dependencies en TeamCity: todas las configuraciones de la cadena se compilan sobre la misma revisión del repositorio, y el fallo de cualquier dependencia cancela la generación de la versión.

1. Gobierno del código y revisión. Issue en GitLab con plantilla, rama por issue, merge request con aprobación obligatoria y guías de codificación segura.

2. Preparación y aislamiento del entorno. Checkout limpio, bases de datos efímeras por compilación, eliminación de restos de ejecuciones previas y agentes dedicados.

3. Control de versión y trazabilidad. Sellado del número de versión y hotfix en todos los proyectos, etiquetado en Git y en TeamCity.

4. Compilación controlada. Base de datos (SSDT y dacpac), aplicación .NET y módulos compilados con herramientas y versiones fijadas.

5. Gestión segura de dependencias. Fuentes NuGet controladas, componentes internos fijados y generación del inventario de software (SBOM).

6. Verificación y pruebas. Pruebas unitarias, de base de datos, de interfaz de usuario y de actualización de versiones anteriores, incluida la idempotencia del hotfix.

7. Protección de binarios. Ofuscación del código .NET y firma digital del ejecutable y del instalador con certificado corporativo.

8. Análisis estático y de composición (SAST/SCA). SonarQube con cobertura de pruebas y Dependency-Track para las vulnerabilidades de componentes de terceros.

9. Artefactos, documentación y notas de versión. Instalador, paquetes NuGet, copias de base de datos, documentación de API, changelog, release notes y vídeo de novedades.

10. Entornos de prueba y publicación controlada. Entorno de pruebas por issue, compilación nocturna de las ramas de versión y publicación oficial bajo aprobación humana.

11. Cierre seguro. Eliminación de bases de datos, procesos y binarios temporales, ejecutada incluso cuando la compilación falla.

Cada fase incorpora controles y evidencias verificables. Las secciones siguientes detallan la cadena de construcción, el gobierno del código y los controles implementados en cada fase, indicando en cada caso la configuración y el paso de TeamCity que los ejecuta.

4. Cadena de construcción en integración continua

La configuración ERP_Version5 es el punto de entrada de la versión: genera el instalador y los paquetes de distribución a partir de los artefactos producidos por sus dependencias. El árbol completo de la cadena es el siguiente.

• ERP_Version5 (instalador, firma y paquetes NuGet)

  • ERP_SQL (base de datos: dacpac y ERPVacia), que consume GeneradorVacia como artefacto fijado

  • ERP_SQL_Hotfix5 (script de hotfix e idempotencia), que depende de ERP_SQL

  • ERP_CS (compilación .NET, pruebas unitarias, ofuscación y firma)

  • ERP (integración SQL + .NET), que depende de ERP_SQL, ERP_CS, ERP_CS_TESTS_UI (que depende de ERP_SQL), ERP_SQL_Tests, ERP_Deploy_Testing (que depende de ERP_SQL y ERP_CS) y ERP_NET_TestUpdate

  • ERP_NET_TestUpdate (prueba de actualización), que depende de ERP_SQL, ERP_SQL_Hotfix5 y ERP_CS

  • ERP_SQL_Tests (pruebas de base de datos), que depende de ERP_SQL

  • ERP_DeclaracionResponsable (PDF firmado Verifactu)

  • ERP_Version5Changelog (changelog)

  • ERP_Version5_VideoNovedades (vídeo de novedades)

  • ERP_SAST (SonarQube y Dependency-Track), que depende de ERP_CS_TESTS_UI

Las flechas de dependencia indican relación de snapshot (misma revisión) y, en la mayoría de los casos, también de artefactos. Las configuraciones Actualizador, TechFun, Traductor, AhoraAPI, AhoraCertificados y AhoraDispositivos participan igualmente en la cadena pero quedan fuera del alcance de este documento.

Políticas de encadenado

• Revisión única. Todas las dependencias se resuelven con sync-revisions: la cadena completa se construye sobre el mismo commit del repositorio, lo que garantiza que el instalador, la base de datos, las pruebas y el análisis de seguridad corresponden exactamente al mismo código.

• Solo compilaciones correctas. Las dependencias de artefactos toman únicamente compilaciones finalizadas con éxito de la misma cadena (take-successful-builds-only, revisión sameChainOrLastFinished).

• Fallo bloqueante. La política ante el fallo de una dependencia es CANCEL: si falla la base de datos, las pruebas SQL, la prueba de actualización o cualquier otra dependencia, la versión no se genera. La única excepción es el análisis ERP_SAST, que se ejecuta en paralelo con política RUN y publica sus resultados en las plataformas de calidad sin detener la cadena (ver 6.7).

• Entorno limpio. Las configuraciones principales están marcadas con cleanBuild=true (checkout limpio en cada ejecución) y shouldFailBuildOnAnyErrorMessage=true, de modo que cualquier mensaje de error emitido por una herramienta marca la compilación como fallida.

• Límites de ejecución y recursos. Se definen tiempos máximos de ejecución (60 minutos para la compilación .NET, 300 minutos para las pruebas de interfaz) y comprobaciones de espacio libre en disco previas a la compilación (entre 10 y 30 GB según la configuración).

• Agentes dedicados. Las pruebas de interfaz de usuario se ejecutan únicamente en agentes con sesión interactiva (nombre terminado en ui); el resto de configuraciones excluyen explícitamente esos agentes y el agente de línea de comandos, evitando interferencias entre compilaciones y pruebas.

Evidencia. El servidor de integración continua dispone de 12 agentes autorizados en el pool Default. La compilación 3710 de ERP_Version5 (rama 5.0.0, 10 de septiembre de 2026, 23:10 a 23:28) se resolvió sobre 14 dependencias de snapshot y quedó etiquetada como v5.0.0.146, la misma etiqueta que recibió el commit en Git.

5. Gobierno del código fuente y desarrollo seguro

La seguridad del producto comienza antes de la integración continua. El repositorio se aloja en el GitLab corporativo de Ahora Soluciones y el acceso desde TeamCity se realiza mediante clave SSH almacenada en el servidor de integración (función SSH Agent con la clave del usuario integrador), sin credenciales en los scripts.

Flujo de trabajo

• Todo cambio nace de una issue. GitLab dispone de plantillas obligatorias para Incidencia y Nuevo desarrollo, que exigen documentar versiones afectadas, pasos de reproducción, análisis técnico, batería de pruebas, notas de versión y documentación funcional.

• Rama por issue. El trabajo se realiza en ramas independientes nombradas con el número de issue (por ejemplo 25412-sii-anulacion-rectificativa), que la integración continua compila de forma aislada. Las ramas de versión son 5.0.0 (mantenimiento), 5.1 y develop.

• Merge request con revisión. La guía de contribución del repositorio establece que todo merge request necesita al menos una aprobación; los cambios en el núcleo AhoraCore requieren la revisión del responsable técnico del módulo; las migraciones de base de datos se revisan de forma específica por su carácter irreversible en producción; los merge requests deben ser pequeños y de un único cambio lógico.

• Estado de la compilación en GitLab. La configuración ERP publica el resultado de la compilación en el commit de GitLab (Commit Status Publisher), de modo que el revisor ve en el merge request si la rama compila y pasa las pruebas antes de aprobarla. TeamCity monitoriza además las referencias refs/merge-requests/*/head.

• Compilar sin avisos y probar antes de subir. La guía exige 0 errores y 0 nuevos avisos de compilación, añadir o actualizar pruebas y ejecutarlas localmente antes de crear el merge request.

Guías de codificación segura

El repositorio incluye guías de convenciones (archivos CONTRIBUTING.md, .editorconfig e instrucciones específicas para C#, WinForms, SQL Server y pruebas) que fijan reglas de seguridad de cumplimiento obligatorio:

• Consultas SQL parametrizadas. Toda consulta utiliza parámetros (Valor[] con @p0, @p1…). La concatenación de valores en SQL está prohibida y las sobrecargas sin parámetros de la capa de acceso a datos están marcadas como [Obsolete], de forma que el compilador avisa de su uso.

• Control de errores obligatorio en todos los métodos, con registro a través del servicio de trazas del producto.

• Inyección de dependencias a través del contenedor de servicios, sin instanciación directa de servicios de infraestructura.

• Preparación para la ofuscación. Los tipos que deben sobrevivir a la ofuscación (entidades, tipos serializados, enumerados) se marcan explícitamente con [Obfuscation(Exclude = true)].

• Base de datos. Cabecera estándar y bloque TRY/CATCH en todos los procedimientos almacenados, IF EXISTS en triggers, acceso a la configuración a través de funciones y no de tablas, y regla de datos estáticos para el actualizador.

• Revisión asistida. El repositorio incorpora agentes y prompts de revisión de código para los asistentes de desarrollo del equipo (revisor de código, planificador, revisión de seguridad) que detectan de forma sistemática inyección SQL, métodos obsoletos, ausencia de control de errores y antipatrones antes de la revisión humana.

Configuración sensible fuera del repositorio

La configuración local (appsettings.local.json, cadenas de conexión de pruebas) no se versiona. En la integración continua, los archivos de configuración de las pruebas se generan en tiempo de compilación con la instancia y la base de datos efímera de cada ejecución (pasos Configurar settings Tests y Configurar settings Tests UI), por lo que el repositorio no contiene credenciales ni cadenas de conexión de entornos reales.

6. Controles de seguridad y procedimientos implementados

6.1. Preparación y aislamiento del entorno de construcción

• Checkout limpio. Las configuraciones se ejecutan con cleanBuild=true: el directorio de trabajo del agente se borra y el código se obtiene íntegro del repositorio en cada compilación, eliminando cualquier resto de compilaciones anteriores.

• Bases de datos efímeras por compilación. Cada configuración que necesita SQL Server crea su propia base de datos en la instancia local del agente, nombrada con el identificador único de la compilación (ERPSQL-<id>, ERPHOTFIX5-<id>, ERPTESTUI-<id>, ERPNETTESTUPDATE-<id>), con autenticación integrada de Windows. Nunca se compila ni se prueba contra bases de datos compartidas o de clientes.

• Saneamiento previo. El paso Preparar compilación elimina las bases de datos de compilaciones anteriores con más de 12 horas de antigüedad y recrea los directorios de publicación, garantizando que el agente parte de un estado conocido.

• Agentes de pruebas de interfaz. Antes de las pruebas de interfaz se cierran los procesos del ERP que pudieran quedar abiertos y la sesión de escritorio remoto, y se reinicia la configuración de conexiones del usuario de pruebas.

6.2. Control de versión y trazabilidad del código

• Sellado de versión. El primer paso de cada configuración ejecuta set-projects-version.ps1, que estampa el número de versión y hotfix (X.Y.Z.H) en todos los proyectos .NET, SQL y en el paquete de TechFun, de modo que todos los binarios, la base de datos y los paquetes comparten el mismo número de versión y pueden correlacionarse con el commit que los produjo.

• Validación del formato. El parámetro Version se valida con expresión regular (^\d+\.\d+\.\d+$) y el hotfix se deriva de la última etiqueta Git (git describe) cuando no se informa explícitamente.

• Etiquetado doble. En las compilaciones oficiales, git-push-version.ps1 confirma los archivos de versión, crea la etiqueta vX.Y.Z.H en el repositorio y aplica la misma etiqueta a la compilación de TeamCity, enlazando de forma inequívoca el código fuente, la ejecución de la cadena y los artefactos generados.

• Fichero de versión. El artefacto version.txt acompaña a cada publicación con el número exacto de versión construido.

6.3. Compilación controlada

Base de datos (ERP_SQL)

• Restauración de paquetes NuGet de la solución SQL con la versión fijada de NuGet (4.9.3).

• Compilación del proyecto SSDT (ERPAhoraSoluciones) a .dacpac con MSBuild o el SDK de .NET, y publicación del dacpac sobre una base de datos nueva mediante sqlpackage (CreateNewDatabase=True). Este despliegue real valida que el modelo completo es desplegable y coherente.

• Comprobaciones del actualizador sobre la base de datos publicada (utilidad GeneradorVacia o Actualizador), que verifican la generación de versión y los datos estáticos.

• Generación del dacpac de referencia y su paquete NuGet (AhoraERP.SQL.Reference) para el desarrollo de módulos y personalizaciones sobre un contrato de esquema conocido.

• Copia de seguridad de la base de datos resultante (ERPVacia.zip) y empaquetado de todos los dacpacs (ERPVacia.dacpacs.zip), que son la base de datos de referencia que utilizan el resto de configuraciones de pruebas.

Aplicación .NET (ERP_CS)

• Restauración de dependencias exclusivamente desde las fuentes declaradas en net/nuget.config (ver 6.4), con directorio de paquetes propio de la compilación.

• Compilación del proceso auxiliar de 32 bits con MSBuild y de la aplicación principal con dotnet build en configuración Release; publicación autocontenida (--self-contained, win-x64), lo que fija el runtime de .NET distribuido con el producto y elimina la dependencia de la versión instalada en el cliente.

• Compilación de los proyectos de pruebas y ejecución de las pruebas unitarias (6.5), generación de documentación (6.9), ofuscación y firma (6.6).

• Empaquetado del resultado (AhoraERP.zip) excluyendo los símbolos de depuración (*.pdb) y los ficheros de configuración no necesarios en distribución.

Módulos 

• Compilación mediante MSBuild a partir de un manifiesto generado (CompileERPAuto.xml); los archivos de proyecto _auto.vbp se generan por script y no se editan a mano.

• Registro temporal de las librerías COM firmadas AhoraCertificados y AhoraDispositivos, obtenidas como artefactos fijados (pinned) de sus propias configuraciones, y desregistro y borrado al finalizar.

• Generación del instalador y desinstalador con NSIS con comprobación explícita de existencia del ejecutable resultante (<fail unless=…>): la ausencia del instalador hace fallar la compilación.

Instalador de la versión (ERP_Version5)

• Ensamblado del instalador NSIS "Instalador Ahora ERP X.Y.Z.H.exe" a partir de los artefactos verificados de las dependencias: aplicación .NET ofuscada y firmada, base de datos, TechFun, actualizador, traductor, API, listados, plantillas y declaración responsable firmada.

• Firma digital del instalador (6.6) y generación de los paquetes NuGet de distribución (6.8).

6.4. Gestión segura de dependencias

• Fuentes NuGet controladas. El archivo net/nuget.config versionado fija las únicas fuentes admitidas: el repositorio oficial nuget.org, los repositorios corporativos nuget.ahorabh.com y nugetbeta.ahorabh.com y el repositorio privado autenticado de DevExpress. La restauración en el agente utiliza este archivo y no la configuración global de la máquina.

• Herramientas con versión fijada. NuGet 4.9.3, dotnet-sonarscanner 11.2.1 y CycloneDX 6.2.0 se instalan en versiones concretas, evitando cambios de comportamiento no controlados en la cadena.

• Componentes internos fijados. Las librerías AhoraCertificados, AhoraDispositivos y la utilidad GeneradorVacia se consumen con la regla lastPinned: solo entran en la versión compilaciones marcadas expresamente como fijadas por el equipo, no la última disponible.

• Inventario de software (SBOM). En cada análisis de ERP_SAST se genera el SBOM en formato CycloneDX 1.6 de la aplicación y se envía a la instancia corporativa de Dependency-Track, que evalúa de forma continua las vulnerabilidades conocidas (CVE) de los componentes de terceros incluidos en el producto (ver 6.7).

6.5. Verificación y pruebas

La cadena ejecuta cuatro niveles de prueba, cada uno en su propia configuración y con su propia base de datos efímera. Todos los resultados se publican en formato .trx y TeamCity los interpreta (XML Report Processing) para mostrar, historizar y comparar los resultados prueba a prueba.

Los niveles de prueba son bloqueantes: ERP_Version5 depende de ERP_SQL_Tests y ERP_NET_TestUpdate con política CANCEL, y la configuración ERP depende además de ERP_CS_TESTS_UI. Un fallo en cualquiera de ellos impide la generación de la versión.

6.6. Protección de binarios: ofuscación y firma de código

• Ofuscación. El paso Ofuscar código de ERP_CS procesa el resultado publicado con Obfuscar según la configuración versionada net/obfuscar.xml, dificultando la ingeniería inversa del producto. El fichero de correspondencia Mapping.txt se conserva como artefacto de la compilación, lo que permite al equipo interpretar trazas de error de producción sin distribuir símbolos.

• Firma de código. El ejecutable AhoraERP.exe (en ERP_CS) y el instalador (en ERP_Version5) se firman con el certificado de firma de código corporativo de la compañía mediante DigiCert Software Trust Manager (smctl con signtool). La clave privada reside en el servicio de gestión de claves y nunca en los agentes. El paso comprueba la salud del servicio (smctl healthcheck) y analiza el registro de firma: cualquier resultado FAILED hace fallar la compilación.

• Declaración responsable Verifactu firmada. La configuración ERP_DeclaracionResponsable compila y ejecuta la utilidad que genera el PDF de la declaración responsable exigida por la normativa Verifactu, firmado electrónicamente con el certificado de la compañía y la versión exacta del producto, y lo incorpora al instalador.

6.7. Análisis estático y de composición de software (SAST/SCA)

La configuración ERP_SAST ejecuta el script versionado erp-net-analisis-calidad.ps1 sobre la misma revisión que el resto de la cadena, reutilizando los resultados de las pruebas de interfaz:

• SonarQube. Análisis estático del proyecto ERP Estandar en la instancia corporativa de SonarQube mediante dotnet-sonarscanner, con exclusión de código generado, importación de la cobertura (formato VS Coverage XML) y de los resultados de pruebas (.trx), y análisis por rama para las ramas de trabajo. El script consulta el quality gate a través de la API y guarda el veredicto y sus condiciones (sonarqube-quality-gate.json) como artefacto.

• Dependency-Track. Generación del SBOM CycloneDX del producto y envío a Dependency-Track; el script espera al procesado del inventario y recoge las métricas de vulnerabilidades. Este análisis se ejecuta en las compilaciones de la rama de versión 5.0.0.

• Resultados como artefactos. Todos los registros (begin/end del scanner, quality gate, SBOM) se publican como artefactos de la compilación para su auditoría posterior.

Los tokens de acceso a SonarQube y Dependency-Track se almacenan como parámetros protegidos del proyecto en TeamCity (ver 6.10).

Configuración actual. El análisis SAST/SCA se ejecuta en cada compilación de versión en paralelo al resto de la cadena, con política RUN: sus hallazgos se gestionan en SonarQube y Dependency-Track sin bloquear la publicación. El script admite el modo bloqueante por quality gate (parámetro FallarSiQualityGateKO) para su activación cuando el equipo lo decida.

6.8. Generación de artefactos

Todos los resultados se generan de forma automatizada y versionada con el número de compilación, y quedan almacenados en el servidor de integración asociados a la ejecución que los produjo. Artefactos de la compilación 3710 (v5.0.0.146):

• Instalador Ahora ERP 5.0.0.146.exe — Instalador NSIS firmado

• AhoraERP.MSI / .EXE / .DB / .BAK / .Code / .Reports / .Plantillas / .TPV .5.0.0.146.nupkg — Paquetes de distribución y actualización

• Actualizador.5.0.0.146.nupkg, Actualizador(x86).zip — Componente de actualización

• ERPVacia.zip, ERPVacia.dacpacs.zip — Base de datos de referencia y modelo dacpac

• Listados.zip, Plantillas.zip, Traductor.zip — Informes, plantillas de importación y traductor

• changelog.txt, changelog-sql.txt, releasenotes.txt — Trazabilidad de cambios (ver 6.9)

• output.mp4 — Vídeo de novedades de la versión

• version.txt — Número exacto de versión construido

En las configuraciones intermedias se conservan además Mapping.txt (correspondencia de ofuscación), DocumentacionAPI.zip, Cobertura.zip, los resultados .trx, las capturas y vídeos de las pruebas de interfaz, el script de hotfix generado y las copias de seguridad de las bases de datos actualizadas en la prueba de actualización.

6.9. Documentación técnica y notas de versión automatizadas

• Documentación de la API. En las compilaciones oficiales, ERP_CS genera con DocFX la documentación de la API pública del núcleo (obligatoriamente documentado con comentarios XML) y la publica como DocumentacionAPI.zip.

• Changelog. ERP_Version5Changelog construye el changelog de la versión y el changelog detallado de objetos SQL a partir de las etiquetas Git y de las issues de GitLab asociadas a cada hotfix, asegurando la trazabilidad entre versiones y facilitando las auditorías de cambios.

• Release notes. ERP_SQL_Hotfix5 genera las notas de versión de los últimos hotfixes a partir de la sección Notas de versión de las issues, que las plantillas obligan a cumplimentar.

• Vídeo de novedades. ERP_Version5_VideoNovedades descarga las issues de tipo Nuevo desarrollo cerradas en el hito de la versión y genera automáticamente un vídeo con las nuevas funcionalidades siguiendo la guía de estilo versionada, que se distribuye con la versión.

6.10. Gestión de secretos y credenciales

• Parámetros protegidos. Los tokens de GitLab, SonarQube y Dependency-Track, la contraseña del certificado de firma de la declaración responsable, las credenciales del entorno de pruebas de Verifactu y los tokens de los entornos de incidencias se definen en TeamCity como parámetros de tipo password, ocultos en la interfaz y en los registros y de solo lectura para las configuraciones.

• Autenticación sin contraseñas. El acceso al repositorio se realiza con clave SSH gestionada por TeamCity; el acceso a SQL Server en los agentes utiliza autenticación integrada de Windows; las llamadas del propio TeamCity usan las credenciales de sesión que el servidor inyecta en cada compilación.

• Claves de firma fuera de los agentes. La clave privada de firma de código se custodia en DigiCert Software Trust Manager; en el agente solo reside el certificado público.

• Configuración generada, no versionada. Las cadenas de conexión de las pruebas se inyectan en tiempo de ejecución con la base de datos efímera de la compilación (6.1), de modo que el repositorio no contiene credenciales de entornos reales.

6.11. Entornos de prueba y publicación controlada

Entorno de pruebas por issue. La configuración ERP_Deploy_Testing despliega automáticamente cada rama de trabajo en el servidor de entornos de incidencias: restaura la base de datos generada por la propia compilación, despliega la aplicación y el actualizador, carga datos de demostración y publica un comentario en el merge request de GitLab con la ubicación del entorno. Si la issue indica una base de datos de origen, se lanza además su actualización a la compilación de la rama, validando el camino de actualización antes de la integración.

Compilación nocturna de las ramas de versión. Las ramas 5.0.0, 5.1, develop y 5.0.0.remsa se compilan de forma programada cada noche a las 00:00 únicamente si contienen cambios pendientes, lo que garantiza que toda la cadena de pruebas y análisis se ejecuta como máximo un día después de cada integración.

Publicación oficial bajo aprobación humana. La generación de una versión distribuible requiere lanzar ERP_Version5 con el parámetro Commit Git (DoCommit=1) activado por una persona autorizada. Solo en ese caso se ejecutan la firma de código, la confirmación y etiquetado en Git, la generación de la documentación y los paquetes NuGet definitivos. Las compilaciones de ramas de trabajo y las nocturnas producen artefactos de verificación pero nunca firman ni etiquetan. La publicación en el repositorio NuGet corporativo (nuget.ahorabh.com) se realiza como acción posterior deliberada sobre los paquetes ya verificados.

6.12. Cierre seguro y limpieza

Todas las configuraciones terminan con pasos de limpieza configurados en modo ejecutar siempre o ejecutar aunque fallen pasos anteriores, de forma que un fallo intermedio no deja residuos en los agentes:

• Eliminación de las bases de datos efímeras de la compilación (SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE), incluidas las bases de datos intermedias de la prueba de actualización.

• Finalización de los procesos AhoraERP y AhoraERPAux y de los procesos con ficheros abiertos en los directorios de despliegue; borrado de los directorios de binarios de pruebas y de la API desplegada.

• Desregistro de las librerías COM y eliminación de todos los binarios (.exe, .dll, .ocx, .oca) del agente.

• Checkout limpio en la siguiente ejecución (6.1).

7. Auditoría y trazabilidad

Cada etapa del SDLC queda registrada en el sistema de integración continua, lo que permite auditar para cualquier versión distribuida:

• El commit exacto del repositorio con el que se construyó, común a toda la cadena, y la etiqueta vX.Y.Z.H presente tanto en Git como en la compilación.

• El agente, los tiempos de inicio y fin y el registro completo de cada uno de los pasos de las 15 configuraciones.

• Los resultados de las pruebas prueba a prueba, con histórico y detección de regresiones, y las evidencias gráficas (capturas, vídeos) de las pruebas de interfaz.

• Los artefactos generados, incluidos los informes del análisis de seguridad, el quality gate, el SBOM y el fichero de correspondencia de la ofuscación.

• El estado publicado en GitLab para cada commit y los comentarios automáticos en los merge requests.

• El changelog que relaciona cada versión con las issues resueltas y las notas de versión redactadas en ellas.

El encadenado con política CANCEL impide el avance a la generación de la versión si un paso no se ejecuta correctamente, lo que constituye un control de flujo de seguridad y una evidencia de cumplimiento de buenas prácticas DevSecOps.

8. Alineación con estándares

Los controles descritos se alinean con las prácticas de los marcos de referencia de desarrollo seguro más extendidos.

9. Conclusiones

El modelo de desarrollo seguro de Ahora ERP incorpora mecanismos de seguridad, control y trazabilidad en todo el ciclo de vida del software: gobierno del código con revisión obligatoria y guías de codificación segura, construcción reproducible en entornos limpios y aislados sobre una revisión única, verificación en cuatro niveles de prueba bloqueantes, análisis estático y de composición de software, protección de los binarios mediante ofuscación y firma digital, y publicación versionada y etiquetada bajo aprobación humana.

Las evidencias se generan y conservan de forma automática en el sistema de integración continua para cada versión distribuida, lo que permite demostrar la aplicación sistemática de las medidas de protección de la información, control de versiones, auditoría de código y validación de artefactos. El proceso se alinea con los principios de un SDLC seguro según los marcos OWASP SAMM, ISO/IEC 27034 y NIST SP 800-218 (SSDF), aportando garantías de integridad, trazabilidad y seguridad del software producido.

Anexo A. Inventario de configuraciones de la cadena

Configuraciones del proyecto ERP del servidor de integración continua que forman el árbol de ERP_Version5, con los pasos que ejecutan y los artefactos que producen.

Anexo B. Glosario

Ahora Soluciones · Ciclo de Vida de Desarrollo Seguro de Ahora ERP · Documento 1.0 · Datos obtenidos del servidor de integración continua y del repositorio del producto el 15 de septiembre de 2026.