50 tazas de café son suficientes para todo.
Además de la regla general descrita anteriormente, publicamos una breve nota sobre los puntos que deben prestarse mucha atención para que nada se rompa en la batalla y en los procesos. La nota se hizo en la búsqueda del lanzamiento de un servicio móvil que migró completamente a .Net Core (el comienzo se estableció aquí ). Logramos realizar esta operación sin ser notada por el cliente, casi sin detener el proceso de desarrollo principal.
A continuación se muestra un plan de acción listo, habrá una lista de pruebas muy amplia, esta imagen estará aquí para el estado de ánimo:
Entonces, en pasos:
1. Planifique un sprint largo con grandes características y / o regresión
Con la reescritura de código fundamental, el servicio necesitará tiempo para insistir el mayor tiempo posible para tener tiempo de corregir todas las fallas en el entorno de prueba.
2. En el sprint exacto para reescribir el código en .Net Core
¿Por qué es importante no comenzar este negocio antes de tiempo? Debido a que debe extraer dos ramas de código con el .net nuevo y antiguo, porque en cualquier momento puede volar un pájaro de urgencia o deberá realizar una demostración de las nuevas características, y luego deberá realizar cambios en la rama estable anterior. Para experimentar una preocupación mínima sobre esto, es mejor acortar el momento del estado de transición.
Por cierto, cuando trabajamos con el código, llegamos rápidamente a la conclusión de que es más conveniente mantener dos copias del repositorio localmente. Es más fácil y más conveniente que cambiar dos ramas masivas.
- Si es posible, reescriba las interfaces WCF en webapi en los servicios utilizados
La implementación de .Net Core del cliente WCF aún está lejos de ser ideal. A pesar del hecho de que las llagas viejas están de alguna manera arregladas, en las nuevas versiones todavía tiene que usar la solución ( 1 , 2 ).
Para la historia: en .Net Core 2.0, la versión de trabajo estable de WCF es 4.4.2 del repositorio myget. Ella, por ejemplo, no tiene problemas con un tiempo de espera temprano
Al comienzo de la migración, utilizamos la versión de .Net Core 2.0. Mientras tanto, Microsoft lanzó .Net Core 2.1. ¿Quién está interesado en admirar los éxitos de los chicos de Redmond en la optimización de la plataforma? Lea el progreso que hizo el motor de búsqueda Bing al actualizar a la nueva versión (spoiler: ¡latensi cayó un 34%!)
También actualizamos a .Net Core 2.1 y WCF 4.5.3. Y no nos olvidamos de especificar en el Dockerfile una nueva imagen base de microsoft / dotnet: 2.1-aspnetcore-runtime. Cuál fue la sorpresa cuando, en lugar de 1,4 GB, vieron un tamaño de imagen de 0,5 GB (estamos hablando de una imagen de Windows, si de repente).
3. Ensillarse para una prueba y demostración
Tenemos dos ambientes a nuestra disposición. Dejamos la demo con la versión anterior como referencia. Se implementó un nuevo servicio en el entorno de prueba: una ejecución en desarrolladores y probadores.
Hubo cierta confusión debido al hecho de que los desarrolladores generalmente trabajan con la prueba, y los probadores principalmente con una demostración. Si era necesario actualizar el antiguo servicio, la situación era exactamente lo contrario de lo normal. Por lo tanto, una discusión y una hoja de trucos sobre dónde y qué buscar fue útil.
Para ejecutar el servicio .Net Core en IIS, debe instalar el módulo que viene con el tiempo de ejecución.
AppPool cambia a CLR Runtime = Sin código administrado.
En la solución en el estándar web.config, es importante no olvidar establecer el requestTimeout deseado y deshabilitar el módulo WebDAV, si hay métodos DELETE.
Además, hay dos opciones para publicar un servicio en IIS:
- realiza la sincronización de MSDeploy, lo que significa que además necesita el conmutador -enableRule: AppOffline
- publica el archivo: significa exactamente antes de la publicación, debe colocar el archivo app_offline.htm en el directorio de servicios y, después de la publicación, eliminarlo
Tanto eso como otro permiten detener un proceso de trabajo y abrir archivos ejecutables. De lo contrario, se producirá un error de que los archivos no están disponibles para sobrescribirse.
Rechazamos el registro a través de Nlog a favor de Serilog, y perdimos la compresión automática de registros; en Serilog simplemente no existe tal característica. En este caso, puede guardarlo utilizando herramientas normales de Windows e instalar la compresión NTFS en las propiedades del directorio.
4. Prueba
Aquí está la lista de verificación más reducida para los lugares más frágiles:
- verifique la devolución de los códigos de estado Solicitud incorrecta, no autorizada, no modificada, no encontrada: todo lo que la API puede brindar
- verificar el registro de solicitudes para todos los códigos de estado
- hacer un diagrama de dependencias externas; como regla general, toda la información necesaria se encuentra en las configuraciones
- desterrar los métodos que afectan su trabajo
- verificar el registro de solicitudes externas
- comprobar el funcionamiento de la configuración de los parámetros de configuración de la aplicación; intenta cambiarlos por calor
- compruebe el almacenamiento en caché http para códigos de estado positivo y negativo
- Encabezado ETag
- encabezado de control de caché
- comprobar solicitudes largas y tiempos de espera
- verificar solicitudes con una respuesta vacía
- verifique los métodos DELETE (WebDAV está deshabilitado o no)
- verificar el trabajo con contenido sin procesar
- cargar y descargar uno / varios archivos
- subir archivos con un tamaño superior al límite
- diseño de encabezado Content-Disposition
- verifique todos los otros encabezados; ponerlos todos juntos en código es bastante fácil
- comprobar la ejecución de código condicional al cambiar de entorno
if (env.IsDevelopment()) - comprobar desconexión del cliente y el servidor
- comparar con el estándar swagger.json: ayudará a detectar la diferencia en los campos transmitidos
Nuestra aplicación móvil utiliza un generador de código para trabajar con la API basada en la descripción de swagger.json, por lo que era importante que la diferencia con la descripción original fuera mínima. En la última versión de Swashbuckle.AspNetCore, la interfaz y el swagger.json generado han cambiado mucho. Tuve que volver a la versión lamentable de Swashbuckle.AspNetCore 1.2.0 y agregar un par de filtros.
5. Prepárate para una pelea mientras tomas café
En nuestro caso, el entorno de combate consta de dos nodos: activo y pasivo.
Para que el cambio al nuevo servicio pase desapercibido, duplicamos el grupo y el sitio en cada nodo, y escribimos un script para cambiar el enlace entre el sitio antiguo y el nuevo.
Por lo tanto, en caso de emergencia, pudimos cambiar rápidamente a la versión anterior.
Además, después del despliegue en la batalla, en una semana nos convencimos de la viabilidad del servicio y encendimos una luz verde para el lanzamiento de la aplicación móvil. La vida en el proyecto regresó de manera segura a su curso anterior.
Subtotal
Ahora nuestro servicio está completamente listo para hacer crecer un contenedor acoplable para su entrega al clúster. Estamos listos para la implementación tanto en Kubernetes como en Service Fabric.
Ahora se están realizando preparativos para la presentación de la nueva infraestructura al cliente. Le informaremos sobre nuestros logros en la próxima serie, mantenga su dedo en el pulso;)