TAGS
Con casi dos años bajo el cinturón de tener una aplicación en la producción de Azure de Microsoft, he aprendido algunas lecciones duras, duras. Uno de los mayores es necesario tener pruebas activas y el seguimiento de su entorno de producción, tanto dentro como fuera del medio ambiente. Suena como una obviedad, pero es tan lejos en la lista de prioridad para la mayoría de los desarrolladores y las nuevas empresas que se necesita mucho tiempo para llegar a, si alguna vez.
Un poco de historia está en orden; es un sistema diseñado para proporcionar capacidades de logística y de gestión para organizaciones de primera respuesta como voluntarios y los cuerpos de bomberos de carrera, el EMS, la seguridad pública, búsqueda y rescate, materiales peligrosos y más.
Resgrid fue fundada por mí mismo y un compañero. Comenzó como un sitio web sencillo y un par de aplicaciones para dispositivos móviles con una página y algunos botones grandes. Un año más tarde es ahora un principio al final de sistema de gestión y logística que se ejecuta en Windows Azure.
Debido a que nuestro mercado es de primera respuesta que necesitamos para asegurar la actividad y que la información se transmite de forma rápida, tener algo hacia abajo incluso durante un corto período de tiempo puede afectar a nuestros clientes y en nuestro mercado no hay un buen momento para ir hacia abajo.
Una de las primeras lecciones duras de lo que no creaban datos de semillas que podríamos utilizar para la prueba y verificación del sistema de producción. Utilizamos Marco de la entidad como nuestro mecanismo de repositorio de respaldo y es muy fácil de añadir datos en el método de la semilla de la configuración de las migraciones:
protected override void Semillas (contexto Contexts.DataContext){ // Este método será llamado después de migrar a la versión más reciente. // Se puede utilizar el método de extensión ayudante DbSet <T> .AddOrUpdate () // Para evitar la creación de datos de semillas duplicados. Por ejemplo. // context.People.AddOrUpdate ( p => p.FullName, nueva persona {NombreCompleto = "Andrew Peters"}, nueva persona {NombreCompleto = "Brice Lambson"}, nueva persona {NombreCompleto = "Rowan Miller"} );} Utilice este método y las semillas de su base de datos! Lo que ir a sembrar usted puede preguntarse? Cualquier cosa que puede que tenga que entrar en el sistema y realizar acciones, registros de clientes, registros de conexión, etc. Incluso si nunca va a hacer las pruebas de producción, crear los datos, y lo tendrás si acaso.
Hacer ninguna prueba y utilizar el método de la semilla después de que haya datos en el sistema ya, empieza a no salir bien. Tuvimos un caso en que tratamos la creación de un departamento de pruebas después de que había clientes en el sistema ya y creamos más de 300 departamentos de prueba.
Encontrar a nuestro sistema está por debajo de sus clientes no es una buena práctica. Usted debe saber que hay un problema, mucho antes de que sus clientes le permiten saber. Una parte crítica de esta, está poniendo a prueba su sitio desde un lugar en Internet que no está en la misma red o espina dorsal como su sistema. Azure ha introducido recientemente que ayuda con esto, pero es solo cheque alto nivel.
Si su uso de equipo de la ciudad como su servidor de CI puede configuraciones de instalación que se ejecutan en un horario que puede poner a prueba su sistema con código complejo, guiones, las llamadas y mucho más. Que el servidor de CI de otro proveedor, como si el uso de Azure, que el servidor de CI en Amazon, etc. También recomiendo el uso de un servicio de copia de seguridad como para proporcionar copia de seguridad de análisis de seguimiento y tiempo de actividad.
En Resgrid, enviamos despachos (llamadas) a través de correo electrónico, mensajes de texto y notificaciones push. Este es un proceso de misión crítica para nosotros, ya que nuestros clientes necesitan estos sistemas para trabajar. Aunque no podemos garantizar la entrega del mensaje, podemos decir que si nunca se envió, nunca lo recibirán. Así que tenemos trabajos que se ejecutan que llevan a cabo las acciones del usuario que generarían esos mensajes y hacemos un seguimiento para asegurar que los recibimos. Probamos el flujo total de la producción, al menos, una vez cada hora.
Si usted tiene un sitio web y un sitio de API que viven en diferentes sistemas, probar los dos. No sólo se base en las pruebas dicen que el camino de sitio web para asegurar que el sistema está funcionando de extremo a extremo.
Usted no tiene que automatizar todo, si le toma 5 minutos para comprobar algo y que te lleva 8 horas para desarrollar una solución automatizada que tendría que probar algo 96 veces para alcanzar el equilibrio. Como una empresa pequeña / micro necesita utilizar su tiempo donde es más eficaz y que traerá nuevos clientes y mantener los ya existentes feliz. Si una prueba manual funciona y no es de alta fricción, que podría ser su mejor apuesta.
.
