Proceso de lanzamiento de versiones del equipo
El primer paso para configurar un procedimiento de DevOps consiste en evaluar el proceso actual. Esto significa analizar:
- Los artefactos existentes, como los paquetes de implementación y NuGet, así como los repositorios de contenedores.
- Las herramientas de administración de pruebas existentes.
- Las herramientas de administración del trabajo existentes.
- Recomendar las estrategias de migración e integración.
Vamos a hacerlo con el equipo de Tailspin y a ver cómo puede ayudar DevOps.
Cuando Irwin, el jefe de producto, sale de la reunión, Amita dice: "Necesitamos ayuda. No sé para cuándo tienen que estar listas estas correcciones, pero sé que será pronto. Y no estamos preparados para lograrlo a corto plazo. Además, el nuevo sitio web de Space Game tendrá que esperar hasta que arreglemos este lío, pero es que el juego viene pisando fuerte".
Andy mira a Mara. "Esto es demasiado para el poco tiempo que llevas aquí".
"No pasa nada", responde Mara. "Quizás puedas explicarme cómo funcionan las cosas por aquí. ¿Cómo pasa un juego de desarrollo a producción?".
"Buena pregunta", comenta Andy. "No estoy seguro de que podamos darte una respuesta sencilla, pero vamos a intentarlo".
El equipo decide ir a una cafetería para relajarse y hablar de manera informal. Juntos, tratarán de averiguar por qué tienen tantos problemas.
Durante el café, Mara escucha e intenta tomar notas. Hay una gran cantidad de información y no está organizada. Estas son sus consideraciones generales sobre el equipo:
- Usan un método en cascada. La dirección ejecutiva es quien establece las prioridades. Los desarrolladores escriben el código y entregan la compilación a Control de calidad, quienes realizan pruebas y, seguidamente, mandan la compilación a Operaciones para implementarla.
- El enfoque en cascada podría ser aceptable en un equipo pequeño, pero aquí los objetivos no siempre están claros y parecen que cambian con frecuencia.
- Las pruebas se retrasan hasta bastante avanzado el proceso, con lo cual corregir errores y realizar cambios son tareas más difíciles y costosas.
- No hay ninguna definición clara del significado de listo. Cada miembro del equipo tiene su propia idea. No existe un objetivo empresarial común con el que todo el mundo esté de acuerdo.
- Parte del código está en un sistema de control de versiones centralizado. Muchas de las herramientas y scripts están disponibles únicamente en recursos compartidos de archivos en la red.
- Hay muchos procesos manuales.
- La comunicación es caótica y depende del correo electrónico, de documentos de Microsoft Word y de hojas de cálculo.
- Los comentarios también son poco frecuentes e incoherentes.
- En cuanto a lo positivo, el equipo parece llevarse bien y quiere hacer mejor las cosas.
Al examinar todas las notas, Mara sabe que necesita organizar toda esta información. Si lo hace, será más fácil evaluar los procesos. Está convencida de que con un método de DevOps se solucionarían muchos de los problemas del equipo, pero necesita encontrar una forma de presentar el caso ante el equipo.
Una forma habitual de comenzar un método de DevOps es comprender los procesos existentes. A partir de ahí, se puede valorar qué funciona bien y qué no, y centrarse en lo que se debe corregir en primer lugar.
Mara pregunta: "¿Alguno de vosotros ha hecho alguna vez un ejercicio de mapa de flujo de valor?"
Andy pone los ojos en blanco, Amita suspira y Tim dice: "No queremos más papeleo".
Mara aduce: "Lo entiendo. Dejádmelo a mí".
Contentos de que la nueva se encargue del asunto, todo el mundo vuelve al trabajo.