Problemas del staging
- pre-live no es igual a producción
- se forma una cola de releases
- los releases se vuelven demasiado grandes
- falta ownership sobre los cambios
- se deja que el proceso sustituya la responsabilidad
Cómo hace shipping Squeaky
- hacer merge solo de lo que ya puede salir a producción: los cambios se prueban lo suficiente en el entorno local de desarrollo
- usar una estrategia de branching plana: cuando una feature está lista para hacer merge, se hace rebase y testing. Si surge un problema, se hace roll forward
- las features de alto riesgo siempre usan feature flags
- despliegue manual: monitoreo continuo después de los cambios. Monitoreo/logging/alertas aplicados de forma general. Despliegue blue/green
Conclusión
- si se renuncia al entorno de staging para lograr un CI/CD real, se puede construir una forma distinta de pensar sobre cómo hacer shipping de software
- si no hay un buffer antes de que los cambios salgan a producción, hay que tener certeza de que esos cambios son aptos para producción
- hay que tener ownership y poner atención a todos los cambios que uno hace
- se reducen los costos y la complejidad de la infraestructura, y se puede simplificar y acelerar el ciclo de vida de desarrollo
3 comentarios
Pensando en la sensación de seguridad que sentí al construir un entorno de staging dentro de una organización, la verdad es que no me resulta tan fácil empatizar.
Aun así, sí me identifico con las desventajas de que los despliegues se retrasen o de que aumente la cantidad de cambios.
Creo que, con solo existir un entorno de staging, ya tiene valor porque permite verificar que se puede desplegar en otros entornos y que se cumple con la esencia del software reproducible, por así decirlo.
Bueno, no sé si esto deba depender de personas con una "responsabilidad" / "atención" incompletas. Como mínimo, si eres programador de computadoras, ¿no deberías apoyarte en una computadora que funciona perfectamente al menos según lo que se le indica?
Y, ampliando el concepto, staging = para aprobación final (para revisar cosas como si al final coincide con la especificación de la que hablamos, o si al meter datos reales del producto se ve peor de lo esperado, etc.)
dev = para discutir entre desarrolladores y demás personas sobre personal y features (para demos)
es como lo estamos usando.
Mmm... creo que este tipo de problema depende de qué clase de servicio estés desarrollando.
Por más que hagas pruebas, siempre pueden surgir problemas, y hay que evaluar si los usuarios pueden aceptarlo.
En un software como Facebook, donde aunque falle uno piensa “bueno, así es”, este enfoque puede funcionar,
pero si se trata de infraestructura de misión crítica o de un servicio de pago, creo que hay que hacer todo lo posible para que no surjan problemas.