Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.
Este artículo es parte de nuestra guía: Guía esencial: Qué debe saber sobre el desarrollo actual de software empresarial

No vuelva a caer en malos hábitos en una organización DevOps

En una organización DevOps, ¿puede todavía establecer límites? ¿Cómo elegir las herramientas adecuadas? Aprenda de estas experiencias antes de hacer el cambio.

Hay mucho que amar sobre DevOps… en teoría. En las implementaciones de la vida real, una organización DevOps está sujeta a las mismas guerras territoriales y herramientas poco adecuadas que las TI tradicionales. También abre TI a nuevos retos, como el aislamiento de los compañeros y los caminos de adopción no estructurados.

"Conforme [los equipos están] probando nuevas herramientas y flujos, nada es perfecto desde el primer momento", dijo Vijaya Kokkili, directora de calidad en CommerceHub, un proveedor de soporte para empresas de comercio electrónico. "Nos hemos tropezado con varios problemas, y aún para algunos no tenemos respuesta".

En los dos años desde que su compañía adoptó DevOps, Kokkili vio tanto los desafíos de la transición y los de la nueva realidad.

"Hemos encontrado que estábamos tratando de poner tantos estándares que hace difícil hacer las cosas", dijo. Los equipos se dieron cuenta de que "no se trataba de esta herramienta o esa herramienta que lo haga funcionar", sino de cómo comunicarse y colaborar y refinar la forma en que está trabajando.

Un nuevo tipo de solitario

Es fácil volver a caer en malos hábitos en una organización DevOps, con un nuevo giro.

Como la mayoría de las organizaciones de TI, los equipos funcionales de desarrollo, base de datos, control de calidad, operaciones y otras áreas de CommerceHub estaban separados físicamente en la oficina. Cuando adoptaron DevOps, crearon equipos multifuncionales con miembros de cada grupo, al tiempo que mantenían a los administradores que supervisaban las áreas funcionales. Los equipos multifuncionales, sin embargo, permanecieron separados en el interior. Por sí mismo, poner algunos desarrolladores con los técnicos de operaciones de TI, el administrador de base de datos, un probador de control de calidad y el director del proyecto no descomponía ningún silo.

"El ingeniero de control de calidad podría ser dejardo de lado por los desarrolladores; ellos no se entienden entre sí [o] hablan el mismo idioma", dijo Kokkili, y no había otra persona de QA allí. El entrenamiento eventualmente alivió esta frustración, enseñando a cada miembro cómo aportar en los puestos de trabajo de los otros.

Una vez que caen las barreras de comunicación, los nuevos departamentos de TI colaborativos deben reforzar el objetivo de todos estos proyectos: una cultura centrada en el cliente.

El equipo informático de la Universidad Estatal de Ohio implementa ITIL con algunos conceptos delgados (lean) y de profesional de gestión de proyectos. DevOps es lo siguiente. Si ITIL es un marco de mejores prácticas para gestionar los cambios de TI, "DevOps consigue un cambio de la cultura", dijo Bob Gribben, director de operaciones de servicio allí.

Mientras tanto, una organización DevOps todavía tiene metas departamentales. Las operaciones de TI tienen objetivos de tiempo de actividad y de utilización, por ejemplo; éstos son diferentes de las metas del dueño del producto para los equipos DevOps multifuncionales. Una cultura centrada en el cliente y en el producto no significa abandonar las métricas de TI.

Compartimos todo, pero eso es mío

Si DevOps se trata de compartir la responsabilidad por una aplicación, ¿todavía puede tener límites? Por ejemplo, si todo el mundo en un equipo multifuncional participa en una respuesta a incidentes, ¿cómo puede restringir al desarrollador de código de acceder a la producción para hacer frente a un problema? ¿Debería intentarlo siquiera?

Para complicar las cosas está el hecho de que DevOps no ve igual de una organización a otra. En una organización DevOps, el equipo de operaciones de TI mantiene 100% del control con respecto al entorno de producción. En otra, los desarrolladores son los responsables de la infraestructura como código y de asegurar la estabilidad en todo lanzamiento.

Preservar la seguridad de la red y la seguridad de la información de la compañía representan barreras para el desarrollo ágil y flexible. Como tal, la seguridad, los datos y las pruebas a menudo son piezas descuidadas de una cultura DevOps.

La seguridad, el control de acceso basado en roles y el cifrado son componentes vitales de los ciclos de vida de aplicaciones DevOps, dijo Michael Grant, jefe de administración de práctica DevOps en la firma de consultoría de tecnología Column Technologies Inc. Tener herramientas que proporcionen una buena visibilidad del tráfico espurio hace que sea más fácil para los equipos de seguridad acceder a abrir los puertos u otorgar a una aplicación el acceso que requieren los entornos DevOps. Las herramientas de monitoreo de la infraestructura que proporcionan visibilidad de la red y las llamadas de las aplicaciones también pueden aumentar la seguridad, ya sea en un centro de datos o en recursos de la nube con varios inquilinos.

Los datos son el fundamento de todas las aplicaciones empresariales y, por lo tanto, deberían ser un componente importante de los procesos DevOps. Pero los administradores de bases de datos no tienen un lugar natural en el bucle de realimentación continua de DevOps. Los datos como servicio es el siguiente paso para DevOps, dijo Grant. Los datos seguros como servicio, dijo, permiten pruebas de carga de control de calidad más precisas antes de liberar el código para la producción, sin rebasar la infraestructura del equipo de base de datos.

Las pruebas son aún más difíciles de vender para los adoptantes de DevOps, que no siempre ven el valor de la garantía de calidad y la experiencia de pruebas.

"Teníamos un equipo de producto con ninguna persona de control de calidad; la suposición allí es que desarrollo puede hacer la prueba", dijo Kokkili. "Pero sin la experiencia, las pruebas siempre terminaban con una deuda técnica que causó problemas en la producción".

Por el contrario, colocar ingenieros de pruebas y control de calidad en el equipo DevOps puede prevenir la mentalidad anticuada de correcciones futuras y soluciones únicas para problemas de código en producción que DevOps declaraba arreglar en primer lugar.

Cuando todo lo que tiene es un martillo

Las herramientas son una parte crítica de cualquier entorno DevOps, pero para un tema tan importante, la elección de herramientas es un punto de fricción para las áreas DevOps.

"Un equipo utiliza Salesforce para realizar el seguimiento de los problemas, otro utiliza Trello y otro utiliza Jira, pero todo es para la misma aplicación", dijo Kokkili. "La visibilidad a nivel superior es difícil".

Los desarrolladores están acostumbrados a tomar herramientas que funcionen, ya sea que eso signifique que encajan con la estatura de cumplimiento de la empresa, reportando requisitos o necesidades de visibilidad de operaciones o no, señaló Chris Riley, analista DevOps en Fixate IO, en un podcast con nuestro portal hermano SearchDataCenter. El objetivo de una organización DevOps es estandarizar sin bloquear la creatividad de los miembros del equipo, y sigue siendo una lucha encontrar herramientas comunes a través de posiciones funcionales.

Las áreas empresariales de TI que adoptan herramientas DevOps a menudo sopesan el código abierto frente a suites empresariales soportadas, y por lo general quedan del lado de las suites empresariales, dijo un consultor de TI que se centra en DevOps. Esto se debe a que las empresas esperan contar con soporte, estabilidad y funciones de facilidad de uso como interfaces gráficas de usuario que muchas herramientas de código abierto no tienen. Mientras tanto, los proveedores de herramientas tradicionales de gestión de la infraestructura y monitoreo, tales como CA y BMC, están desarrollando productos DevOps, pero con resultados mixtos. Un compromiso podría ser herramientas como Puppet que siguen el modelo de código abierto Linux y toman de la comunidad ascendente para un producto controlado y soportado.

¿Ya llegamos?

El éxito requiere la mejora continua y el perfeccionamiento, en lugar de un impulso inicial para ciertos cambios sin un plan general. DevOps, como ITIL antes de él, promueve este bucle de retroalimentación, pero con demasiada frecuencia los departamentos de TI esperan llegar a un destino final, dijo Doug Tedder, consultor principal en Tedder Consulting.

Vimos el mismo patrón en las implementaciones de gestión de servicio TI de ITIL (ITSM. La gente incorpora la gestión de incidentes y un proceso de gestión del cambio rudimentario, pero no entienden cómo los procesos interactúan o su objetivo, dijo Tedder. "Algunas personas han sobrediseñado los procesos de ITSM [...]. Eso no es ITIL, es la gente construyendo el proceso".

"Requiere esfuerzo querer cambiar", agregó Gribben de la Universidad Estatal de Ohio. Por ejemplo, "[la formación en nuevas herramientas es] el costo de llevarse a alguien durante cinco horas a la semana, por algo que podría ahorrarle 25 horas a la semana".

También señaló que es la naturaleza humana centrarse en diferentes herramientas, o en más herramientas, en lugar que hacer frente a procesos.

"La alta dirección dice: ‘Espere, ya le compramos una herramienta' [así que, ¿por qué necesita otra?]. Y se queda sin vapor", dijo Tedder. Si el departamento de TI no está sirviendo a las mejoras continuas que se alinean al negocio, ninguna cantidad de herramientas o procesos o grupos de trabajo los salvará de las TI en las sombras y la tercerización.

Kokkili de CommerceHub defiende hacerlo como ellos lo hicieron, y empezar a usar DevOps poco a poco, implementándolo con un solo equipo de producto el primer año y construyendo la aceptación con capacitaciones, presentaciones y la asistencia a conferencias. "Falle rápido" ("fail fast") podría ser un buen mantra para las actualizaciones de una aplicación, pero no tanto para las personas involucradas.

Este artículo se actualizó por última vez en abril 2016

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close