DevOps III

Realmente, no se trata exclusivamente de un problema de predecibilidad o de que ambas partes no se hayan tenido en cuenta a la hora de programar sus tareas (que lo es), sino que hay, además, un aspecto importante que hay que tener en cuenta y es que cada paso a producción genera incertidumbre.

Una nueva versión con problemas puede afectar no solo a su conjunto de usuarios, sino que puede comprometer la disponibilidad o el rendimiento de otros sistemas con los que comparte infraestructura o incluso afectar a la seguridad.

No ayuda el hecho de que los desarrolladores tengamos malas prácticas, no probemos los productos lo suficientemente o no nos preocupemos por el impacto que tienen nuestros desarrollos sobre la infraestructura de sistemas (“¿optimizar?, ¿para qué si la “chapa” es barata?”).

Podemos luchar contra esa incertidumbre, pero no podemos luchar contra la aparición de nuevas versiones ni con la ventaja competitiva (o de ahorro de costes) que tiene liberar y poner en producción una nueva versión a tiempo, porque lo que es seguro es que nos movemos en un contexto donde el cambio es inevitable y necesario.

Por esta razón, los Departamentos de Sistemas no pueden convertir el proceso de aceptación de las aplicaciones en algo lento, farragoso y con continua devolución de versiones a desarrollo por el incumplimiento de ciertas normas que no aportan valor a nadie.

1 comentario
  1. Pingback: DevOps I | Jummp

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: