Cada semana, IDG participa en un TechTalk y esta semana fui invitado a hablar sobre DevOps con algunos expertos en el campo. Incluso nos convertimos en tendencia en Twitter. Dividieron la charla en 5 preguntas, con respuestas de varios miembros de la comunidad. Hubo muchos colaboradores y les animo a que revisen el hashtag #IDGTechTalk. ¿Alguno de ustedes tiene una definición práctica de DevOps con la que se sientan cómodos? Comenzaron con la pregunta más abierta posible. Como escritor y presencia externa, encuentro esto fácil de responder. Sin embargo, fue interesante ver algunas de las respuestas de los profesionales de la industria. Los desarrolladores en la industria se habían especializado tanto que solo se dedicaban a escribir código y se olvidaban de las pruebas, la implementación y la experiencia del usuario. DevOps se trata de volver a reunir a los desarrolladores con los usuarios. #idgtechtalk – Brent Kirkpatrick (@DrBKirkpatrick) 1 de marzo de 2018
Esta es una perspectiva interesante de Brent Kirkpatrick. A veces, los usuarios finales parecen ser la última prioridad en gran parte del desarrollo de software. Es bueno ver a alguien que se preocupa por DevOps debido a los beneficios para la experiencia del usuario. Añade además: Los desarrolladores solían sentarse en sus cubículos y solo hablar con las personas encargadas de las pruebas. Había una barrera. Para hablar con un desarrollador, tenías que presentarles un caso de uso y un camino de ejecución con un error muy específico. #idgtechtalk – Brent Kirkpatrick (@DrBKirkpatrick) 1 de marzo de 2018
Conectar a los usuarios con los desarrolladores es idealista, pero DevOps es una filosofía idealista. En esta charla, definí DevOps como “un cambio cultural primero”. Las herramientas que mejoran DevOps no serían tan útiles sin un cambio cultural. La cultura debe estar presente primero. Desde un nivel gerencial, debe reconocerse que las formas antiguas de desarrollo no son tan efectivas. Eliminar los compartimentos estancos entre desarrollo y operaciones (e incluso los usuarios, según Brent Kirkpatrick) es lo que se necesita para implementar una cultura de TI adecuada. ¿Has implementado realmente DevOps en tu organización? Si es así, ¿se extiende a todos los grupos de desarrollo? Esta pregunta es mucho más difícil de responder de lo que algunos pueden darse cuenta. DevOps tiene tantos componentes, ¿cuándo se considera que se ha terminado? ¿Realmente se puede terminar alguna vez? Allan Zander parece no pensar así: A.2 Digamos que nos estamos acercando a una visión más idealizada de #DevOps, con la mejora continua como objetivo. No estoy seguro de si alguien puede considerarse “terminado” de implementar #DevOps. #IDGTechTalk @IDGTechTalk – Allan Zander (@ajzander) 1 de marzo de 2018
DevOps se verá diferente para cada empresa. Algunas pueden centrarse en la automatización, otras pueden centrarse en el aspecto cultural, etc. No hay un final definitivo para DevOps. Si crees que has terminado de implementarlo, es posible que estés en riesgo de arruinarlo. Siempre habrá nuevas herramientas disponibles para mejorar los procesos. La automatización, la inteligencia artificial y el aprendizaje automático son cada vez más complejos. Terminar con DevOps sería ignorar estas herramientas. ¿Cuál ha sido el mayor beneficio de DevOps para ti? Los beneficios de DevOps pueden ser diversos dependiendo de a quién le preguntes. Por lo tanto, las respuestas en el IDGTechTalk fueron diversas. Algunas personas estaban interesadas en lanzamientos rápidos, mientras que otras estaban interesadas en la medición. La perspectiva varió mucho en esta sección. Quizás la mayor lección aprendida fue la pregunta de seguimiento realizada por Brent Kilpatrick: El desarrollo ágil puede parecer más rápido que el método tradicional, pero se realizaban menos pruebas antes del lanzamiento. ¿Cómo ves la integración de las pruebas en el marco de DevOps? #idgtechtalk – Brent Kirkpatrick (@DrBKirkpatrick) 1 de marzo de 2018
Algunas de las mayores desventajas de DevOps son la falta de enfoque en las pruebas y la seguridad. No fue una sorpresa ver a personas hablar sobre los tiempos ágiles de lanzamiento. Reconocer las fallas en nuestras prácticas es lo que nos hace mejorar. Las mejores prácticas son las mejores porque están probadas. Nicholas D. Evans tuvo una excelente respuesta con respecto a las microcaracterísticas: Definitivamente debe estar presente o podría ser un desastre. Las pruebas también se pueden realizar de manera ágil. Normalmente lanzamos microcaracterísticas de manera regular, por lo que podemos probar muy rápidamente. Estoy de acuerdo, se necesitan más pruebas para las funcionalidades principales… #idgtechtalk – Nicholas D. Evans (@NicholasDEvans) 1 de marzo de 2018
Este truco es una excelente manera de mantener la seguridad y tener los mejores lanzamientos posibles. En lugar de centrarse en los horarios de lanzamiento principales, los cambios ágiles de manera incremental pueden ser igual de efectivos y seguros. ¿Cuáles han sido algunos de los principales obstáculos de DevOps? ¿Resistencia? La seguridad fue mi respuesta. Los equipos de seguridad han sido excluidos del proceso de DevOps y esto ha sido un problema. DevSecOps ha sido un tema popular, pero DevOps es la palabra de moda que reina supremamente. Otro obstáculo son aquellos que se sienten obsoletos con DevOps: Varía. Pero esto es un cambio clásico de gestión. DevOps está sucediendo. Los desarrolladores y probadores deben reconocer que la elección no es entre “este cambio o ningún cambio”. Ahora es entre “este cambio u otro cambio”. Abrazar DevOps significa tomar el control de manera proactiva. #idgtechtalk – Steven M Prentice (@StevenPrentice) 1 de marzo de 2018
La cita de Steven es precisamente cómo debería implementarse DevOps en la gestión. Las empresas se están moviendo hacia la nube, agregando contenedores, automatización, etc. No hay lugar para la resistencia y la gestión debe dejarlo claro. El cambio no siempre es para mejor, pero con DevOps lo es. ¡Asegúrate de seguir a @IDGTechTalk en Twitter para la charla de la próxima semana!
