Hoy en día la gestión del ciclo de vida del software y técnicas de lo que llamamos DevOps tienen bastante peso en la decisión de cómo y con qué implementar nuestras necesidades de negocio. El poder definir una buena estrategia de DevOps nos alivia muchos dolores de cabeza y noches de insomnio antes de un despliegue en producción.
Con la adopción de nuevos servicios Cloud en nuestros proyectos surgen dudas como:
– ¿Cómo voy a mantener el versionado de la implementación que haga en el servicio?
– ¿Qué pasa si un día hay que hacer un rollback o un despliegue no sale bien?
– ¿Es necesario que haga copias de seguridad?
– ¿Puedo integrarlo en mis entornos de desarrollo, test, preproducción, D-1, etc…?
Las respuestas a estas preguntas son las que vamos a tratar hoy.
Azure Cognitive Search VS Azure SQL Database
Azure Cognitive Search, al igual que muchos otros recursos o servicios que nos proporciona Azure, podemos gestionarlo como tal desde el portal o via script/API. Esto quiere decir, que el servicio no nos proporciona mecanismos para hacer copias de seguridad y restaurarlas como hace por ejemplo con las Azure SQL Database.
Hagamos una similutd con las Azure SQL Database ya que, menos en la gestión de backups, nuestro enfoque debe ser muy similar.
Microsoft te proporciona el servicio como tal y tú puedes levantar una base de datos que en principio irá vacía. La estructura y datos (iniciales) que se despliegue en ella, es cosa tuya.
Con la aparición de los proyectos en Visual Studio de base de datos la gestión de versiones de SQL ha pasado de ser un backup y una carpeta de scripts de actualización a un proyecto que se compila, despliega y actualiza por ramas como si de código se tratase.
Este es el punto que tenemos que aplicar al resto de servicios que consumimos.
Para desplegar el servicio y sus dependencias, tenemos los esquemas ARM que a día de hoy podemos ejecutar desde cualquier plataforma de despliegue, ese punto nos lo dan más que cubierto.
Pero, ¿Cómo hacemos con el contenido?
La solución que nos parece más viable, con las herramientas que tenemos para trabajar con Azure Cognitive Search es tratarlo como código, al igual que hacemos (o es recomendable hacer) con las bases de datos SQL. Incluir un proyecto dentro de nuestra solución que se encargue de generar los elementos que contiene nuestro Azure Search como puedan ser:
- Orígenes de datos
- Indexadores
- Índices
- Skillsets
Vinculado a nuestro repositorio donde tengamos el proyecto/solución debemos incluir la definición de estos elementos y la plantilla ARM de los recursos necesarios. De esta manera llevaremos los cambios en nuestro software alineados con los cambios necesarios en la configuración y comportamiento de nuestro servicio.
Supongamos el siguiente escenario:
- Somos el equipo de desarrollo de la intranet/CRM de nuestra empresa y tenemos montado y funcionando Azure Cognitive Search en nuestra gestión documental.
- Los emails que recibe el buzón de correo de soporte de nuestra empresa, los tenemos incluidos en la gestión documental e indexado con Azure Cognitive Search
- Nos llega una funcionalidad nueva: Añadir en los emails que recibe el email de soporte de nuestra empresa el análisis de sentimiento del contenido de ese email.
Para implementar esta nueva funcionalidad (obviando el trabajo de frontend y backend) tendremos que hacer modificaciones en los diferentes elementos de Azure Search:
- Añadir la skillset de análisis de sentimientos
- Añadir un campo al índice donde almacenemos este valor y definamos si es filtrable, ordenable, etc…
- Modificar el indexer para que vuelque el resultado de la skillset al índice
Estas modificaciones irán incluidas en la misma versión que el frontal y el backend, pasarán las mismas etapas y validaciones que el resto del software. ¿Cómo?
Teniendo un proyecto (en C# por ejemplo) que sea el que se encargue de efectuar estos cambios.
Pero no estos cambios en concreto, sino cualquier cambio que apliquemos a cualquier elemento:
Los índices podemos definirlos mediante clases en la que sus propiedades sean los campos del índice y los atributos de estas propiedades sean los que definen si es Searchable, Filtrable, etc…
Las Skillsets podemos o bien tenerlas definidas también con clases o bien tratarlos como un JSON y hacer que simplemente se manden via API REST
Los indexadores y fuentes de datos podemos gestionarlos igual que las Skillsets, tenemos esas dos opciones.
Este proyecto de despliegue, “únicamente” tiene que encargarse de ir lanzando las peticiones de actualización al servicio de Azure Search que o bien por parámetro o bien por fichero de configuración hayamos especificado.
Con esto, nos aseguramos, que después de que se haya ejecutado este programa, tendremos el contenido de nuestro Azure Search igual que lo que tenemos definido en código (ya sean clases de C#, ficheros JSON, java, Python, el que nos permita el SDK y mejor se amolde a nuestra solución)
Quiero remarcar el “únicamente” porque tendremos que dotar a este programa de la lógica de que hacer en caso de que haya una operación no permitida, como puede ser: eliminar un campo del índice, cambiar si es Filtrable o no, etc…
Ante estas situaciones piensa como lo resolverías si tuvieses que hacer el despliegue manualmente y pásalo a código/script.
O bien podrías generar un índice nuevo o eliminar el existente y volverlo a generar. Esto último, hay que pensarlo bien en entornos de producción ya que tendremos que volver a indexar todo el contenido. Si esto es viable, es la solución más fácil.
Una vez hechos estos cambios seguiríamos el mismo flujo como si una modificación de código más se tratase. Mediante pull request de los cambios de versión o la estrategia que tengamos definida para el resto de nuestro software en el que va incluido el Azure Search pasando por todos los entornos antes de llegar a producción.
De manera que si existiese un problema en el despliegue o cambio de configuración lo veríamos enseguida gracias a nuestro flujo de integración continua y no llegaría a producción.
Teniendo esta aplicación/ejecutable/scripts que se encarguen de gestionar el contenido del Azure Search, nuestro flujo de despliegue debería ser el siguiente:
- Desplegar templates ARM para generar o actualizar los recursos desplegados en el grupo de recursos
- Ejecutar el ejecutable/scripts para actualizar Azure Cognitive Search. (Sería buena idea que esto devolviese el nombre de los índices desplegados, por si los necesitamos para parametrizar otras aplicaciones que se desplieguen a posteriori)
- Continuar con el despliegue normal de nuestro software: Backend, frontend, base de datos, etc.
Conclusión
Teniendo montado este sistema, ya podemos dar respuesta a las preguntas que nos hacíamos inicialmente.
– ¿Cómo voy a mantener el versionado de la implementación que haga en el servicio?
Usando la misma estrategia que uses para el versionado de tu código. Irá alineada la versión de código y contenido/implementación del Azure Cognitive Search
– ¿Qué pasa si un día hay que hacer un rollback o un despliegue no sale bien?
Simplemente lanzaremos el despliegue de la versión anterior que fuese correcta y nuestra aplicación/scripts se encargará de efectuar los cambios
– ¿Es necesario que haga copias de seguridad?
No, tienes cada versionado en el gestor de código. Los datos puedes volver a cargarlos desde el origen de datos una vez hayas desplegado la infraestructura y los indexers.
– ¿Puedo integrarlo en mis entornos de desarrollo, test, preproducción, D-1, etc…?
Si, con la solución que planteamos únicamente tendríamos que cambiar los parámetros o el fichero de configuración que usemos para indicar el recurso sobre el que queremos desplegar y ¡A JUGAR!
¡Sigue Aprendiendo!
Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼
>> Más info
