#130 varios despliegues al día los hace cualquiera, pero nunca estarán exentos de bugs, sobre todo, cuantas más integraciones existan.
El blue Green lo aplican sobre una única infra pero por pods, con unas reglas que validan, en mi opinion casos básicos generalmente (respuestas https, etc.)
Apta ser justos en QA he visto colar bugs inmensos, automatizar QAs es lo más inteligente en cuanto a costes y ayuda a ir más seguro, pero no seguro al 100%.
A mí la tendencia que más miedo me dan las empresas grandes es que están cogiendo lo peor de las startups para hacer desarrollos rápidos, que es tener equipos super multidisciplinares en los que se supone que todos saben de todo y son responsables de todo, obviando en muchos casos el crear frameworks e incluso sobreabusando de los lambdas.
#105 es cierto que dividir en pequeños equipos reduce ciertos tipos de errores del dia a día, pero también complica funcionalmente un ya de por si complejo sistema. Además, alguien debe velar porque todo en conjunto tenga coherencia, y crear esos test es muy caro, ya que debes tener un entorno igual que replique todas las interacciones. Es más caro lo que ha pasado? Si, pero nadie quiere ese gasto hasta que peta todo
#73 a mi modo de ver, a veces puedes correr y otras tienes que madurarlo. Dicho esto nunca vas a probar todo al 100% porque es imposible en un mundo real. Pero si, todo se arregla ahora con la "beta"
#26 pues las empresas que están en azure y demás clouds replicarán, duplicarán y harán el sw más defensivo, gastando el doble o el triple, durante un tiempo claro, cuando vean lo que gastan para un caso qie se da cada x meses o años, pasaran de todo otra vez (confiando en test rápidos, test de integración y no probando nunca en su conjunto) porque replicar todo es muy muy caro
#2 pero es que ahora se ha vendido al mundo que hacer desarrollos rápidos en micros y evoluciones pequeñas que pasan unos test super rápidos sirve para todo. Es más, como son tan pequeños es fácil revertirlos, y como todo está replicado y se hace blue Green canary no afectas más que un poquito en el peor de los casos.
Es el martillo de oro aplicado al ci/CD, esto está muy bien para muchas apps, pero para software industrial y software crítico no sirve, repito no sirve.
Después de la ultima noticia con foto de hace una década que comparten coronel baños y Rubén Gisbert salida de la fabrica de bulos rusos... Lo que tienen que hacer es investigar sus cuentas y esas donaciones de 500€ de sus directos, y dejarse de historias
#1 pero si no dice nada! Solo está esperando a que Trump llegue y diga que usa le deja a rusia hacer lo que quiera. Es más, deja a europa sola en este fregado, porque elm resto del planeta se desentendera
#9 pero es que comer digno y tener una casa en un pueblo de la España vaciada no necesitas 1080 € al mes + pluses por hijos, más comedor gratis, medicinas gratis, etc.
Ahora que si quieren ayudas para vivir en una ciudad en la que vale un zulo 200k mínimo, pues ya no estamos hablando de algo digno, es otra cosa, y a mí ya no me parece normal
#13 la verdad, los que tienen la vida resuelta, tienen contactos y hacen trabajos esporádicos, o negocios en los que ganan más que yo trabajando como un cab...
#7 lo que cuentas de las empresas es habitual en toda empresa grande, ya que la gente llega a ganar tanto dinero que su única preocupación es seguir ganándolo, por ejemplo, creando métricas.
El problema de las metricas es que la gente ya solo intenta salir en ellas bien, no mejorar la empresa y cuando la métrica es cantidad de proyectos innovadores, ya no se preocupan de que triunfen etc. Solo de crear nuevos proyectos aunque sean mamarrachadas que no llegan a producción o no producen nada
El blue Green lo aplican sobre una única infra pero por pods, con unas reglas que validan, en mi opinion casos básicos generalmente (respuestas https, etc.)
Apta ser justos en QA he visto colar bugs inmensos, automatizar QAs es lo más inteligente en cuanto a costes y ayuda a ir más seguro, pero no seguro al 100%.
A mí la tendencia que más miedo me dan las empresas grandes es que están cogiendo lo peor de las startups para hacer desarrollos rápidos, que es tener equipos super multidisciplinares en los que se supone que todos saben de todo y son responsables de todo, obviando en muchos casos el crear frameworks e incluso sobreabusando de los lambdas.