El gran secreto sucio de la programación es que todo el mundo, en algún momento de su carrera, ha roto algo grande.
Grande como, borrar la base de datos de producción completa en su primer día de trabajomatando la aplicación en vivo mientras varios vendedores se lo muestran a los clienteso derribando la mitad de Internet al pasar la información incorrecta.
Ups.
Hay un millón de razones por las que las cosas salen mal, y no todas son completamente evitables. Pero tener una buena configuración para probar nuevos código puede al menos mitigar algunos de los peores errores.
Tradicionalmente, implementar código nuevo en un sitio web o aplicación sigue tres pasos. Primero, un ingeniero escribe el código y lo prueba en su máquina local, es decir, su propia computadora.
Si eso funciona, ese código se implementa en el llamado entorno de prueba, que es bastante parecido al verdadero. El entorno de ensayo permite probar nuevas características o actualizaciones con datos reales o anónimos como último paso antes de finalmente enviar el código a producción.
Sin embargo, es un poco más complicado que eso, ya que los entornos de prueba se dividen en múltiples ramas o bifurcaciones que permiten probar diferentes funciones simultáneamente. Estas bifurcaciones luego se vuelven a fusionar con el código del entorno de prueba y se envían a producción como un lote una vez que se prueban todas.
Ahora, esto suena como una configuración bastante buena, ¿verdad? Algo así como cómo los nuevos aviones primero se prueban muchas veces en tierra, luego vuelan sin pasajeros y finalmente obtienen luz verde para transportar personas.
No obstante, últimamente, muchos ingenieros han dejado de usar los entornos de prueba por completo, argumentando que es mejor, más rápido y más barato omitir esa etapa y simplemente implementar nuevas actualizaciones y funciones de inmediato. Pero, ¿podría esto estar lastimándote más que ayudándote?
Echemos un vistazo más profundo a por qué algunos ingenieros están abandonando los entornos de prueba y por qué estos argumentos podrían no tener sentido.
Facebook lo hace…
Muchos apuntan a Facebook, que es bien sabido que no utiliza un entorno de prueba, sino que impulsa los cambios a un pequeño (pero enorme) subconjunto de usuarios, por ejemplo, el 1 % de los usuarios en Hungría, y, si eso funciona, implementa actualizaciones a un público más amplio. audiencia. Pero no todas las empresas tienen miles de millones de usuarios como Facebook.
Claro, dependiendo de la tolerancia de uno para el tiempo de inactividad y la realización de revisiones, se puede argumentar simplemente para implementar nuevos lanzamientos en la naturaleza y ver qué sucede. Para la mayoría de las empresas, no hay dependencias de vida o muerte en su producto. Y simplemente permitir que un sitio web o una aplicación no responda, durante el tiempo que sea necesario para revertir los cambios y verificar qué causó la interrupción, puede ser una opción.
Por otra parte, este podría no ser el enfoque más fácil de usar. Además, es posible que existan acuerdos vigentes con los clientes que limiten el umbral del tiempo de inactividad antes de que se impongan sanciones al proveedor de servicios (usted).
En lugar de eliminar la responsabilidad, la traslada al equipo en general.
Es importante asegurarse de que las actualizaciones o los cambios que están destinados a beneficiar al cliente, e incluso pueden ser una solicitud directa de ellos, realmente funcionen según lo previsto y no requieran que los administradores de cuentas pidan perdón.
Los entornos de ensayo son demasiado costosos
Según el tamaño de su sitio web o aplicación, mantener servidores adicionales en funcionamiento para la puesta en escena puede llevar a que un CFO triste pague el doble de las facturas de AWS.
Permítanme hacer una analogía con un restaurante. Sí, si mantiene su cocina completamente equipada y con personal para probar nuevos elementos del menú para un restaurante, eso afectará sus resultados. O todo.
Pero también se puede preparar y probar una nueva receta en casa, en una estufa normal, con cantidades más pequeñas de ingredientes.
Lo mismo ocurre con la puesta en escena. No necesariamente necesita la misma capacidad de hardware para probar el código para la producción. Siempre que tenga en cuenta los recursos relativos que está utilizando, debería ofrecer resultados útiles. Y, si te aseguras de que la puesta en escena refleje la producción de espejos en lugar de la configuración de tu hogar, pronto descubrirás si te falta algún ingrediente.
Despliegue ahora de IONOS La característica, por ejemplo, se encarga de eso activando y administrando las sucursales de características en la fase de preparación, sin romper el banco.
funcionó en mi máquina
Preparar su código no se trata solo de asegurarse de que funcione durante la producción. La puesta en escena también se trata de lograr que otras partes interesadas participen.
Los defensores de la puesta en escena argumentan que tener un entorno de puesta en escena diluye la responsabilidad porque desarrolladores arrojar su código sobre la cerca a las personas que lo administran.
Eso puede ser cierto, pero también ayuda a romper los silos entre los diferentes equipos de productos.
Un entorno de prueba permite a los diseñadores probar cómo se ven las cosas, permite a los ingenieros de control de calidad (QA) probar el nuevo código en diferentes plataformas, a los gerentes de producto realizar un seguimiento de los cambios y a los clientes tener una idea de una nueva función antes de que se publique. .
Es básicamente como tener dos restaurantes paralelos pero idénticos.
En lugar de eliminar la responsabilidad, la traslada al equipo más amplio, lo que a su vez fomenta una mayor participación y compromiso con el producto.
La puesta en escena genera grandes colas
Si es una organización más grande con muchos equipos que trabajan en diferentes partes de una aplicación, tener un solo entorno de preparación puede llevar a procesos de aprobación más largos; esto no solo ralentiza las cosas, sino que también impide que los ingenieros comiencen una nueva tarea o hace que tienen que volver atrás y corregir elementos de una función anterior después de haber comenzado un nuevo proyecto.
Esto puede ser bastante tedioso.
Idealmente, lo que le gustaría de la puesta en escena es tener automáticamente varias ramas de funciones con los correspondientes entornos de puesta en escena que permitan que el código se pruebe inmediatamente y se publique después de que pase todas las comprobaciones.
Nuevamente, administrar esto puede ser una tarea difícil, pero la función Implementar ahora de IONOS puede hacer esto por usted. En principio, eso debería significar que puede implementar continuamente, sin acumular grandes colas o perder productividad debido al cambio de tareas.
La puesta en escena no está a la par con la producción
Otra razón por la que a algunas personas no les gusta la puesta en escena es que se necesita mucho trabajo para mantener el entorno de la puesta en escena en un estado de copia al carbón con la producción.
Esto no solo se aplica a todas las dependencias, sino también a los datos que se usan durante la producción pero que no se pueden usar durante la preparación porque contienen cosas como contraseñas, identidades personales o datos de tarjetas de crédito.
Esto significa que necesita mantener un conjunto de datos ficticio y también hacer que el esquema de esos datos se corresponda con la información que tiene en las fases de preparación y producción. Los desarrolladores también necesitan datos ficticios o de prueba similares para el desarrollo local (o la revisión), por lo que también se pueden usar para la puesta en escena.
Es básicamente como tener dos restaurantes paralelos pero idénticos.
Construir esto desde cero puede parecer una gran tarea. Pero, de nuevo, si comienza con un entorno de prueba adecuado y se asegura de que se actualice regularmente para reflejar la producción, solo se necesita un poco de tiempo adicional para mantenerlo.
Y tener ese hábito podría ayudar a su empresa a mantener a los ingenieros productivos y, lo que es más importante, a mantener contentos a sus clientes.
Entonces, si está pensando en deshacerse de los entornos de escenario, piénselo de nuevo. En lugar de un proceso engorroso, mantener esta fase de desarrollo del producto ayudará a que la experiencia del cliente funcione sin problemas y le permitirá involucrar a la empresa en general, sin arruinarse.