Ambientes compartidos: el problema son las personas

Habla con cualquier persona de ingeniería: devs, arquitectos, gestores. La respuesta siempre es la misma. Nadie está contento con los ambientes compartidos. Dev, test, stage, demo, homolog. No importa el nombre. Los ambientes no productivos son universalmente malos. Esa es la realidad de nuestra industria.

Yo nunca me sentí cómoda con ningún ambiente compartido en ninguna empresa donde trabajé. Y te hago la misma pregunta: ¿alguna vez viste un ambiente no productivo que funcionara bien?

Ahora, la parte curiosa. Si le preguntas a alguien cuál es la solución, la respuesta casi siempre es: “si tuviéramos un ambiente más, ahí sí funcionaría”. Y mi pregunta es: si no funcionó en los ambientes que ya existen, ¿por qué funcionaría en el próximo?

Para qué sirven los ambientes?

Algunos argumentan que los ambientes son necesarios para probar. Yo diría que ese es el tipo más caro de prueba que existe. ¿Por qué necesitas un ambiente remoto compartido? ¿Por qué no puedes probar en tu máquina? ¿Por qué no puedes tener un mecanismo de prueba más barato?

Claro, algunos escenarios son más difíciles. Un sistema legado propietario sin código fuente, por ejemplo, es genuinamente complicado de probar localmente. No es imposible, pero lleva más trabajo.

El problema es que mucha gente no conoce formas mejores de probar y asume que la única alternativa es tener un ambiente compartido. Buenas ingenieras ejecutan todo lo que pueden en sus propias máquinas y evitan ambientes compartidos a toda costa.

Alguien podría argumentar que pruebas complejas y de larga duración requieren ambientes compartidos. Pero si logras reproducir esos escenarios localmente, el ambiente compartido se vuelve redundante. Para Integración Continua (CI), tiene sentido tener un ambiente centralizado ejecutando pruebas continuamente. Pero eso es CI, no un playground colectivo.

Y si no se puede ejecutar localmente?

Entonces tienes algo genuinamente caro de probar. Pero antes de aceptarlo, pregúntate: ¿estás seguro de que no existe un container Docker o Podman que lo resuelva? Muchas veces la solución existe, solo que no está integrada en el día a día de la empresa, o las personas no saben cómo hacer ese cambio.

Toma AWS como ejemplo. Una de las cosas que más me molesta es que necesitas pagar para aprender. Varios servicios simplemente no corren en tu máquina: Bedrock, SQS, agent-core. Necesitas una cuenta y vas a pagar una factura solo para hacer un POC.

Pero las ingenieras siempre encuentran la forma. Existe un proyecto open source llamado LocalStack que uso hace años. Emula APIs de AWS localmente. No es para producción, es para pruebas. Y resuelve el problema.

Y si no tengo una API?

Es común no tener APIs para todos los “estados” que necesitas inducir en una prueba. Por ejemplo: ¿cómo simular que alguien compró 300 iPhones en un e-commerce para probar un escenario de fraude? Si el servicio no expone esa API, creas una interfaz de prueba. Una API que solo existe en ambientes no productivos, con el único propósito de crear el estado necesario para la prueba.

No tener una API es un inconveniente, no un impedimento. Si tienes el código fuente, solo tienes que ir y agregar la interfaz de prueba que necesitas.

Y si no tengo el código fuente?

Digamos que es un sistema legado propietario, sin APIs, solo con una interfaz gráfica. Aunque sea un software de escritorio, si existe una UI donde puedes crear el estado que necesitas mediante clics, puedes escribir software que haga esos clics por ti. ¿Es más lento? Sí. Pero aun así es posible automatizar la creación del estado necesario.

Cómo mejorar

Algunas prácticas que hacen una diferencia real:

• Automatiza todas las pruebas. Si es manual, se va a romper.
• Aísla las pruebas. Una prueba no puede depender del estado que otra dejó.
• Ten CI de verdad. Deja de usar feature branches como muleta.
• Crea interfaces de prueba en los servicios que no exponen APIs para inducción de estado.
• Prioriza pruebas locales. Cuanto más barata la prueba, más la ejecutas.
• Trata los ambientes como inmutables. No hagas deploy de tu branch en el ambiente de dev. No toques nada manualmente. Todo por automatización.
• Habla sobre comportamiento. Si el equipo no discute cómo las personas usan los ambientes (generalmente en retrospectivas), no se pueden corregir malos hábitos.
• Capacita a los gestores para identificar y corregir comportamientos que degradan ambientes.

Deja de crear ambientes nuevos. Empieza a cambiar la cultura y el comportamiento de las personas que usan los que ya existen.