La automatización es uno de los requisitos esenciales de la implementación de DevOps. Hay varias formas diferentes en las que podemos planificar el flujo de trabajo de automatización. Vamos a utilizar el marco de automatización API.
Hay tres unidades esenciales. Primero está el script de automatización, que puede contener archivos de características, datos de automatización o, a veces, repositorios de correo basura. Todo esto será utilizado por el marco de automatización API para automatizar la tarea. El marco de automatización API estará compuesto por un motor de ejecución de automatización, utilidades de automatización, utilidades de KPI para monitorear las tareas de automatización y ciertas utilidades comunes para integrar servicios externos al marco API existente. El resultado final serán informes y registros de automatización. Podemos utilizar varias herramientas diferentes en cada una de estas capas para asegurarnos de poder derivar un flujo de trabajo de automatización sólido para nuestro sistema existente utilizando marcos de automatización API.
El flujo de trabajo automatizado de DevOps también se basa en una canalización de componentes. La canalización de componentes comienza con la actividad de los desarrolladores de verificar la fuente. Una vez que se verifica la fuente y se compila, realizaremos pruebas de unidad y de sus componentes. En caso de que sea necesario revertir, revertiremos los cambios y una vez que estemos convencidos con el módulo probado, ensamblaremos los módulos. Cargaremos el módulo no controlado para su aprobación y finalmente, una vez aprobado, enviaremos una notificación. Las notificaciones pueden ser de dos tipos, puede ser una notificación de éxito o de error. Una vez que la carga de módulos no controlados se realice correctamente, el tipo de notificación será exitosa; de lo contrario, será una notificación de error.
Teniendo en cuenta el proceso de integración, comenzamos eligiendo la versión del componente. Una vez que hayamos seleccionado la versión del componente, debemos descargar todos los módulos dependientes. Después de descargar las dependencias, o módulos de los que depende nuestro componente, ensamblaremos y crearemos una unidad desplegable. Esas unidades desplegables se desplegarán utilizando varias estrategias de despliegue diferentes, como si se pudiera incrementar hasta la puesta en escena. Realizaremos una “prueba de humo” como resultado, podremos revertir la implementación y notificar la falla. Pero si la prueba tiene éxito, comprobaremos el “sistema inmunológico”. Nuevamente, el resultado de la verificación, si no es satisfactorio, podemos revertir el despliegue, pero si tiene éxito, realizaremos la prueba de aceptación. Si la prueba de aceptación no tiene éxito, podemos revertir la implementación nuevamente. Pero si es así, si todo está bien, podemos retroceder la preparación, realizar una prueba de humo adecuada en la preparación, promocionar los módulos y luego desplegar la unidad. Y finalmente, una vez finalizada la implementación, notificar el éxito. Pero si la etapa de reversión no tiene éxito, notificaremos el error.
Finalmente, vemos el flujo de trabajo automatizado de DevOps, pero ahora desde la perspectiva de la implementación en producción. Planificaremos el incremento de implementación de lo que esté listo para la producción. Una vez que esté implementado, haremos una prueba y decidiremos si revertimos la implementación o no. Si seleccionamos la estrategia de implementación de reversión porque la prueba falle, debemos detectar una implementación incorrecta. Necesitamos notificar el fracaso. Pero sí, si pasa la prueba se realizará una prueba del sistema “inmunológico” y notificaremos el éxito.
