Guía de Preparación para la Producción de Aplicaciones – CodesCode

Desplegar una aplicación en producción no es el estado final, sino una etapa muy crucial del ciclo de vida del desarrollo de software.

Desplegar una aplicación en producción no es el estado final, sino una etapa muy crucial del ciclo de vida del desarrollo de software. Hay muchos factores que podrían salir mal, especialmente cuando estás desarrollando un nuevo servicio, desplegando por primera vez o lanzando una importante actualización de características. Para evitar cualquier incidente, esta guía puede ayudarte a crear un plan para desplegar y gestionar tu aplicación en producción.

Preparación para producción

Revisión de arquitectura: Sé que este es el primer paso antes de comenzar el desarrollo. Pero la mayoría de las veces, a medida que avanza el desarrollo, muchas cosas cambian y la arquitectura de los documentos se vuelve obsoleta. Siempre es buena práctica mantener actualizado tu documento y verificarlo antes de la versión final.
Seguridad: La seguridad es otro pilar importante de un servicio saludable. Esto garantiza la seguridad de los datos almacenados y compartidos en varios subsistemas. Verificar y asegurarse de que se sigan buenas prácticas de seguridad antes de lanzar el servicio ayudará a largo plazo.
Panel de control del servicio: Un conjunto de paneles de control de monitoreo de servicios consolidados en un solo lugar para proporcionar una vista integral de la salud y el rendimiento del servicio. Esto ayudará a comprender los diferentes componentes y el uso de la aplicación.
Alarmas: Hay algunas alarmas estándar como memoria, CPU, GPU, etc. (umbral en 70% u 80%), que permitirán a tu equipo conocer posibles problemas y ayudar a mitigarlos proactivamente. Este evento te ayudará a implementar metodologías adecuadas para escalar tu aplicación según sea necesario. Hay ciertos puntos de datos que son desconocidos en el momento de su versión, y está bien poner un número arbitrario para generar una alarma para ese tipo de métrica.
Escalar, cachear y latencia: Cada aplicación se construye para un conjunto determinado de usuarios y un cierto número de transacciones para soportar. Pero a menudo, necesitamos estar preparados para escalar hacia arriba o hacia abajo según el uso. Siempre es una buena práctica establecer factores de escala adecuados para ampliar o reducir la aplicación según varios parámetros para evitar cualquier tiempo de inactividad o impacto en los clientes. Asegúrate de implementar un mecanismo de caché adecuado para almacenar en caché e invalidar los datos en caché. Esto te ayudará a mantener tus SLA para una baja latencia.
Pruebas beta: Las pruebas beta proporcionan un entorno de desarrollo para probar el flujo, las interacciones y el funcionamiento de extremo a extremo de la aplicación. Esto ayuda a construir confianza.
Pruebas gamma o UAT (Pruebas de aceptación de usuario): Siempre es mejor probar tu aplicación/funcionalidad con un conjunto de usuarios leales que pueden proporcionar comentarios basados en el uso real. Esto también te ayudará a probar tu aplicación antes de abrirla a una audiencia más amplia.
Manuales de ejecución: Hay escenarios en los que se requieren ciertos conjuntos de operaciones manuales para realizar ciertas tareas, como incorporar usuarios, migrar clientes existentes, etc. Estos deben documentarse correctamente para evitar cualquier problema.
Cobertura de pruebas unitarias: Define un criterio de cobertura mínima, por ejemplo, 80% o 90%, y sigue eso para escribir pruebas unitarias. Cuanta mayor cobertura, menor será la posibilidad de encontrar errores.
Pruebas de integración: Las pruebas unitarias son una excelente manera de detectar cualquier problema con tu función o un bloque de código, pero las pruebas de integración te permitirán probar la funcionalidad como un todo. Esto también asegurará que cualquier cambio futuro no rompa la funcionalidad existente.
Proceso de gestión de cambios (CM): El punto #8 habla sobre los manuales de ejecución. Mientras que los manuales de ejecución definen los pasos para realizar las operaciones manuales, el proceso de gestión de cambios garantizará que se sigan los pasos correctos y se documenten estos cambios. Esto establecerá las mejores prácticas para cualquier cambio manual y evitará problemas en producción.
Pipeline de CI/CD: Evita la intervención manual tanto como sea posible. Un pipeline de CI/CD completo garantizará que los cambios sean revisados adecuadamente, probados unitariamente y probados de integración.
Pruebas de desarrollo: Realiza tantas pruebas de desarrollo como sea posible para todos los escenarios posibles que puedas imaginar. Esto elevará la calidad del entregable y garantizará la seguridad del código implementado en producción.
Plan de mitigación de incidentes: No importa cuán bien esté diseñado y desarrollado el sistema, siempre habrá riesgos conocidos o desconocidos asociados. Siempre es buena práctica documentar un plan de mitigación de riesgos en caso de que ocurra algún incidente. Por ejemplo, ¿qué sucede si el servidor web se bloquea, qué pasa si la redirección de la página web está rota, etc? Un plan de mitigación actuará como una guía para que cualquier desarrollador del equipo actúe rápidamente en caso de un incidente. “¡Desarrolla lo mejor, prepárate para lo peor!”
Documentación de dependencias: Si tu aplicación depende de alguna otra aplicación o aplicaciones, revísalo, documenta y crea un plan de mitigación para casos de uso como qué sucede si ese servicio comienza a limitar, qué pasa si el servicio está inactivo, etc.
Registro de eventos: Asegúrate de implementar un registro adecuado para todos los escenarios, como información, error, advertencia o depuración. Además, asegúrate de no imprimir datos críticos en el registro y de implementar un nivel de registro adecuado en las diferentes etapas.
Pruebas de carga: Realizar pruebas de carga en tu aplicación te proporcionará un número en el cual la aplicación podría fallar. Esto te ayudará a implementar un mecanismo de escala adecuado para evitar tiempo de inactividad.
Mecanismo de reversión: ¿Qué sucede si llega a producción una implementación defectuosa? ¿Qué sucede si llega a producción algún código no probado? ¿Qué sucede si el código implementado no funciona correctamente en producción? Para mitigar cualquier problema de este tipo, se debe establecer y documentar un mecanismo de reversión adecuado para volver la aplicación a un estado previamente conocido. Esto te ayudará a restaurar rápidamente el estado previamente conocido de la aplicación.
Pruebas A/B: En caso de una importante actualización de características, es mejor recopilar métricas basadas en clientes A/B. Estas métricas proporcionarán información sobre la función lanzada y su adopción. Esto te ayudará a tomar la decisión de lanzarlo a una audiencia más amplia o revertirlo.
Mecanismo de lanzamiento: Alfa, beta, gamma, UAT y Producción. Estas son diversas etapas que podrías establecer para orientar a diferentes tipos de clientes. Pero para lanzar tu aplicación o una importante característica a una audiencia más amplia, define una estrategia de lanzamiento adecuada, como lanzarla a una base de usuarios geográficos determinados, lanzarla a un porcentaje determinado de usuarios, lanzarla a un número determinado de usuarios, etc. Una vez que el lanzamiento inicial sea exitoso, luego cómo lanzarlo a una audiencia más amplia.

Conclusión

En conclusión, tener documentación detallada que capture varios puntos de datos no solo facilita un desarrollo más seguro, sino que también proporciona un despliegue más seguro y un servicio saludable.