Ambientes en desarrollo de software 👨‍💻

¿Qué es un ambiente en desarrollo de software?

Con ambiente de desarrollo me refiero al hardware y al software donde ejecutamos una aplicación.

Cada ambiente de desarrollo tendrá sus propios binarios y bases de datos para evitar interferencias.

Te aconsejo que como mínimo tengas tres entornos:

• Desarrollo
• Pruebas
• Producción

Aunque para mí, lo ideal es tener 4:

• Desarrollo
• Testing
• Preproducción
• Producción

Como consecuencia de tener varios ambientes de desarrollo, no deberíamos tener usuarios, passwords, endpoints, rutas de base de datos... hardcodeado en el código. Debemos usar variables de entorno.

Ambiente de desarrollo

En este ambiente será donde actualizaremos versiones, crearemos nuevas funcionalidades, intentaremos romper la aplicación, romper la base de datos... todo lo que esté en nuestra mano para evitar sorpresas en producción.

Ambiente de testing

El ambiente de testing es básicamente probar la aplicación como se espera que funcione.

No lo probaremos igual que en desarrollo, si no que la idea de este ambiente es que las pruebas sean automáticas.

Este ambiente debe tener su propia base de datos, es muy fácil cambiar entre bases de datos o entre usuarios de acceso a las bases de datos con variables de entorno.

Aunque... sinceramente, cuando tengo prisa el testing es lo primero que me salto 😅

Sé de sobra que el testing no es una pérdida de tiempo ni mucho menos, pero es algo que me ralentiza el sacar una nueva aplicación o funcionalidad.

Idealmente, deberíamos ir haciendo tests a medida que vamos desarrollando (TDD test development driven) pero no siempre lo hago y la excusa siempre es la misma, el tiempo.

Me estoy educando en incluir el tiempo de testing en los plazos de entrega.

Los test se deberían de escribir en el momento que estás desarrollando, ya que ese es el momento donde tienes más fresca esa funcionalidad.

Ni que decir tiene que el testing te ayuda enormemente en la refactorización y en dormir más tranquilos por las noches 🧐

Ambiente de preproducción

También se le conoce como staging.

Idealmente, este ambiente debería ser igual al de producción.

El motivo de que los ambientes de preproducción y producción sean lo más parecido posible es para intentar garantizar que si la aplicación corre bien en preproducción correrá también bien en producción.

Si dependiera de mí, la única diferencia que habría entre preproducción y producción serían las bases de datos, lo que ocurre es que a veces no se puede tener la misma potencia de hardware en preproducción que en producción por temas de costes.

En teoría, los desarrolladores no deberían tener acceso a este ambiente, si no que son usuarios QA o usuarios seleccionados de pruebas los que deberían probar la aplicación en este ambiente.

Seguro que te suena que una aplicación está en alfa, o en beta. Pues eso es un ambiente de preproducción.

Igualmente, si trabajas con Git seguro que te suena ver algún repositorio tageado con la versión y acabado en rc, por ejemplo, versión 0.9.2-rc. Ese rc hace referencia a release candidate que no es más que una forma de indicar que ese código es de preproducción.

El objetivo de este ambiente es generar un tráfico o un estrés alto a la aplicación y ver su comportamiento. No es lo mismo probar una aplicación con 5 usuarios que con 500 usuarios simultáneamente.

De hecho, tengo una experiencia con esto y fue con una aplicación que usaba como backend a Firebase.

El tema era que cuando lo probaba yo todo iba perfecto, pero cuando la aplicación la usaban los usuarios se ralentizaba bastante.

El problema era que yo estaba asignando id correlativos a los documentos de Firestore y eso generaba retrasos o hotspot. Lo solucioné generando los id con un algoritmo de dispersión para evitar la escritura simultánea en zonas de la base de datos muy próxima.

En otro artículo contaré esta experiencia con más detalle.

Ambiente de producción 🚀

Despliegue después de que se pase la fase de preproducción.

Los errores más comunes que ocurren aquí son debido al alto número de usuarios que usan la aplicación de forma simultánea.

Los desarrollores no deberían tener acceso a las variables de entorno de producción.

Sólo el personal de infraestructura deberían saber las variables de entorno.

Conozca algún caso en el que en empresas muy desconfiadas ni el personal de infraestructura conoce las variables de entorno, si no que son autogeneradas.

Evita los hotfix 🛑

Un hotfix es un arreglo en caliente que se hace normalmente sobre un error en una aplicación.

Es habitual que cuando nos encontramos con un error en producción nuestra tendencia es a reparlo y subir los cambios cuanto antes, saltándonos todos los ambientes.

Esto no es recomendable, ya que muy probable se te olvide recoger esos cambios en la fase de desarrollo y cuando se haga una nueva característica o la depuración de otro bug ese hotfix se quede atrás y vuelva a explotar.

Hasta luego 🖖