Listo para producción no es listo para el usuario
La entrega continua es el penúltimo objetivo de las organizaciones que adoptan DevOps. No es el objetivo final, porque eso significaría un despliegue continuo.
Se hace mucho ruido en los callejones de DevOps con respecto a la capacidad de entregar software listo para producción decenas de veces al día.
Qué lindo.
La razón por la que esto no me entusiasma demasiado es que, en la mayoría de las organizaciones empresariales (incluso aquellas que adoptan DevOps), la entrega es solo el primer paso en la fase de "llegada al mercado" del ciclo de vida de las aplicaciones. Pocas aplicações están “listas” para los usuarios en el momento de la notificación final de compilación y lanzamiento. Todavía tiene que implementarse en producción, donde una variedad de procedimientos y políticas garantizarán su entrega adecuada a los usuarios.
Mira, la implementación continua es (debería ser, podría ser, será) el objetivo final de las organizaciones que adoptan DevOps. Incluso si no lo es, el problema más amplio es que simplemente entregar a producción no hace que una aplicação sea “entregada” a sus destinatarios. Esto requiere implementación, en producción, junto con todos los servicios necesarios para escalar, proteger y acelerar la aplicação para garantizar que presente una experiencia de aplicação óptima a los usuarios, tanto corporativos como consumidores.
Eso podría significar equilibrar la carga para garantizar la escala y la disponibilidad. Casi con toda seguridad significa seguridad, al menos en el firewall, con suerte seguridad de la aplicación y posiblemente más. También puede implicar acceso e identidad. Quizás no sea así para las aplicaciones orientadas al consumidor, pero es posible que las orientadas a la empresa deban incluirse en SSO o políticas federadas para garantizar un acceso fluido y sin problemas. También puede requerirse velocidad en términos de rendimiento.
Todas estas cosas deben suceder antes de que una aplicación esté “lista” para los usuarios. Y la “producción” lo sabe. Del 32% de los encuestados en nuestro Informe sobre el estado de la entrega de aplicação de 2017 que se clasificaron en la categoría “tenemos entre 1 y 10 de estos servicios implementados”, la mayoría se ubicó en el lado “tenemos más de 5”, y el 63% indicó que actualmente tienen implementados entre 6 y 10.
Independientemente de los problemas de “implementación continua”, estos servicios son fundamentales para garantizar que las aplicaciones estén “listas para los usuarios” y no solo “listas para la producción”.
Entregar a producción innumerables veces es genial, pero entregar al mercado con mayor frecuencia es el verdadero objetivo. Incluso si DevOps llega a producción (¡adelante! ¡el agua está bien, de verdad!) para manejar la aplicación y su infraestructura inmediata, todavía habrá servicios ascendentes que deben aprovisionarse, configurarse y probarse antes de que la aplicación pueda realmente considerarse "entregada".
Lanzar aplicaciones a producción con mayor frecuencia en realidad no afecta el cronograma de implementación. Hay una razón por la que los proyectos de código abierto tienen una rama “estable” y una opción de “compilación nocturna”. Claro, puedo obtener lo último y lo mejor, pero como usuario preferiría la opción "estable", porque tener aplicaciones que se rompen o se bloquean aleatoriamente no contribuye de ninguna manera a una experiencia positiva de la aplicação .
El cronograma de implementación debe ser impulsado por el negocio e implementado por TI, y eso significa lograr que TI (las cuatro operaciones) participen para comenzar a automatizar la mayor parte posible del proceso. Porque una aplicación no está preparada para el usuario, sino que está protegida y acelerada por los servicios que la rodean en producción.