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.
