¿Cómo puedo alojar un rol de trabajador de Azure localmente/en el local?

Question

Algunos antecedentes ....

Estamos aventurarse en Azure por primera vez y estamos tratando de hacerlo en pequeños pasos. Por ahora, nuestras primeras aplicaciones serán funciones de los empleados que supervisen las colas para procesar las solicitudes (como enviar un correo electrónico o realizar algún raspado de pantalla) y nos insertaremos en las colas de nuestra aplicación local MVC y los servicios de WCF. Más adelante trasladaremos la aplicación MVC y los servicios de WCF a Azure.

Nuestro flujo de trabajo de desarrollo va esencialmente como esto (algo modificada de una manera sin importancia):

1. Desarrollar a nivel local y en algunos servidores compartidos. Verifique en el control de la fuente.
2. Cada 15 minutos, a construir servidor crea y despliega a un entorno de "desarrollo" (se dobla como CI y cubre en caso de que tenga que pulsar un entorno de "desarrollo" que no sea local)
3. probadores técnicos activar manualmente la construcción del servidor para desplegar la última versión exitosa de "Dev" para el entorno de prueba (o alternativamente, la compilación de prueba desplegada previamente, incluida/excluida la base de datos).
4. Los verificadores técnicos y los comprobadores comerciales activan manualmente el servidor de compilación para implementar la última versión exitosa de "Prueba" (o alternativamente, la compilación de prueba desplegada previamente, incluida/excluida la base de datos) en el entorno de control de calidad.
5. En algún momento fusionamos el conjunto de cambios que la garantía de calidad aprueba para la implementación.
6. Más adelante, nuestro servidor de compilación de producción implementa esta versión en etapas y luego en nuestros entornos de producción (la hospedamos N veces en entornos paralelos/independientes).

Como puede ver, tenemos una serie de versiones alojadas internamente de nuestra aplicación para que la gente de soporte interno la ataque antes de llegar a la producción. Me gustaría que estos tengan un nivel razonablemente bajo de dependencia de Azure. No es necesario que complete la dependencia del servidor, por lo que seguiremos usando Azure Queues y tal vez algunos otros mecanismos solo porque son fáciles de seguir, pero no queremos que nuestro servidor de compilación tenga que implementarse en Azure. para cada uno de estos entornos (y alternativamente pagar todo ese alojamiento).

Entonces, ¿cómo podemos alojar razonablemente nuestras funciones de trabajador en las instalaciones de una manera en la que realmente estamos probando el código que se implementa en Azure?

Una opción que se ha sugerido es que creemos el rol de trabajador como un contenedor/fachada y hagamos todo el trabajo real dentro de una biblioteca de clase, que era nuestro plan. Sin embargo, el seguimiento para permitirnos "alojar" esto sería crear una segunda aplicación de envoltura/fachada que realice el mismo trabajo que la función de trabajador, solo de forma que podamos ejecutarlo como una tarea programada o una ventana. servidor. En definitiva, no me gusta esta opción porque un proyecto completo nunca se prueba hasta que llega a la puesta en escena.

¿Es posible hacer algo similar cuando creamos una segunda aplicación wrapper/fachada que en lugar de llamar a la biblioteca de clases a la que realmente hace referencia y llama a la función Run() en la función worker?

Answer 1

¿Piensas que Azure emulator podría ayudarte? Estos son differences entre el proveedor real de Azure y el emulador.

Tener una fachada para su rol de trabajador parece razonable.¿Y usar adaptadores para adaptar cualquier posible tecnología de nube (u otro hosting) a esa fachada? Solo estoy tratando de arrojar algunas ideas. De hecho, utilicé este enfoque antes, pero era un proyecto "personal".

Use PowerShell para configurar sus roles y otras cosas. Configure su emulador de Azure como this.

Answer 2

El enfoque de fachada es el mejor para adoptar, para ser honesto.

Cuando tiene implementaciones que finalmente tienen dependencias en la infraestructura de soporte, es excepcionalmente difícil realizar una prueba completa hasta que se implemente en una infraestructura idéntica o comparable. Ese es seguramente el caso con un Rol de trabajador azul.

Al desacoplar los aspectos funcionales de la aplicación de los puntos de contacto de infraestructura, se puede pasar el esfuerzo de asegurar que su código se comporta como debe ser, demostrar que la fachada se comporta como es debido, a continuación, prueba de confianza de la combinación final.

Siempre hay algún elemento de compromiso en este sentido a menos que sus entornos de prueba sean idénticos a sus entornos de producción.

Y es para lo que es la implementación de transición de Azure; ese último nivel de pruebas de confianza antes de pasar a la producción.

Puede crear una implementación muy pequeña, exclusivamente para las últimas etapas de prueba. Usted paga por el tiempo que se implementa la función, por lo que si elimina la implementación una vez que se completan las pruebas, puede minimizar el costo.

Por último, y el patrón de fachada es un ejemplo, el diseño para la capacidad de comprobación. Factorice su código para maximizar la cantidad que se puede probar antes de la implementación y minimice su riesgo en etapas posteriores de prueba.