¡El tiempo es (mucho) dinero!

Por enero 18, 2018

¿Usted cree que el tiempo es como el dinero?

En el mundo conectado en que vivimos hoy, esta verdad toma proporciones aún mayores. Y esa antigua expresión me parece haber sido perfectamente creada para el mundo de DevOps.

Por ejemplo, muestro aquí algunos ejemplos que permiten ahorrar mucho tiempo, y que podrán permitir que aquellos proyectos interesantes, pero con baja prioridad y que siempre están a la espera de un  determinado recurso, empiecen a ejecutarse.

Actualmente, para desarrollar algún software, tenemos muchos ambientes que necesitamos mantener actualizados (Dev, Test Integrado, Homolog, Producción). Normalmente, los desarrollos ocurren en DEV y los desarrolladores son los responsables por la supervisión de ese servidor. Pero a partir de ahí, otras áreas necesitan utilizar esfuerzos para la publicación de nuevos deploys.

Funciona de esta manera:

1º Los desarrolladores crean sus paquetes y de alguna forma abren una solicitud para el personal de Database, Infraestructura, Gobernanza y similares para que hagan la publicación.

2˚ Database comprobará cada script SQL para saber si tiene código válido y si está dentro de la política de seguridad de la empresa, y luego de ello, se ejecutará manualmente. Con ello, los DBAs crearon formas de recuperar la base caso ocurra algún problema.

3º Infraestructura seguirá paso a paso el itinerario de publicación (copia de archivos, exclusión de directorios, backup, ejecución de archivos bat, start de pool) y, al final, pedirá al desarrollador para que pruebe.

Luego, la Gobernanza hará el registro de la solicitud y mantendrá la información en el historial. Esto plantea cuatro cuestiones:

  • ¿Este escenario parece con algo que usted ve en su día a día?
  • ¿Cuánto tiempo el DBA utiliza con publicaciones?
  • ¿Alguna vez, por un equívoco del proceso manual, se olvidó la copia de un determinado archivo y los desarrolladores necesitaron “depurar” el ambiente para encontrar el problema?
  • ¿Cuánto tiempo podría ser liberado para el equipo de Gobernanza si no se necesitase registrar en sistema el resultado de cada uno de los deploys solicitados?

Todo esto es posible con la automatización de publicación. Los desarrolladores crean sus paquetes, y a través de una herramienta web ejecutan el deploy.

Los scripts SQL se ejecutarán secuencialmente pasando por todas las comprobaciones necesarias (comandos no válidos, script en blanco, servidor adecuado). Al final de la ejecución, se puede grabar registros y enviar correo al solicitante. Se puede tener un flujo de rollback automático si algún script tenga error.

El plan de infraestructura se seguirá integralmente, asegurándose de que no se eliminará ningún archivo y se iniciarán todos los pasos. Se puede crear una copia de seguridad inicial y, en caso de necesidad, se llamará un restore.

La Gobernanza tendrá toda la información de lo que fue ejecutado, por quién, cuando, status de la ejecución y no se perderá tiempo teniendo que registrar esa información. Con eso, todos ahorrarán tiempo y los recursos que hoy ejecutan esas actividades podrán estar asignados a otros proyectos.

Escrito por Francis David
System Analyst at CA Technologies
LinkedIn: @francisdavid

Los comentarios están cerrados.