Los acceptance test deben correr en el ambiente de staging y el de producción.
“Testear todos los ambientes, en todo momento”.
Lanza a producción con seguridad implementando un flujo CI/CD claro en Jenkins: usa un único artifact, encadena jobs y ejecuta acceptance tests en cada ambiente. La clave está en la repetibilidad del pipeline y en confiar en las pruebas como tu norte.
¿Cómo llevar el mismo artifact de staging a producción?
Usa el mismo pipeline que ya funcionó en staging para producción. Si trabajas con un Jenkinsfile, el código es el mismo; solo cambia el job que invocas. La confianza proviene de usar el mismo artifact en toda la cadena.
Idea clave: si el artifact es único, puedes lanzarlo a múltiples ambientes sin cambios y con la misma trazabilidad.
¿Cómo encadenar jobs en Jenkins con post build action?
El encadenamiento asegura que solo se despliegue a producción cuando el build está estable y los acceptance tests pasaron. Primero crea el job de producción y luego configuras el de staging para llamarlo.
Práctica recomendada: el acceptance test debe poder romper el build. Si falla, no se despliega a producción.
¿Por qué correr acceptance tests en staging y producción?
Porque los ambientes nunca son idénticos. Aunque staging “imite” producción, hay diferencias de configuración: URL, parámetros de conexión y base de datos. Ejecutar la batería de tests en todos los ambientes te dice dónde está el problema.
Habilidades y keywords reforzadas dentro del flujo:
¿Tienes dudas sobre cómo parametrizar el artifact o encadenar tus jobs en Jenkins? Comparte tu caso en comentarios y afinamos tu pipeline juntos.
Lanza a producción con seguridad implementando un flujo CI/CD claro en Jenkins: usa un único artifact, encadena jobs y ejecuta acceptance tests en cada ambiente. La clave está en la repetibilidad del pipeline y en confiar en las pruebas como tu norte.
Usa el mismo pipeline que ya funcionó en staging para producción. Si trabajas con un Jenkinsfile, el código es el mismo; solo cambia el job que invocas. La confianza proviene de usar el mismo artifact en toda la cadena.
Idea clave: si el artifact es único, puedes lanzarlo a múltiples ambientes sin cambios y con la misma trazabilidad.
El encadenamiento asegura que solo se despliegue a producción cuando el build está estable y los acceptance tests pasaron. Primero crea el job de producción y luego configuras el de staging para llamarlo.
Práctica recomendada: el acceptance test debe poder romper el build. Si falla, no se despliega a producción.
Porque los ambientes nunca son idénticos. Aunque staging “imite” producción, hay diferencias de configuración: URL, parámetros de conexión y base de datos. Ejecutar la batería de tests en todos los ambientes te dice dónde está el problema.
Habilidades y keywords reforzadas dentro del flujo:
¿Tienes dudas sobre cómo parametrizar el artifact o encadenar tus jobs en Jenkins? Comparte tu caso en comentarios y afinamos tu pipeline juntos.
Los acceptance test deben correr en el ambiente de staging y el de producción.
“Testear todos los ambientes, en todo momento”.
Continuous Integration es testear continuamente en todos los ambientes.
Hola David, cuando hablas de pruebas, son las pruebas unitarias del desarrollador? o puede implementar algunos escenarios del analista de pruebas?
La visualización y el proceso que se puede observar en Console Output me parece excelente ya que podemos manejar en tiempo real como va el proceso y la respuesta que nos debe arrojar y en caso que no pase nos logra indicar en que parte tenemos el error
👉 Un artifact es el resultado final de tu proceso de build que está listo para usarse o desplegarse.
por que no hablan de observabilidad?
Esta parte también esta integrada en gitlab
Recomiendan Jenkins o Gitlab para implementar CI/CD en un entorno on premise?
¿Alguien lo hizo como Jenkinsfile que pueda compartir su solución? 🙏🏻