Por más sitios que visito… más sale el tema y más posturas diferentes me encuentro. El mundo está dividido en este tema.
Por un lado, están los que piensan que desarrollo debe poder pasar a producción autónomamente, cuando quiera. Historia de usuario desarrollada, historia de usuario que pasa inmediatamente a producción, a veces con un simple “git push”. Algunos a esto le llaman “Devops”, otros “Continuous Deployment”.
Argumentan que ellos no son de los de ¿Tardaríais mucho en pasar a producción un cambio en sólo una línea de código? No. Aprende entrega continua. Son más del estilo a aquello que contamos del caso de estudio: cómo trabaja Quora en Continuous Deployment o el de Flicker.
Por otro lado, están los que dicen que hasta preproducción OK… pero a producción nada, eso es sagrado, ahí se necesita autorización y revisión por un externo. ¿Razones? Si desarrollo pasa a producción cuando quiere, lo que quiere, aparecen varios riesgos, principalmente:
– Se pasaría a producción cualquier desarrollo que a cualquiera se le pase por la cabeza, a veces sin una necesidad de negocio detrás. Empiezan a crecer descontroladamente las aplicaciones en producción. Muchas de ellas no eran realmente necesarias para negocio.
– Algunos desarrollos no son conscientes de las implicaciones que poner algo en producción tiene en otras aplicaciones: dependencias, se consumen el rendimiento de la máquina, realmente no habían hecho las rigurosas pruebas de aseguraban, etc.
– “Continuous Delyvery” no implica “Continuous Deployment”.
Dejo a un lado a un tercer grupo, los que pasan a producción sin control, sin pruebas que den seguridad o de cualquier manera. Los anteriores dos grupos aseguran que lanzan todo tipo de pruebas antes de pasar a producción.
Bueno, ¿tú que piensas? ¿qué haceis?
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Lo más importante de despliegue continuo son los prerequisitos que se tiene que cumplir un build. Si no hay un proceso automatizado muy riguroso, el despliegue continuo es simplemente el equivalente de un desarrollador trabajando en producción.
Esto incluye:
– Un porcentaje muy elevado de cobertura de pruebas unitarias (+90%)
– Un porcentaje my elevado de cobertura de pruebas de aceptación (+90%)
– Smoke testing
– Pruebas de stress / load
– Despliegue controlado
– Un entorno de preproducción igual a producción
– Un proceso de migración automatica, que esté probado varias veces antes de ejecutarse en producción
– …
Si todo esto está en plazo, no veo ningún inconveniente en desplegar immediatamente en producción. Los argumentos contra despliegue continuo entonces ya no valen:
– «Se pasaría a producción cualquier desarrollo que a cualquiera se le pase por la cabeza» => Esto no debería pasar en ningún caso, independentientemente de despliegue continuo o no, es otro problema
– Algunos desarrollos no son conscientes de las implicaciones que poner algo en producción => Estos problemas se deben detectar durante la fase de pruebas automatizadas
Aparte de esto, si haces despliegue continua, pequeños problemas tampoco son muy graves, ya que se pueden solucionar muy rápidamente
El problema realmente viene cuando haces despliegue continuo sin todos estos controles. Lo dificil es saber cuando tus controles son bastante para poder desplegar continuamente.
¿Quien hace el pase a producción asume todas las consecuencias que se puedan derivar de ese paso a producción? Si es así, adelante. Si no, esa autonomía no me sirve.
Hola Javier,
¿Qué tal una mezcla? o sea, para ciertas situaciones como bug-fixes, parches, o mejoras, tener un enfoque de devops. Estas son las que más queman y más rápido hay que liberar.
Para nuevas funcionalidades, nuevas aplicaciones, o cosas más grandes, entonces hacerlas a través de un proceso un poco más pesado, más revisado (con foco en el negocio, con verificación de impacto sobre otros sistemas, etc.).
He visto también distintas dinámicas en distintas empresas, y tal vez varía mucho de acuerdo al tipo de aplicación.
Saludos
En muchos casos, sí sería posible. Pero en otros, aunque se den todas las condiciones que comenta Kenneth, no lo es. Hay tres casos muy simples que se me ocurren:
a) Cuando el contenido a desplegar contiene información restringida o que depende del tiempo. Ejemplo: ofertas en la web, o publicar una compra/fusión entre dos empresas. Sería divertido ver cómo se hunde una empresa o se fastidia su venta, por publicar su compra antes de lo debido.
b) Dependencias: En un entorno donde hay varios proveedores desarrollando, no se puede desplegar una nueva versión de un servicio web (por ejemplo), ya que yo sólo puedo probar que funciona MI DESARROLLO, no el de los demás proveedores. Si los que hacen las aplicaciones que consumen el servicio, no despliegan al mismo tiempo sus desarrollos…tendremos un grave problema.
c) Ventanas de tiempo: es habitual solicitar ventanas de tiempo para pruebas en entornos complejos. Si yo necesito 2 o 3 días para hacer múltiples pruebas (unitarias, funcionales automatizadas, manuales, rendimiento, etc), no me apetece que otro dedida subir cambios y me encuentre con un entorno que no espero, con juegos de datos que son los que yo he preparado, etc, etc.
Los 3 casos que comentas van incluídos en los que puse:
a) No creo que esto sea un tema de despliegue continuo. El tema es simplemente no integrar lo que no se puede mostrar. Esto se puede hacer mediante branching o feature flags o cualquier otra forma de control. No impide el despliegue continuo
b) Las pruebas de integración automatizadas deberían de detectar estos fallso. Por eso es necessario que hay un entorno de pruebas igual a producción. Si las pruebas de integración no son suficientes, no se cumplen los requisitos para poder hacer despliegue continuo.
c) Haciendo despliegue continuo, todo tipo de prueba debe de ser automático. Entonces, cualquier prueba se debe ejecutar antes de subir a pro. Las pruebas no deberían tardar 2 o 3 días en ejecutarse. Si el despliegue es continuo y las pruebas se ejecutan frecuentemente, un cambio no puede ser tan grande que probarlo tarda 2 o 3 días.
¿Existe una metodología que dice que todas las pruebas deben ser automáticas? En el área de testing existe un consenso bastante grande sobre esto, diciendo que no es una buena idea, el «sapiens testing» o «testing manual» no debería ser eliminado. Yo no lo haría.
Hola Kenneth, no pretendo ni desmontarte los argumentos (que además entiendo que son correctos) ni atacar los conceptos de integración continua y pruebas automatizadas. Ambos los veo útiles y necesarios, pero veo casos en los que el riesgo hace plantearse dudas.
Tal y como comentas, hace falta primero identificar (lista blanca), las características que hacen un entorno viable para implementar integración continua «de desarrollo hasta producción». Yo por mi experiencia, me gusta también tener (lista negra), casos en los que el riesgo supera al beneficio obtenido por tenerlo todo automatizado.
Por cierto Javier, este artículo estaría muy relacionado con el de Gestión de Configuración y control del código. Como bien dice Kenneth, muchas situaciones se pueden controlar con branching/feature flags para ayudar a evitar que sea necesario tener unos ojos revisándolo todo en producción…siempre y cuando estemos subiendo la versión correcta de todo…