Crear un equipo de DevOps que vaya en la dirección correcta es más difícil de lo que crees. No hay un enfoque único para todos los DevOps, pero adoptando nuevas estrategias puedes asegurarte de que tu equipo sea un verdadero equipo de DevOps. Lee más en el siguiente post, que fue publicado originalmente aquí en InfoWorld.com.
Todo el mundo grita tanto «DevOps» estos días, que podrías estar listo para ceder e ir a comprar una caja. Excepto que DevOps es, en su mayor parte, no es algo que venga en una caja. Claro, hay herramientas que pueden ayudar a una organización centrada en DevOps a trabajar más fácilmente, pero el corazón de DevOps está en los equipos que implementan sus filosofías. Implementar DevOps significa adoptar algunas nuevas – y a veces aterradoras – estrategias para la organización del equipo, responsabilidades y expectativas. Aquí hay tres cosas que te dirán que estás en un equipo de DevOps que ha apuntado firmemente en la dirección de DevOps:
1. DevOps: Equipos basados en el producto
Una verdadera organización de DevOps normalmente organizará equipos de TI en torno a los productos que esos equipos entregan. Eso significa abandonar el viejo enfoque de disciplina-silo que la mayoría de nosotros ha utilizado durante décadas. Un equipo de producto al estilo de DevOps (como este) incluirá cosas como gerentes de producto, desarrolladores, expertos en infraestructura, administradores de sistemas y todos los demás necesarios para hacer que ese producto se convierta en una realidad de producción.
Por supuesto, muchas de esas responsabilidades no serán una ocupación a tiempo completo en cada proyecto. No es raro que un solo experto en infraestructura de redes preste servicio en múltiples equipos basados en productos, por ejemplo, compartiendo su tiempo según sea necesario en función de las prioridades de la organización.
También hay mucho valor en la coordinación de disciplinas específicas. El hecho de que todos los operadores de sistemas mantengan una visión de alto nivel de todo lo que está sucediendo puede garantizar el buen funcionamiento, y el hecho de que todos los desarrolladores se «acurrucen» de vez en cuando puede facilitar el intercambio de nuevas técnicas, lecciones aprendidas y otra información valiosa. Esto sucede en los gremios de productos cruzados, donde los miembros de cada disciplina se reúnen de vez en cuando para hablar de negocios y compartir información.
2. DevOps: Fallando con estilo
Los verdaderos equipos de DevOps no intentan prevenir el fracaso reduciendo la velocidad del cambio. En su lugar, juegan para moverse rápidamente, confiando en la capacidad de su equipo para recuperarse del fracaso con la misma rapidez. Al desplegar los productos en pequeños sprints controlados, los equipos saben que el número de cambios que se están desplegando en un momento dado será mínimo, por lo que se mitiga el riesgo y se facilita la recuperación rápida.
Los equipos de DevOps dan la bienvenida al fracaso como una experiencia de aprendizaje significativa. Gracias a los conductos de entrega automatizados y a las pruebas automatizadas de las unidades, cada fallo se convierte en otra prueba que se incorpora al proceso de construcción. En lugar de confiar en el conocimiento y la experiencia institucional para prevenir el mismo fallo en el futuro, los equipos de DevOps codifican todo en su proceso, evitando automáticamente que el mismo fallo ocurra dos veces.
Un equipo de DevOps todavía trata de anticipar y prevenir el mayor número de fracasos posible en un sentido proactivo, pero tampoco rehúye el hipo ocasional. Culturalmente, esto significa que las organizaciones tienen que adoptar una actitud madura sobre el fracaso, eliminar el «juego de la culpa» de la cultura y centrarse en la anticipación, el aprendizaje y la prevención como una parte profundamente arraigada de su proceso.
3. DevOps: Automatización obsesiva
Un verdadero equipo de DevOps sabe que el error humano es el mayor punto de fracaso en cualquier proceso, y el mayor cuello de botella cuando se trata de moverse rápidamente. Estos equipos adoran la automatización, tanto por su infalible consistencia como por su increíble velocidad. Desde las reglas de registro y análisis del código, pasando por la rotación del entorno de pruebas, hasta la prueba de la unidad real, hasta el despliegue de la producción final, estos equipos saben que la automatización es el único camino a seguir.
Pero un equipo de DevOps verdaderamente efectivo no es particular acerca de sus herramientas de automatización o tecnologías. Se centran en la herramienta adecuada para el trabajo, y están dispuestos a alejarse de una herramienta y adoptar otra si proporciona un camino más suave para el objetivo final del negocio. Heterogéneo sólo comienza a describir la tienda promedio de DevOps, y eso puede ser un enorme desafío para las organizaciones heredadas que tienen un profundo compromiso filosófico con una plataforma o enfoque particular.
Los equipos de Effective DevOps saben que el objetivo de la tecnología de la información es ofrecer aplicaciones y servicios a sus usuarios, proporcionando experiencias de usuario, no sólo características, y que todo lo que está en medio es sólo un gran potencial de topes de velocidad. Saben que el trabajo de DevOps es proporcionar la ruta más suave, segura, rápida y fiable entre los teclados de los desarrolladores y un despliegue de producción, de modo que cada nuevo sprint de codificación pueda resultar rápidamente en un despliegue de producción probado. DevOps no es «NoOps», sino que es un esfuerzo operativo obsesivo para automatizar la mayor cantidad de operaciones posibles.
DevOps es un cambio importante
De las empresas que aborrecen y controlan el cambio, dependen de los despliegues manuales, se centran en gran medida en los procesos manuales de control de calidad para detectar problemas y mantienen un organigrama basado en silos, los DevOps pueden parecer extraños, controvertidos o incluso locos. Pero créame, algunas de las empresas tecnológicas más ágiles, rápidas y reactivas de hoy en día confían en los enfoques del estilo de DevOps para poner más producto en las manos de sus clientes que nunca antes. Lo están haciendo con menos burocracia interna, un mayor enfoque en los resultados y la experiencia del cliente y, en general, con tecnólogos más felices y menos rotación de empleados.
Aprende más con el camino de preparación para el examen: Ingeniero de desarrollo certificado por la AWS