Cómo empezar DevOps: Guía paso a paso

1. Cree una hoja de ruta de transformación de DevOps

Para adoptar DevOps, cree una hoja de ruta. El plan debe trazar cómo comenzar con DevOps, en un formato paso a paso. Una hoja de ruta permite a una organización coreografiar sus acciones por adelantado.

Publique la hoja de ruta y la documentación adjunta en una ubicación central donde las partes interesadas y los miembros del equipo puedan acceder al contenido cuando lo deseen. Por ejemplo, use Microsoft PowerPoint o Google Slides para documentar la hoja de ruta y publicar esas diapositivas en la plataforma de colaboración de la empresa. Incluya suficientes detalles para que la hoja de ruta sea fácil de entender, incluso sin un presentador. Resista la tentación de enviar las diapositivas por correo electrónico para asegurarse de que la hoja de ruta no se pierda entre los últimos correos electrónicos de RR.HH.

Las partes interesadas pueden ver la hoja de ruta y hacer preguntas sobre su función en el proceso de ejecución de su proyecto. Los equipos de TI pueden ver los próximos pasos en la transformación a medida que realizan cambios. Todos tienen la oportunidad de hacer preguntas y proporcionar comentarios sobre la hoja de ruta. No hay secretos, lo que ayuda a sofocar los rumores.

Una hoja de ruta de transformación de DevOps no es un proyecto único. Esté preparado para actualizar e iterar en la hoja de ruta a medida que su organización avanza en su camino DevOps.

2. Seleccione una cadena de herramientas de DevOps

Para iniciar DevOps es fundamental elegir una cadena de herramientas, pero es solo un paso. DevOps no se puede comprar, independientemente de lo que diga el amigable vendedor de software de automatización o administración de repositorios. La selección de herramientas es esencial para tener en cuenta los requisitos de los desarrolladores, así como las integraciones y las pilas de tecnología.

La selección y composición de la cadena de herramientas de DevOps también incluye un ejercicio de licencia y seguridad. Para las cadenas de herramientas basadas en la nube, las organizaciones deben crear un modelo de su distribución de gastos (y montos) en todos sus proveedores de herramientas y proveedores de servicios en la nube. Una cadena de herramientas de DevOps puede convertirse en un vector para ataques man-in-the-middle y similares. Involucre al equipo de seguridad durante las fases de debida diligencia e implementación de la nueva cadena de herramientas.

Las organizaciones de TI deben adoptar un enfoque de proyecto piloto al seleccionar una cadena de herramientas DevOps, en la que los equipos internos trabajen con los proveedores de herramientas, y posiblemente incluso con una empresa de servicios profesionales, para implementar la combinación correcta de herramientas que satisfaga sus requisitos de entrega a través de la capacitación y luego un primer proyecto manejable.

3. Implemente herramientas y estrategias para la transformación cultural

Hay cierta comodidad con el status quo para algunos tipos de personalidad de los desarrolladores. DevOps interrumpe algunas estructuras de poder organizativo y político a medida que los desarrolladores obtienen poder en el proceso de entrega. Para enfrentar estos desafíos, implemente herramientas y estrategias que fomenten la transformación cultural en las partes de la empresa que experimentarán la mayoría de los cambios.

Para implementar herramientas para la cultura DevOps, siga estos pasos:

1. Abra la nueva cadena de herramientas de DevOps a los equipos de desarrollo, operaciones y seguridad.
2. Brinde capacitación en DevOps a los equipos de desarrollo y operaciones para enseñarles las habilidades necesarias para usar la nueva cadena de herramientas.
3. Capture y defina una estrategia de colaboración entre desarrolladores, operaciones, QA y equipos de seguridad para flujos de trabajo.
4. Capacite a las partes interesadas y las unidades de negocio sobre los conceptos de DevOps para que el personal fuera del departamento de TI aprenda nuevas formas de interactuar con el desarrollo y las nuevas expectativas que el desarrollo de productos les imponga.
5. Cree documentación de procesos internos que capture los procesos de DevOps y publíquela en un repositorio central, como una wiki, para facilitar las actualizaciones.

4. Automatice procesos

La perspectiva de la automatización puede dar miedo en algunos entornos corporativos. Para disipar este miedo, considere un enfoque transparente y por fases para la automatización de DevOps.

Establezca objetivos de automatización por prioridad. Automatizar todos los procesos a la vez no es realista ni factible, para ninguna organización. Por ejemplo, al comenzar con las pruebas automatizadas, concéntrese primero en las pruebas de software y luego automatice las pruebas de seguridad. Si bien las pruebas automatizadas no pueden reemplazar la experiencia de un evaluador humano, un enfoque por fases permite a las organizaciones demostrar cómo la automatización puede aumentar las capacidades del personal.

Este enfoque también permite a los administradores de TI trabajar directamente con los equipos que sentirán los cambios derivados de la automatización de sus tareas. Aproveche esta oportunidad para explicar el razonamiento empresarial y ayudarlos a adaptar sus deberes laborales a la automatización.

5. Céntrese en los datos y el análisis

Las herramientas modernas de DevOps permiten a los equipos de TI aprovechar los datos procesables de su cadena de herramientas. Aprovechar esos datos es fundamental para el éxito de DevOps porque altera la forma en que los equipos de TI se comunican con las partes interesadas y entre los departamentos.

Configure informes de panel para las partes interesadas para que los líderes del proyecto no tengan que generar informes de gestión manualmente. Presente a las partes interesadas los paneles y cómo enviar comentarios al equipo de DevOps sobre los datos que reciben. Una mentalidad de "primero el tablero, luego preguntas" puede requerir algunos ajustes culturales menores, especialmente en la administración.

6. Ejecute un proyecto piloto

Un proyecto piloto de DevOps permite a los equipos y a las partes interesadas probar sus nuevas herramientas y procesos en un proyecto pequeño. Una escuela de pensamiento típica es elegir un proyecto interno sin un cliente adjunto, para reducir el riesgo si algo sale mal: un cliente dispuesto (y que paga) por el proyecto aumenta las apuestas para el equipo y el proyecto. Por otro lado, con un cliente cooperativo como parte del proyecto, los equipos de DevOps pueden recibir comentarios de fuera de su organización.

7. Prepárese para el aprendizaje y la mejora continuos

No existe un último paso tradicional en el proceso de inicio de DevOps. Así como el software sigue un proceso de integración/entrega continua, también lo hacen los procesos y herramientas de DevOps. Con el tiempo, los equipos aprenderán lecciones sobre cómo hacer algo mejor. Esas lecciones deben encontrar su camino de regreso a la estrategia de la organización. Los nuevos miembros del personal aportarán nuevas perspectivas y experiencias de empleadores y proyectos anteriores. Inevitablemente, los equipos también querrán incorporar algunos de sus aprendizajes y experiencia en el marco de DevOps.