Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# GAMEOPS03-BP04 Adopte una estrategia de despliegue que minimice el impacto en los jugadores
Incorpora una estrategia de implementación para el software y la infraestructura de tu juego que minimice la cantidad de tiempo de inactividad que mantiene a los jugadores alejados del juego. Si bien algunos tipos de actualizaciones pueden requerir la instalación de nuevas actualizaciones en el cliente del juego, diseñe el juego de forma que minimice o evite el tiempo de inactividad durante las implementaciones.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Uno de los pasos más importantes a tener en cuenta a la hora de desarrollar una estrategia de despliegue de juegos es determinar cómo se administrará la infraestructura del juego. Gestiona tu infraestructura de juego con una herramienta de infraestructura como código (IaC), como [AWS CloudFormation](https://aws.amazon.com/cloudformation/) [ Terraform de ](https://www.terraform.io/) [ Hashicorp, ](https://www.terraform.io/) para reducir los errores humanos durante la preparación del entorno. Las plantillas de infraestructura se pueden implementar y probar en canalizaciones automatizadas, lo que crea coherencia en la configuración de los diferentes entornos de juego.
Hay varias estrategias de despliegue que se pueden usar en un juego:
**Sustitución continua **
El objetivo principal de las sustituciones sucesivas para un despliegue es ejecutar el lanzamiento sin cerrar el juego y sin afectar a los jugadores. Es importante que la actualización o los cambios que se vayan a realizar sean compatibles con versiones anteriores y funcionen de forma similar a las versiones anteriores del sistema.
En esta implementación, las instancias del servidor se reemplazan (sustituyen o implementan) de forma incremental por instancias que ejecutan la versión actualizada. Esta sustitución sucesiva se puede realizar de varias maneras diferentes. Por ejemplo, para implementar actualizaciones continuas en una flota de servidores de juegos dedicados, un enfoque típico consiste en crear un nuevo grupo de instancias EC2 de Auto Scaling que contenga la nueva versión compilada del servidor de juegos implementada en ellos y, luego, redirigir gradualmente a los jugadores a las sesiones de juego alojadas en esta nueva flota de servidores. Si se requiere una actualización del cliente del juego asociada como requisito previo para usar la nueva versión del servidor del juego, debes incluir una comprobación de validación para comprobar que solo los jugadores que tienen instalada esta nueva actualización del cliente del juego acceden a estas sesiones de juego.
Las flotas de servidores (por ejemplo, los grupos de EC2 Auto Scaling) que contienen la versión anterior de compilación del servidor de juegos solo se eliminan del servicio una vez que se agotan las sesiones de jugadores activas de manera eficiente, normalmente mediante la configuración de métricas de servidor individualizadas que permiten a los equipos de operaciones del juego automatizar este proceso. Como alternativa, para reducir la cantidad de infraestructura y el tiempo necesarios para llevar a cabo una implementación continua, se puede aplicar un enfoque alternativo en el que las instancias de producción existentes se eliminen del servicio, se actualicen con la nueva versión del servidor de juegos y, a continuación, se vuelvan a colocar en la flota de producción. Este enfoque reduce la cantidad de infraestructura necesaria, pero también aumenta el riesgo, ya que la cantidad de servidores de juegos en vivo disponibles para los jugadores se reduce a medida que se reemplazan los servidores.
Este modelo también se puede usar para realizar despliegues continuos en servicios de backend, como bases de datos, cachés y servidores de aplicaciones que no alojan partidas. Siempre que estos servicios se implementen de manera altamente disponible con varias instancias agrupadas en clústeres, la complejidad de las implementaciones de estos servicios debería ser menor que la de las implementaciones en servidores de juegos dedicados.
**Blue/green Implementación**
El objetivo principal de una blue/green implementación en un juego es minimizar el tiempo de inactividad y, al mismo tiempo, permitir la recuperación segura de la implementación anterior si se identifican problemas. Es adecuado para despliegues en los que dos versiones del backend del juego son compatibles y pueden servir a los jugadores de forma simultánea.
En la estrategia de blue/green despliegue, se configuran dos entornos idénticos (azul y verde). La versión del juego existente está etiquetada en azul, mientras que la nueva versión del juego que es el objetivo de despliegue está etiquetada en verde. Cuando el entorno ecológico esté listo para la migración, puede configurar la capa de enrutamiento para que transfiera el tráfico al entorno verde y, al mismo tiempo, mantener el entorno anterior (azul) disponible en caso de que sea necesaria la conmutación por recuperación. En este escenario, las actualizaciones de enrutamiento pueden requerir la actualización del servicio de emparejamiento para configurarlo y comenzar a enviar sesiones de juego a la nueva flota o, en el caso de los servicios de backend de juegos, esto podría consistir en actualizar los registros DNS de Amazon Route 53 para tu servicio o [ cambiar el peso del balanceador de carga de la aplicación ](https://aws.amazon.com/blogs/aws/new-application-load-balancer-simplifies-deployment-with-weighted-target-groups/) para enviar tráfico al nuevo grupo objetivo.
Uno de los inconvenientes de la estrategia de blue/green despliegue es el coste inherente del entorno de espera, debido a la infraestructura adicional necesaria para realizar el despliegue. Una opción para mitigar este costo adicional de infraestructura es considerar la posibilidad de adoptar una variante de blue/green implementación en la que el nuevo software de juego se implemente en los mismos servidores que ya están implementados en producción. En este escenario, se puede iniciar un nuevo proceso de servidor ecológico con el nuevo software, paralelamente al proceso de servidor azul existente, de manera que la transición se produzca entre los procesos del servidor en lugar de entre infraestructuras físicas independientes. Este enfoque también puede acelerar la implementación de juegos en una gran cantidad de infraestructuras al eliminar la necesidad de esperar a que se lancen los nuevos servidores en la nube. Para conocer las prácticas recomendadas sobre este enfoque de implementación, consulta [ Blue/Green Implementaciones en. AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)
**Despliegue en Canarias **
El despliegue canario es útil para los desarrolladores de juegos, ya que la estrategia se puede aplicar para lanzar una versión alfa o beta temprana de un juego, o bien utilizar funciones del juego, como un nuevo modo de juego, mapa o desafío, para un grupo reducido o restringido de jugadores en producción. Este tipo de despliegue recibe el nombre de * * canario. Es posible que la versión incluya funciones de seguimiento e informes adicionales, de modo que cuando los jugadores reales jueguen a ese juego o función, recopilen la telemetría de su juego y la analicen para detectar anomalías o problemas.
En el caso de las nuevas funciones, no se notifica de forma constante a los jugadores al respecto, y la telemetría del juego es la fuente principal que se utiliza para determinar si los jugadores tienen problemas, por lo que la versión debería revertirse. Al mismo tiempo, si no se detecta ningún problema importante, la función puede ampliarse a más jugadores para obtener más información. Si se notifica a los jugadores, se les puede pedir que envíen comentarios periódicos sobre su experiencia. Lo ideal sería que dicha actividad de prueba fuera coordinada por un equipo de operaciones en vivo.
Como estrategia, Canary Deployment también se puede utilizar en las versiones estándar para poner gradualmente a disposición de los jugadores una nueva función. Una ventaja potencial sobre el blue/green entorno estándar es que no se requiere un segundo entorno a gran escala. La capacidad del nuevo entorno reducido determina el número de jugadores que se incorporarán a la nueva función. Antes de añadir más jugadores, la capacidad debe ampliarse adecuadamente. Si bien se espera que esta blue/green técnica personalizada cueste comparativamente menos que la estándar blue/green, se estima que tendrá un costo que puede ser superior al de la técnica de sustitución continua de los despliegues canarios.
Ejecute un solo canario en un entorno de producción y concéntrelo en sus datos y comentarios. Si se implementan varios sistemas canarios, se complica la solución de problemas y el aislamiento de los problemas en la producción, y se deteriora la calidad de los conjuntos de datos y los comentarios que se recopilan.
Otra variante es cuando uno o más experimentos (por lo general, pruebas de interfaz de usuario) se ejecutan en despliegues específicos, en los que un conjunto de servidores de backend del juego incluye una versión de una función y otro conjunto del mismo tamaño sirve para otra versión de la misma función. No se crea ninguna infraestructura adicional o especial para ello, y solo los grupos de servidores back-end seleccionados reciben estas actualizaciones. El resultado de los experimentos consiste en observar cómo reaccionan los jugadores ante cada una de las versiones de la misma función, determinar si existe un consenso general sobre lo que les gusta o no, y observar si hay problemas relacionados con su usabilidad o funcionalidad. Estos experimentos estratégicos también se denominan A/B pruebas, y el proceso general se denomina * A/B pruebas*. Una vez finalizados estos experimentos, se recopilan los datos de prueba necesarios antes de volver a la versión actual del sistema de backend del juego en los servidores utilizados para las pruebas.
**Implementaciones tradicionales antiguas **
En el estilo tradicional de despliegue, durante un período de mantenimiento programado, el juego se cierra y los jugadores conectados son eliminados o agotados antes de que las instancias del servidor del backend del juego se actualicen con las versiones de código más recientes. Esta implementación afecta a los jugadores cada vez que se lleva a cabo, y los jugadores deben recibir una notificación antes de lo previsto. Como resultado, este modelo es el que más afecta a los jugadores y debe evitarse siempre que sea posible.
Una vez implementada la actualización del juego, los jugadores pueden hacer una prueba de humo antes de abrir la partida, ya que estarán esperando a que la partida vuelva a abrirse. Esto puede provocar un aumento del tráfico si los jugadores intentan iniciar sesión y jugar en poco tiempo. Por lo tanto, si el juego no está diseñado para soportar esos picos de tráfico, puedes optar por permitir que los jugadores regresen gradualmente al juego por lotes.
También puedes optar por aprovisionar en exceso la infraestructura para mantener el pico inicial de tráfico y, una vez que el tráfico del juego se estabilice, podrás reducir los recursos. Si es necesario, realiza este tipo de despliegue fuera de las horas punta, cuando el número de jugadores es el más bajo. El mantenimiento programado con frecuencia, así como el mantenimiento prolongado, conllevan intrínsecamente un riesgo de pérdida de jugadores y una posible pérdida de ingresos. Los jugadores también esperan cambios tras un nuevo lanzamiento y pueden perder la confianza en el juego si regresan tras un período de inactividad.
### Pasos para la implementación
+ **Minimiza el tiempo de inactividad: ** implementa estrategias de despliegue que reduzcan el tiempo de inactividad y mantengan a los jugadores en el juego.
+ **Infraestructura como código (IaC): ** utiliza herramientas como AWS CloudFormation Terraform para gestionar la infraestructura del juego y reducir los errores humanos.
+ **Estrategias de implementación: ** usa una o una combinación de despliegues sucesivos blue/green, de sustitución y canarios para ofrecer actualizaciones fluidas y reducir el impacto en los jugadores.