¿Es esto un entorno de control de calidad de Azure válido y posible?

Question

Estoy tratando de formular un entorno válido de desarrollo/prueba/QA para que el paquete de aplicaciones de mi empresa migre a Azure. Sin embargo, estoy imponiendo la restricción sobre nosotros de que nuestro dev/test/qa/etc. los entornos se alojan en el sitio y se implementan a través de un servidor de compilación (como CC.NET, TeamCity, Jenkins, etc.).

En tal un "entorno de prueba", necesitamos la capacidad de desencadenar las implementaciones de una instantánea de código específica inédita (y datos) para un equipo de control de calidad y comerciales profesionales para poner a prueba tanto para las pruebas técnicas y de las pruebas de aceptación de negocios. Es evidente que todas estas personas no compilarán y presionarán F5 en Visual Studio para realizar esta prueba, por lo que necesitamos un entorno para implementarlo. En nuestro SDLC, realmente pasamos por ~ 4 de tales entornos antes de llegar a la puesta en escena y la producción. En resumen, necesitamos un proceso de bajo costo (implementaciones automatizadas) y fácilmente reproducibles para esto.

Al planificar este entorno, la cuestión de "Cómo alojar los servicios de Azure" es claramente la parte más difícil. Así que veamos cada parte de Azure. Las opciones en cursiva son las que queremos ir.

• roles web Bueno, IIS puede más o menos manejar estos para nosotros (al menos lo suficiente para situaciones dev/test - todos menos verdadera prueba de carga que evidentemente tendríamos hacer en Azure, lo cual está bien).
• Roles de trabajo Tenemos dos opciones aquí, al parecer. La primera es tener una "aplicación de envoltura" que es un servicio de Windows y podemos usar eso para alojar los archivos DLL que nuestras funciones de trabajo llaman para la funcionalidad (después de todo, nuestro verdadero proyecto Rol de trabajador no debe ser nada más que un archivo de configuración y ~ 4 líneas de código que llama a una DLL para hacer el trabajo). Esa opción funciona, pero requiere un código de aplicación y una administración/mantenimiento de código de implementación muy diferentes. La segunda opción es usar Azure Compute Emulator. Esto funciona siempre que sus Roles de trabajo no necesiten monitorear puertos externos ni nada. En nuestro caso, nuestras Roles de trabajo solo necesitan monitorear Colas, y posteriormente acceder a varios recursos. Los problemas con esto giran en torno a las diferentes secuencias de comandos de compilación porque la única forma de automatizar una implementación en Azure Emulator es ejecutar CSPack y CSRun en la máquina que aloja Azure Emultor, que probablemente no sea su servidor de compilación. Debido a esto, tendrás que hacer algún tipo de scripting remoto para lograr esto.
• roles VMque realmente no se preocupan por estos, así que estoy totalmente ignorando este aspecto de la prueba.
• Colas Aquí, tenemos 3 opciones. El primero es usar MSMQ. Como esto requiere una base de código completamente diferente que no tenemos (o al menos una abstracción alrededor de esa base de código diferente), no estoy considerando esta opción. El segundo es mantener Colas en Azure ya que son muy pequeñas/baratas. De hecho, estamos haciendo esto temporalmente hasta que podamos probar la tercera opción. La tercera opción es usar Azure Storage Emulator. No estoy seguro, pero creo que esta opción solo permitirá que los servicios que se ejecutan en la máquina local accedan a los objetos de almacenamiento. Para Colas, nuestro código de aplicación es el código que realmente "implementa" las colas, por lo que debería estar bien siempre que nuestro código de aplicación se esté ejecutando realmente en el servidor que aloja Azure Storage Emulator.
• Cuadros Aquí, tenemos 3 opciones.El primero es uno que odio y es usar una base de datos y crear una tabla para acceder a estas tablas. No estoy considerando esa opción. El segundo es mantener las tablas en Azure. No me gusta esto porque es un montón de cosas que pueden almacenar datos de gran tamaño (hasta 1MB por registro). Mientras que las colas son increíblemente ligeras y baratas, el costo de la mesa puede sumar bastante rápido. Esto nos deja en la tercera opción, utilizando Azure Storage Emulator. No estoy seguro, pero creo que esta opción solo permitirá que los servicios que se ejecutan en la máquina local accedan a los objetos de almacenamiento. Todavía no entiendo todas las tablas de ventajas y desventajas en el emulador.
• Blobs Aquí, tenemos 2 opciones. El primero es malo, y eso los mantiene en Azure. Estos son, con toda probabilidad, archivos de tamaño considerable, por lo que no es prudente. Por lo que la segunda opción, una vez más, es utilizar Azure Storage Emulator. Creo que esto es lo que tenemos que hacer.

Así que dado que tenemos MVC Aplicaciones (rol web), servicios web WCF (rol web), colas, Mesas, Roles Blobs, y trabajador que se desencadenan por las colas, pero tablas de acceso, gotas, y WCF servicios web, ¿esto parece una forma razonable de alojar nuestros entornos internos de control de calidad (y similares)? Además de algunas molestias con los scripts remotos CSPack y CSRun para implementar en el emulador de Azure, ¿todo esto suena razonablemente automatizable con un servidor de compilación?

Answer 1

EN MIEMBRO: Está saltando a través de demasiados aros para no tener que implementar en Azure para entornos de control de calidad Dev & ... ¿por qué no simplemente implementar y probar sus scripts de implementación al mismo tiempo? Use instancias xtra-small para mantener bajos los costos.

Emulación del almacenamiento no es/eso/genial en absoluto. Hay muchas diferencias menores que harán que sus pruebas no sean confiables. Tampoco está probando el equilibrio de carga, algo que podría encontrar problemas con cualquier estado de sesión no planificado.

Answer 2

Uno de los consejos más útiles acerca de Azure que recibí es "Pruebe en Azure lo antes posible". Te ayudará a abordar las diferencias entre Azure real y emulador tan pronto como sea posible en tu ciclo de vida de desarrollo, y hay muchas.

En segundo lugar, sus soluciones alternativas suenan como un montón de trabajo solo para tener entornos de prueba. Creo que alojar en Azure sería más rentable. Y al final, igual tendrá que probar en Azure antes de lanzar su producto.