DevOps durante el proyecto: control de código, CI/CD y despliegue gobernado en implementaciones SAP S/4HANA

Esta guía continúa la serie de AGT sobre DevOps en proyectos SAP S/4HANA y está dirigida a líderes técnicos, arquitectos y equipos de construcción en utilities, oil & gas y empresas de tecnología en América Latina. Mientras la primera guía de la serie abordó cómo gobernar la fase de planificación, esta se enfoca en el momento donde ese gobierno se pone a prueba: la construcción, integración y despliegue del código durante el propio proyecto, y cómo esa disciplina evita que la deuda técnica infle el TCO antes incluso de llegar al go-live.

Fundamento conceptual

En un escenario típico de desarrollo para SAP S/4HANA —por ejemplo, una app Fiori con servicios OData—, los desarrolladores ABAP crean y modifican código usando abapGit, lo que permite rastrear cambios, revertir versiones anteriores y colaborar entre equipos. Una vez confirmados los cambios, comienza el proceso de build: abapGit puede exportar el código del repositorio Git como una solicitud de transporte, que luego se importa al sistema de QA para pruebas. Las herramientas de desarrollo ABAP basadas en Eclipse aportan resaltado de sintaxis, autocompletado y depuración, y el ABAP Test Cockpit permite ejecutar pruebas unitarias y generar reportes que identifican defectos antes de avanzar.

Para las fases de liberación y despliegue, una vez completadas la construcción y las pruebas, se utilizan CTS, CTS+ y gCTS —o un pipeline de CI/CD configurado con las opciones vistas en la fase de planificación— para mover los cambios entre los sistemas de desarrollo, QA y producción. CTS+ extiende esta gestión a objetos no-ABAP, proveyendo secuenciación automática de transportes y procesamiento en paralelo; gCTS permite gestionar ese mismo flujo con comandos estándar de Git, incluyendo ramificación y fusión para trabajar varios cambios en simultáneo antes de consolidarlos en una única solicitud de transporte.

En paisajes SAP BTP, la fase de desarrollo se apoya en SAP Business Application Studio —un entorno de desarrollo en la nube con soporte para SAPUI5, SAP Fiori, Node.js, Java, entre otros, con plantillas, generación de código base e integración con Git— y en el SAP Cloud Application Programming Model para construir, probar y desplegar aplicaciones cloud-native. Para la liberación y el despliegue, SAP Cloud Transport Management gestiona el ciclo de vida de las aplicaciones y el transporte de cambios entre distintos entornos y proveedores cloud de forma más estandarizada que un proceso manual. En la práctica actual, Cloud Transport Management añade transparencia al historial de auditoría de cambios —quién hizo qué cambio y cuándo— y permite separar responsabilidades: un desarrollador dispara la propagación de un cambio, mientras que el transporte resultante lo gestiona un equipo de operación central [4].

En paisajes cloud puros dentro de SAP BTP, ABAP Environment, la fase de calidad se apoya en SAP Cloud ALM para gestión de pruebas: la herramienta soporta el alcance de pruebas, testing manual y automatizado, y el monitoreo de la ejecución de pruebas, con aplicaciones de planificación, preparación y ejecución integradas entre sí. Incorporar esta fase de calidad temprano en el ciclo de desarrollo permite recibir retroalimentación antes, lo que ayuda a resolver errores previo al release y contribuye a un producto más robusto.

Project “Piper” es un framework de código abierto que provee un conjunto de herramientas y plantillas para construir pipelines de CI/CD en sistemas ABAP usando Jenkins, incluyendo plugins y scripts para automatizar la construcción, prueba y despliegue de aplicaciones ABAP. Soporta distintos sistemas ABAP —incluido SAP S/4HANA— y ofrece plantillas para varios tipos de aplicación, con capacidades de gestión automatizada de transportes, gestión de código fuente y testing automatizado. La conexión entre el pipeline y el sistema de desarrollo ABAP puede hacerse por OData o por Remote Function Call, según la versión y el escenario técnico del sistema. En su forma actual, el servicio SAP Continuous Integration and Delivery en BTP ofrece una vía guiada por interfaz gráfica para configurar CI/CD sin necesidad de alojar una instancia propia de Jenkins, con soporte de infraestructura provisto por SAP bajo acuerdos de nivel de servicio, mientras que Project “Piper” se sostiene con soporte comunitario vía GitHub [7]. De hecho, bajo el capó, el propio servicio SAP CI/CD utiliza las mismas etapas y pasos de Project “Piper” [8], lo que significa que la elección entre ambos no es tanto una diferencia de motor técnico sino de quién asume el soporte y cuánta infraestructura propia se quiere administrar.

El principio de “fail fast” durante la construcción se sostiene en prácticas concretas: implementar CI/CD para desplegar y probar cambios de código en un entorno similar a producción; fomentar una cultura de experimentación segura para el equipo; invertir en testing automatizado para detectar defectos antes de que escalen; usar monitoreo y logging con agregadores de logs y herramientas de APM para visibilidad en tiempo real; y sostener metodologías ágiles con tableros que expongan cuellos de botella durante el propio sprint, no después del release.

Aplicación práctica

En utilities y oil & gas de LATAM, es habitual que el proyecto de construcción no ocurra sobre un paisaje homogéneo, sino sobre una combinación de núcleo S/4HANA on-premise o privado y extensiones cloud sobre BTP —por ejemplo, apps Fiori para cuadrillas de campo, integraciones con medición inteligente (AMI) o portales de autogestión para clientes regulados—. En ese contexto, la decisión de la fase de planificación sobre qué mecanismo de transporte usar para cada componente se pone a prueba durante la construcción: mezclar CTS clásico para el núcleo ABAP con Cloud Transport Management para las extensiones BTP, sin una orquestación central que los sincronice, es una fuente común de despliegues inconsistentes entre ambientes.

Para equipos con presupuesto acotado, el servicio SAP Continuous Integration and Delivery ofrece una vía de entrada de menor costo operativo que mantener Jenkins propio, precisamente porque SAP asume el soporte de infraestructura bajo SLA [7]. Esto es relevante en LATAM, donde sostener una plataforma Jenkins autoadministrada compite por recursos escasos de TI con otras prioridades del proyecto. Adoptar Project “Piper” como capa de plantillas reutilizables —ya sea desde el servicio gestionado o desde una instalación propia— permite estandarizar pipelines entre distintos equipos de desarrollo, algo especialmente valioso cuando la implementación involucra a un integrador local y a especialistas remotos trabajando en paralelo.

La ausencia de un motor de automatización nativo en SAP Cloud ALM —ya señalada como decisión de planificación en la guía anterior de esta serie— se materializa durante la construcción como un punto de fricción real: los equipos deben tener resuelto, antes de escribir el primer caso de prueba automatizado, con qué herramienta se ejecutará esa automatización y cómo se integrará con la orquestación de Cloud ALM. Postergar esa decisión durante la construcción obliga a elegir entre avanzar con testing manual —que no escala en proyectos con cientos de transacciones regulatorias por probar— o detener el sprint para resolver una integración que debió cerrarse antes.

Un anti-patrón frecuente en proyectos LATAM con presión de cronograma es promover cambios ABAP directamente entre ambientes sin pasar por gates de calidad automatizados, apoyándose únicamente en revisión manual de código. Esto contradice el principio de fail fast: en lugar de detectar errores en minutos dentro de un pipeline, se detectan semanas después en un ambiente de aceptación, cuando el costo de corregirlos —y el impacto en el cronograma del proyecto— ya es considerablemente mayor.

Mejores prácticas y consideraciones

• Centralizar la orquestación del transporte, incluso en paisajes híbridos. Definir un único punto de gobierno que sincronice CTS/CTS+/gCTS con Cloud Transport Management evita que cada equipo (ABAP, Fiori, BTP) despliegue con su propio ritmo y genere inconsistencias entre ambientes.
• Resolver la automatización de pruebas antes de escribir el primer caso de prueba. Dado que SAP Cloud ALM orquesta pero no ejecuta pruebas automatizadas por sí solo, la herramienta de ejecución debe estar decidida e integrada desde el inicio de la construcción, no descubierta a mitad de sprint.
• Usar Project “Piper” o el servicio gestionado de SAP CI/CD según la capacidad real del equipo de sostener infraestructura propia. Ambos comparten el mismo motor de pasos y etapas; la diferencia real está en quién asume el soporte y el costo operativo de mantenerlo.
• No sacrificar los gates de calidad automatizados por presión de cronograma. Cada promoción de código que se salta un gate automatizado traslada el costo de detección de errores de minutos a semanas, y ese costo se acumula silenciosamente hasta el go-live.
• Aprovechar el rastro de auditoría de Cloud Transport Management como activo de compliance, no solo como conveniencia técnica. En utilities y oil & gas, donde los procesos suelen estar sujetos a auditoría regulatoria, la trazabilidad de quién cambió qué y cuándo tiene valor más allá de la gestión de versiones.
• Anti-patrón a evitar: tratar la elección entre CI/CD gestionado por SAP y Project “Piper” autoalojado como una decisión puramente técnica. Es, ante todo, una decisión de capacidad operativa del equipo y de a quién se transfiere la responsabilidad de mantener la infraestructura del pipeline durante y después del proyecto.

Referencias

1. SAP S4HANA System Conversion Guide
2. Materials Management with SAP S4HANA Functionality and Configuration
3. Joe Darlak, Jesper Christensen - SAP HANNA
4. Integrate SAP Cloud Transport Management Into Your CI/CD Pipeline — Project “Piper” — https://www.project-piper.io/scenarios/TMS_Extension/
5. Custom Extensions in SAP S/4HANA Implementations - A Practical Guide for Senior IT Leadership
6. SAP Master Data Governance
7. Project “Piper”: Continuous Delivery for the SAP Ecosystem — https://www.project-piper.io/
8. btp-cap-multitenant-saas — Setup CI/CD for Project (SAP Samples, GitHub) — https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md
9. Migrating to SAP S4HANA