Un pipeline para Windchill se parece al de cualquier otra aplicación empresarial, con dos diferencias: la aplicación es grande y lenta en arrancar, y su configuración importa tanto como su código. Esta es la estructura que usamos y el orden en que la construimos.
1. Control de versiones para todo
Las personalizaciones, los scripts de build, los scripts de despliegue y toda la configuración que se pueda exportar viven en Git. Los cambios llegan mediante pull requests con un segundo revisor. Si no está en Git, el pipeline no puede desplegarlo, y de eso se trata.
2. Compilar una sola vez
El pipeline compila las personalizaciones a partir de un commit etiquetado y genera un único artefacto versionado: un paquete para máquinas virtuales o una imagen Docker para Kubernetes. Ese artefacto se promociona sin cambios de pruebas a producción. Recompilar para cada entorno es la forma en que se cuelan las diferencias.
3. Probar en tres capas
- Pruebas unitarias de la lógica de negocio, que se ejecutan en segundos sin servidor Windchill.
- Pruebas de API que llaman a sus endpoints REST y servicios en una instancia recién desplegada.
- Smoke tests que recorren unos pocos flujos críticos: crear un artículo, hacer check-in de un documento, liberar un cambio.
Windchill tarda en arrancar, así que mantenemos acotada la etapa de pruebas sobre el entorno desplegado. Una batería corta que se ejecuta en cada merge vale más que una larga que se ejecuta una vez al mes.
4. Promocionar con una decisión
El despliegue en producción espera una aprobación, y esa aprobación queda registrada junto con las notas de versión que generó el pipeline. A los auditores les gusta. A los ingenieros también, porque la pregunta de qué cambió y quién lo aprobó se responde en un solo lugar.
5. Verificar y conservar una vuelta atrás
Tras el despliegue, el pipeline comprueba los endpoints de salud y vuelve a ejecutar los smoke tests. El rollback despliega de nuevo el artefacto anterior. Lo probamos con regularidad, porque un rollback que nunca se ha ejecutado es una esperanza, no un plan.
Por dónde empezar
Si hoy sus releases son manuales, empiece por las etapas 1 y 2: Git y un build automatizado. Son las que más riesgo eliminan con menos esfuerzo, y todas las etapas posteriores se apoyan en ellas.