Crear entornos de pruebas de integración para toda la empresa es una práctica frecuente y costosa que lo ralentiza todo. Estos entornos invariablemente se convierten en recursos valiosos que son difíciles de replicar y un cuello de botella para el desarrollo. También proveen de una falsa sensación de seguridad por sus inevitables discrepancias en los datos y configuraciones entre entornos. Irónicamente, la objeción habitual a sus alternativas — ya sean entornos efímeros o múltiples entornos de prueba locales — es su costo. Sin embargo, no se considera el costo de los retrasos causados por los entornos de integración para toda la empresa, como tener equipos de desarrollo en espera de que otros equipos terminen, o a los despliegues de nuevas versiones de sistemas dependientes. En su lugar, los equipos deberían usar entornos efímeros y, preferiblemente, un conjunto de pruebas propias del equipo de desarrollo que puedan ser ejecutadas y descartadas a bajo costo, usando stubs para sus sistemas en vez de réplicas reales. Para otras técnicas que soportan esta alternativa echa un vistazo a pruebas de contrato guiados por el consumidor, desacoplar el despliegue de la publicación, centrarse en el tiempo medio de recuperación y pruebas en producción.
When the enterprise-wide quarterly or monthly releases were considered best practice, it was necessary to maintain a complete environment for performing testing cycles prior to deployment to production. These enterprise-wide integration test environments (often referred to as SIT or Staging) are a common bottleneck for continuous delivery today. The environments themselves are fragile and expensive to maintain, often with components that need manual configuration by a separate environment management team. Testing in the staging environment provides unreliable and slow feedback, and testing effort is duplicated with what can be performed on components in isolation. We recommend that organizations incrementally create an independent path to production for key components. Important techniques include contract testing, decoupling deployment from release, focus on mean time to recovery and testing in production.
When the enterprise-wide quarterly or monthly releases were considered best practice, it was necessary to maintain a complete environment for performing testing cycles prior to deployment to production. These enterprise-wide integration test environments (often referred to as SIT or Staging) are a common bottleneck for continuous delivery today. The environments themselves are fragile and expensive to maintain, often with components that need manual configuration by a separate environment management team. Testing in the staging environment provides unreliable and slow feedback, and testing effort is duplicated with what can be performed on components in isolation. We recommend that organizations incrementally create an independent path to production for key components. Important techniques include contract testing, decoupling deployment from release, focus on mean time to recovery and testing in production.
